HOFF. Внедрение DataGo! Web Streaming в Yandex Cloud
В этом кейсе мы расскажем, как мигрировать аналитический проект, какие этапы проекта требуется пройти, чтобы получить отчетность в безопасном стеке.
На примере реализации проекта 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 на сайте.
- Обеспечить аналитикам более привычную структуру данных для комфортной адаптации отчетности.
- Выгрузить исторические данные и обеспечить их сходимость за счет пересчета сеансов за ретро-период.