Смена источника данных для сквозной аналитики: внедрение DataGo! Web Streaming в Yandex Cloud на проекте Hoff

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

На примере реализации проекта Hoff разберем:

  • с какими сложностями мы столкнулись при замене стриминга web данных и какие выводы удалось сделать;
  • какие требования накладывают на проект действующие процессы маркетинговой аналитики;
  • каких результатов удалось добиться при завершении проекта.

Причины миграции аналитического проекта

В 2022 году многие российские компании столкнулись с наложенными ограничениями на аналитические сервисы Google, такие как:

  • Невозможность продлить или активировать лицензию Google Analytics 360. Это привело к потере привычного источника данных для аналитики компании.
  • Возникновение сложностей с оплатой Google Cloud Platform. Как следствие, высокие риски потери ретро-данных и возможная блокировка аналитического проекта.
  • Рост санкционных ограничений. Это накладывало риск возможной блокировки сервисов Google и других иностранных поставщиков.

Ожидание команды Hoff от миграции

  • Маркетинг продолжает принимать решения на основе данных без потери привычной отчетности. Сохранение привычной структуры отчетности - важная часть любого миграционного проекта, позволяющая маркетологам и аналитикам проекта минимизировать ресурсы на построение необходимой отчетности и интерпретацию результатов.
  • Бизнесу доступно сравнение периодов год-к-году в привычной детализации. Это важный аспект отслеживания и фиксации результатов в разрезе необходимых периодов.
  • Не допустить разрыв в сборе данных и получении маркетинговой аналитики. Потеря части аналитических данных или маркетинговой аналитики может привести к принятию неверных решений и потере бюджетов, что может быть критичным для бизнеса.
  • Импортировать ретро-данные и обеспечить сходимость. Использование накопленных исторических данных помогает собирать необходимую статистику и принимать управленческие решения.

Какие вопросы возникали при реализации проекта миграции?

В ходе реализации проекта по миграции на альтернативный стек всегда возникают дополнительные вопросы, ответы и решение которых нужны “здесь и сейчас”. Мы скомпоновали основной пул вопросов, влияющих на конечный результат и требующих своевременного решения в нашем кейсе.

Стоит отметить, что каждый процесс импортозамещения или миграции на альтернативный стек индивидуален, и у специалистов, участвующих в вашем проекте, могут возникать другие вопросы. Как правило, это зависит от целей бизнеса, конечного желаемого результата, исходных данных, необходимого ресурса (сотрудников, бюджетов, сроков и т.д.) и многих других факторов.

Вопрос 1: Как не допустить разрыва в получении отчетности?

  • Упростили интеграцию веб-трекера при отказе от Universal Analytics за счёт переиспользования существующего на сайте dataLayer и отправки данных через Measurement Protocol. Это способствует минимизации использования ресурса на переразметку сайта.
  • Упростили переработку отчетности, предоставили данные в привычной аналитикам структуре (близкой к Universal Analytics 360). Это занимает меньше ресурса аналитиков для адаптации отчетности.

Вопрос 2: А мы получим те же самые данные и как?

  • Мы переиспользовали сбор данных через ранее внедренный на сайте dataLayer. Сырые данные будут переданы в формате бесшовной стыковки без прерываний, что минимизирует ресурсы команды на работу с ними.
  • Рассчитали сессионные данные по алгоритму, близкому к логике источника до миграции. Это позволит сохранить текущую структуру данных, чтобы не изменять формат отчетности.

Вопрос 3: А как нам сравнивать данные год-к-году?

Как решили:

  • Импортировали хитовые данных предыдущего стриминга из GBQ в ClickHouse с сохранением структуры.
  • Рассчитали сессии алгоритмом стриминга DataGo! за ретро-период на исторических данных.

Это позволило нам импортировать исторические данные в новое хранилище и обеспечить их сходимость.

С какими вызовами столкнулись на проекте Hoff?

Для успешной реализации любого аналитического проекта необходимо заранее оценить все подводные камни, с которыми можно столкнуться в ходе работ. В этом кейсе мы подсветим основные моменты, с которыми столкнулись специалисты DataGo! и DataGo! Consulting и расскажем, как удалось их решить.

Вызов 1: Не сходится разбивка по кампаниям/каналам

Например: Меньше сессий в органике или платном трафике, значительно больше сессий в прямом трафике в сравнении с Google Analytics. Как следствие, маркетингу недоступна оценка эффективности каналов в сравнении с историческим периодом.

В чем причины

  • Для корректной работы логики Last-Non-Direct-Click необходима история посещения сайта пользователем
  • В Google Analytics стандартный период атрибутирования источников трафика (ожидание рекламной кампании) для одной куки составляет 6 месяцев
  • После подключения стриминга прошло недостаточно много времени, чтобы корректно и полно идентифицировать источники трафика

Что важно учесть

  • Переключение отчетности на данные нового стриминга рекомендуется не раньше, чем через месяц после начала сбора данных, в идеале - до 6 месяцев
  • Проводить сверку распределения трафика по каналам целесообразно не ранее, чем через 2 недели

Вызов 2: Органика из Яндекса выглядит завышенной

Ситуация: Данные собираются уже больше месяца, но yandex/organic показывает больше сессий в сравнении с GA. Это формирует недоверие к полученным данным.

В чем причины

Стриминг DataGo! идентифицирует источник, как yandex/organic вместо привычного в GA yandex/referral (фича, а не баг)

Вывод

Это ожидаемо, т.к. yandex/referral определялся Google некорректно. Многие проекты настраивали переопределение источника.

Вызов 3: Данных в стриминге стало больше на 2-5%

Ситуация: Равномерное увеличение хитов в любых срезах на 2-5% в сравнении с Google Analytics. Это вызывает недоверие к полученным данным.

В чем причины

Стриминг DataGo! не блокируется частью блокировщиков рекламы и не ограничивает размер хита 8Kb. Это позволяет собирать больше данных (= меньше терять).

Вывод

Это ожидаемое расхождение.

Вызов 4: Хитов собирается столько же, но сессий стало меньше

Ситуация: Количество хитов/событий совпадает с Google Analytics, при этом количество сессий меньше. Это формирует недоверие к полученным данным.

В чем причины

DataGo! по-умолчанию корректно обрабатывает переходы пользователей на платежные шлюзы и обратно без необходимости кастомных настроек.

Как решили

Пришли к выводу, что логика сессий DataGo! более корректно связывает хиты в сеансы (без разрывов) и вместе с Hoff и Aero пересчитали ретро период за 2 года по новому алгоритму.

Вызов 5: Не совпадают форматы данных в OWOX BI и DataGo! Streaming в связке: IP-адрес и геолокация пользователя

Ситуация: название городов в стримингах OWOX и DataGo! пишутся по-разному, например St.Petersburg и Saint-Petersburg. Это мешает построению ретро-отчетности.

В чем причина

Формат присвоения определенным IP-адресам геолокацию у стриминга OWOX BI, который был установлен у компании Hoff, отличался от формата, который предоставлял DataGo! Streaming.

Как решили

Специалисты DataGo! Consulting сформировали словарь соответствия, позволяющий присвоить всем ранее собранным IP-адресам геолокацию в новом формате DataGo! Streaming, при этом без нарушения структуры итоговой отчетности.

Результаты Hoff

  • Маркетинг Hoff принимает решения о распределении бюджета на привычных для команды отчетах.
  • Аналитикам Hoff доступны к использованию привычные сервисы за счет сохранения исторических данных в новом хранилище.
  • Бизнесу Hoff доступен ретро-период для оценки результатов в формате “Год к году”.

Что важно учесть в реализации миграционного проекта

  • Рекомендация минимизировать время на интеграцию за счет переиспользования ранее внедренного dataLayer на сайте.
  • Обеспечить аналитикам более привычную структуру данных для комфортной адаптации отчетности.
  • Выгрузить исторические данные и обеспечить их сходимость за счет пересчета сеансов за ретро-период.