Настроили систему аналитики для оценки дохода от рекламы

В агентство обратилась онлайн-школа стилиста Насти Ерасовой – «Разборки в моде» - которая предлагает курсы, марафоны, вебинары, посвященные теме моды и стиля.




Онлайн обучение проходит на платформе GetCourse. Помимо организации и проведения самих занятий, платформа предлагает свою CRM-систему, которая дает возможность принимать платежи, сегментировать клиентов, анализировать продажи и ключевые показатели.



Казалось бы, этого достаточно для того, чтобы получить внятную аналитику. Однако система не позволяет определить источник продажи, и, как следствие, эффективность рекламных каналов.

MediaNation разделила работу на два этапа:

• реализовать сбор данных аналитических систем (Google Analytics и Яндекс.Метрики) на стороне CRM–сервиса GetCourse;
• реализовать передачу данных об оплаченных заказах из CRM в Google Analytics и Яндекс.Метрику.

Первое решение, которое напрашивалось, – собирать данные о транзакциях через коды электронной торговли, установленные на страницах «Корзина», «Оплата», «Спасибо за заказ».

Но это решение не удалось реализовать. Во-первых, несмотря на то, что после оплаты услуг онлайн-школы через Robokassa и PayPal пользователи могли вернуться на сайт (через редирект или нажав на кнопку «Вернуться в магазин»), это делали не все. Клиенты часто закрывали страницу системы оплаты, так и не перейдя к финальной странице «Спасибо за заказ».

Во-вторых, хотя переход на финальную страницу «Спасибо за заказ» и был возможен, выяснилось, что на ней не было полезной информации – ни номера заказа, ни оплаченной суммы. Добавить такие данные через разработчиков было нельзя и соответственно нельзя было их получить автоматически с помощью какого-либо скрипта.

Учитывая эти ограничения, мы решили собирать необходимые нам данные в CRM-системе GetCourse и передавать их в системы аналитики.

GetCourse позволяет работать с информацией по трафику и цепочкам взаимодействия пользователей. Однако многие данные собираются не так, как привыкли маркетологи, работая с традиционными аналитическими системами. Например, в базовом профиле пользователя источником трафика указывается домен сайта, а параметр канала – реферальный трафик. Это не позволяло оценить источники переходов на сайт и эффективность различных рекламных каналов.




Несмотря на это, с профилем можно было работать, внеся в алгоритм сбора данных некоторые изменения.


Регистрационная форма – точка сбора данных о клиенте (имя-емейл-телефон). Нам было необходимо, чтобы в ней дополнительно собиралась корректная информация об источнике перехода на сайт, а также данные аналитических систем.

Мы создали код на Javascript, который во время регистрации дополнял информацию о клиенте и был расположен внутри контейнера Google Tag Manager. В результате стало возможно собирать идентификаторы аналитических систем из cookies браузера, а именно: ClientID Google Analytics, ClientID Яндекс.Метрики, ClientID Fаcebook, а также данные на всех уровнях UTM–меток (utm_source, utm_medium, utm_campaign, utm_content и utm_term) из URL-адреса. Отметим, что внешний вид регистрационной формы, которую видит клиент, не изменился, т.к. передача данных была реализована через дополнительные скрытые поля внутри заявки.

Конечно, конструктор Tilda позволяет также вставлять свои собственные javascript-коды. Но мы решили прибегнуть к проверенному инструменту – Google Tag Manager – который ускорил и упростил решение задачи, и тем самым снизил для заказчика стоимость наших услуг.

Рис. 1: Пример дополнительных скрытых полей в регистрационной форме. GetCourse

Рис. 2. Часть кода в Google Tag Manager, который показывает, по каким правилам будут обработаны данные и переданы в соответствующие поля регистрационной формы.

В итоге необходимые данные об источниках перехода появились в CRM в карточках клиентов и их заказах.

Рис. 3. Карточка клиента с созданными дополнительными полями. GetCourse

Рис. 4 Страница с заказами и созданными дополнительными полями. GetCourse

На этапе разработки скрипта для передачи данных в поля форм мы столкнулись со следующей проблемой: страница сайта и всплывающее окно регистрационной формы находились на разных поддоменах третьего уровня (domain.site.ru), что не позволяло передавать данные через cookies. Эта проблема была связана с кросс-доменным ограничением (Same Origin), цель которого – безопасность при работе с вкладками браузера. Мы пытались решить эту проблему через Cross-Origin Resource Sharing (CORS) на стороне GetCourse, но техподдержка платформы не смогла нам в этом помочь. Однако мы нашли выход. Поскольку лендинг и форма заявки находились на поддоменах третьего уровня, все ограничения можно было снять, добавив на оба сайта код document.domain = 'site.com'. Так мы и сделали: код был прописан в наш основной скрипт, который запускался на каждом поддомене через Google Tag Manager.

Рис. 5. Основной сайт и всплывающее окно (iframe) регистрационной формы на другом поддомене с консолью отладки Google Tag Manager

Благодаря доработке скрипт из всплывающего окна (iframe) может прочитать cookies внешнего сайта и получить данные по UTM-меткам.


Следующим шагом стало создание алгоритма, по которому данные из CRM передавались на сервер MediaNation для дальнейшей обработки. Мы использовали функционал «Процессы» в платформе GetCourse, в котором описали правила передачи информации о состоявшихся оплатах.

Рис. 6. Визуальное отображение внутреннего функционала «Процессов» (правил передачи данных) с указанием сайта, на который будут отправляться данные из CRM.

В данном случае использовался сервер с техническим доменом MediaNation, который собирал отправленные данные.

В итоге общая схема сбора и передачи информации выглядела следующим образом:

1. Google Tag Manager запускал скрипт для записи в поля форм данных об идентификаторах аналитических систем и UTM-метках.
2. Данные пользователей сайта и их конверсии передавались в аналитические системы. Но не передавались данные по доходу и транзакции.
3. Данные о заказе, клиенте и источнике перехода на сайт передавались в CRM GetCourse.
4. GetCourse передавал данные на сервер MediaNation, где они преобразовывались в соответствующий каждой аналитической системе (Google Analytics и Яндекс.Метрике) формат.
5. Преобразованные данные отправлялись в каждую систему аналитики по своими протоколам:

• передача данных в Google Analytics через Measurement Protocol;
• передача данных в Яндекс.Метрику через офлайн–конверсии.

На стороне аналитических систем данные по трафику пользователей «склеивались» (через идентификаторы ClientID) с их транзакциям и отображались в отчетах.


Нам удалось дополнить существующие отчеты в CRM GetCourse, разобраться в протоколах передачи данных на сторону аналитических систем и увидеть в отчетах данные о доходах.

Рис. 7. Отчет из системы Google Analytics по транзакциям и доходам

Рис. 8. Отчет Яндекс.Метрики о факте передачи данных по конверсиям (транзакциям) и их ценность (доход)

Решение поставленных задач помогло сделать шаг навстречу идеальной системе сквозной аналитики, когда в аналитических системах есть подробные данные об источниках лидов и совершенных ими оплатах. Все это поможет в дальнейшем улучшать показатели бизнеса.