Мы привыкли, что сквозная аналитика востребована в крупном ритейле, и для ее обеспечения используются большие сложные CRM. Однако этот кейс демонстрирует, что связь транзакций и источников лидов интересует всех, кто хочет грамотно подходить к маркетингу. Даже модных блогеров, чьи сайты созданы на Tilda, а используемая CRM ограничена в функционале.
В агентство MediaNation обратилась онлайн-школа стилиста Насти Ерасовой – «Разборки в моде» с задачей настройки системы аналитики, которая позволяла бы оценивать доход от рекламной активности. Школа предлагает курсы, марафоны, вебинары, посвященные теме моды и стиля.
Онлайн обучение проходит на платформе GetCourse. Помимо организации и проведения самих занятий, платформа предлагает свою CRM-систему, которая дает возможность принимать платежи, сегментировать клиентов, анализировать продажи и ключевые показатели.
Казалось бы, этого достаточно для того, чтобы получить внятную аналитику. Однако система не позволяет определить источник продажи, и, как следствие, эффективность рекламных каналов.
Настя Ерасова, создатель проекта
- реализовать сбор данных аналитических систем (Google Analytics и Яндекс.Метрики) на стороне CRM–сервиса GetCourse;
- реализовать передачу данных об оплаченных заказах из CRM в Google Analytics и Яндекс.Метрику.
Аудит инструментов и оценка возможных сценариев передачи данных
Первое решение, которое напрашивалось, – собирать данные о транзакциях через коды электронной торговли, установленные на страницах «Корзина», «Оплата», «Спасибо за заказ».
Но это решение не удалось реализовать. Во-первых, несмотря на то, что после оплаты услуг онлайн-школы через Robokassa и PayPal пользователи могли вернуться на сайт (через редирект или нажав на кнопку «Вернуться в магазин»), это делали не все. Клиенты часто закрывали страницу системы оплаты, так и не перейдя к финальной странице «Спасибо за заказ».
Во-вторых, хотя переход на финальную страницу «Спасибо за заказ» и был возможен, выяснилось, что на ней не было полезной информации – ни номера заказа, ни оплаченной суммы. Добавить такие данные через разработчиков было нельзя и соответственно нельзя было их получить автоматически с помощью какого-либо скрипта.
Учитывая эти ограничения, мы решили собирать необходимые нам данные в CRM-системе GetCourse и передавать их в системы аналитики.
GetCourse позволяет работать с информацией по трафику и цепочкам взаимодействия пользователей. Однако многие данные собираются не так, как привыкли маркетологи, работая с традиционными аналитическими системами. Например, в базовом профиле пользователя источником трафика указывается домен сайта, а параметр канала – реферальный трафик. Это не позволяло оценить источники переходов на сайт и эффективность различных рекламных каналов.
Несмотря на это, с профилем можно было работать, внеся в алгоритм сбора данных некоторые изменения.
Этап 1: сбор данных о заказе
Регистрационная форма – точка сбора данных о клиенте (имя-емейл-телефон). Нам было необходимо, чтобы в ней дополнительно собиралась корректная информация об источнике перехода на сайт, а также данные аналитических систем.
Мы создали код на 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 – который ускорил и упростил решение задачи, и тем самым снизил для заказчика стоимость наших услуг.
Пример дополнительных скрытых полей в регистрационной форме. GetCourse
Часть кода в Google Tag Manager, который показывает, по каким правилам будут обработаны данные и переданы в соответствующие поля регистрационной формы.
В итоге необходимые данные об источниках перехода появились в CRM в карточках клиентов и их заказах.
Карточка клиента с созданными дополнительными полями. GetCourse
Страница с заказами и созданными дополнительными полями. GetCourse.
На этапе разработки скрипта для передачи данных в поля форм мы столкнулись со следующей проблемой: страница сайта и всплывающее окно регистрационной формы находились на разных поддоменах третьего уровня (domain.site.ru), что не позволяло передавать данные через cookies. Эта проблема была связана с кросс-доменным ограничением (Same Origin), цель которого – безопасность при работе с вкладками браузера. Мы пытались решить эту проблему через Cross-Origin Resource Sharing (CORS) на стороне GetCourse, но техподдержка платформы не смогла нам в этом помочь. Однако мы нашли выход. Поскольку лендинг и форма заявки находились на поддоменах третьего уровня, все ограничения можно было снять, добавив на оба сайта код document.domain = 'site.com'. Так мы и сделали: код был прописан в наш основной скрипт, который запускался на каждом поддомене через Google Tag Manager.
Основной сайт и всплывающее окно (iframe) регистрационной формы на другом поддомене с консолью отладки Google Tag Manager.
Благодаря доработке скрипт из всплывающего окна (iframe) может прочитать cookies внешнего сайта и получить данные по UTM-меткам.
Этап 2: передача данных о заказе
Следующим шагом стало создание алгоритма, по которому данные из CRM передавались на сервер MediaNation для дальнейшей обработки. Мы использовали функционал «Процессы» в платформе GetCourse, в котором описали правила передачи информации о состоявшихся оплатах.
Визуальное отображение внутреннего функционала «Процессов» (правил передачи данных) с указанием сайта, на который будут отправляться данные из CRM.
В данном случае использовался сервер с техническим доменом MediaNation, который собирал отправленные данные.
В итоге общая схема сбора и передачи информации выглядела следующим образом:
- Google Tag Manager запускал скрипт для записи в поля форм данных об идентификаторах аналитических систем и UTM-метках.
- Данные пользователей сайта и их конверсии передавались в аналитические системы. Но не передавались данные по доходу и транзакции.
- Данные о заказе, клиенте и источнике перехода на сайт передавались в CRM GetCourse.
- GetCourse передавал данные на сервер MediaNation, где они преобразовывались в соответствующий каждой аналитической системе (Google Analytics и Яндекс.Метрике) формат.
- Преобразованные данные отправлялись в каждую систему аналитики по своими протоколам:
5.1. передача данных в Google Analytics через Measurement Protocol;
5.2. передача данных в Яндекс.Метрику через офлайн–конверсии.
На стороне аналитических систем данные по трафику пользователей «склеивались» (через идентификаторы ClientID) с их транзакциям и отображались в отчетах.
В итоге
Нам удалось дополнить существующие отчеты в CRM GetCourse, разобраться в протоколах передачи данных на сторону аналитических систем и увидеть в отчетах данные о доходах.
Отчет из системы Google Analytics по транзакциям и доходам
Отчет Яндекс.Метрики о факте передачи данных по конверсиям (транзакциям) и их ценность (доход)
Решение поставленных задач помогло сделать шаг навстречу идеальной системе сквозной аналитики, когда в аналитических системах есть подробные данные об источниках лидов и совершенных ими оплатах. Все это поможет в дальнейшем улучшать показатели бизнеса.
Теги:
