Как сеть магазинов обуви Rendez-Vous перешла на Яндекс Тег Менеджер и подтвердила качество передаваемых данных

Яндекс Метрика собирает основные события на сайте автоматически. Но для детального анализа маркетинговых активностей и поведения пользователей бизнесу часто нужны дополнительные данные: достижения целей, действия с товарами, параметры визитов, данные о заказах и другие события, которые зависят от специфики сайта и задач компании.

Чтобы эти данные попадали в аналитику, на сайте нужно настроить разметку: определить, какие действия пользователей нужно фиксировать и какие параметры передавать вместе с ними. Управлять такой разметкой можно через менеджер тегов — он позволяет добавлять и обновлять теги, триггеры и переменные без постоянных изменений в коде сайта.

Поэтому при переходе с одного менеджера тегов на другой важно не только перенести настройки, но и убедиться, что события продолжают передаваться корректно. Рассказываем, как Rendez-Vous с агентством MGCom решили эту задачу без негативного влияния на бизнес-метрики.

Какую цель поставили

Rendez-Vous нужно было заменить Google Tag Manager новым менеджером тегов. Компания хотела получить решение, которое соответствует актуальным требованиям к инфраструктуре, поддерживает нужную логику событий и может быть встроено в уже существующий аналитический стек без потери данных.

Какое решение выбрали

Перед переходом команда агентства провела сравнительный анализ доступных решений для управления тегами. Специалисты оценивали инструменты по нескольким критериям:

По итогам анализа выбрали Яндекс Тег Менеджер.

На выбор Яндекс Тег Менеджера повлияло несколько факторов:

• Инструмент встроен в экосистему Яндекса, логично дополняет работу с Метрикой и постоянно развивается.
• Интеграция не требует полной перестройки аналитической архитектуры.
• Интерфейс и логика работы близки привычной модели тег-менеджмента.
• Решение соответствует требованию клиента работать на базе российской инфраструктуры.

Rendez-Vous было важно не просто выбрать отечественную альтернативу, но и убедиться, что переход не ухудшит качество данных. Поэтому следующим шагом стал параллельный запуск Google Tag Manager и Яндекс Тег Менеджера на реальном трафике.

С какими сложностями столкнулись

Главный риск перехода — возможные расхождения в данных. Если новый менеджер тегов начал бы фиксировать события иначе, бизнес и аналитики могли бы получить некорректную картину по целям, конверсиям и другим метрикам.

Команде важно было понять:

• Как система работает на реальном трафике
• Сохраняется ли качество данных в разных браузерах
• Совпадают ли объёмы достижения целей за длительный период
• Не появляются ли расхождения после публикации из-за разной скорости загрузки скриптов или особенностей браузеров

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

Как переходили на новое решение

Чтобы исключить риски потери данных, команда запустила Google Tag Manager и Яндекс Тег Менеджер параллельно. Работа велась в несколько этапов:

1. Перенос структуры контейнера Google Tag Manager в Яндекс Тег Менеджер. В Яндекс Тег Менеджере опубликовали теги, а также настроили идентичные триггеры и переменные по аналогии с инструментом Google.
2. Параллельный сбор данных. Теги последовательно были опубликованы в Яндекс Тег Менеджере и одновременно приостановлены в Google Tag Manager. Каждое изменение сопровождалось проверкой корректности работы на сайте.
3. Контрольная реализация события напрямую через код сайта. Для одного действия были настроены идентичные цели через Google Tag Manager и Яндекс Тег Менеджер, а также подготовлено ТЗ для внедрения аналогичного события напрямую в код сайта.
4. Поэтапная валидация данных. После реализации сопоставили срабатывания целей в Яндекс Метрике с фиксированием отклонений в данных.

Такой подход позволил сравнить работу двух инструментов на реальном трафике и проверить, насколько корректно новая система воспроизводит логику прежнего решения.

Какие результаты получили

Тест длился 1 месяц. За это время системы зафиксировали:

• Яндекс Тег Менеджер — 29 521 достижение целей
• Google Tag Manager — 29 512 достижений целей

Тест относительно кода сайта длился 1 неделю. За это время системы зафиксировали:

• Яндекс Тег Менеджер — 4 939 достижений целей
• Google Tag Manager — 4 886 достижений целей
• Код сайта — 4 908 достижений целей

Разница между системами в сумме за период составила от 0,45 до 1,1%, что укладывается в допустимую погрешность для тег-менеджеров.

При этом конверсия полностью совпала. Это подтвердило, что переход не повлиял на бизнес-метрики.

Почему возникли расхождения

Небольшие отклонения ожидаемы для таких проверок. Они связаны с техническими особенностями работы систем.

На расхождения могли повлиять:

• Разная скорость загрузки скриптов. Даже несколько миллисекунд могут изменить момент отправки события при быстрых действиях пользователя.
• Особенности браузеров и расширений. Например, один тег-менеджер мог быть заблокирован на стороне пользователя, а второй — нет.
• Порядок выполнения тегов. Может одновременно выполняться несколько скриптов, и последовательность их запуска не всегда совпадает. В зависимости от очерёдности выполнения тегов событие может отправиться на доли секунды раньше или позже.
• Отличия контейнерных решений от реализации через код сайта. Контейнерные решения добавляют дополнительный этап обработки события через систему тег-менеджера. В случае прямой отправки через код сайта этот этап отсутствует.

Эти расхождения не влияют на качество аналитики.

Выводы

Переход с Google Tag Manager на Яндекс Тег Менеджер выполнили без потери данных.

В ходе работы над проектом удалось подтвердить, что:

• Качество сбора событий полностью сохранилось
• Яндекс Тег Менеджер стабильно работает в краткосрочной и долгосрочной перспективе
• Решение готово к масштабированию

Для бизнеса это даёт несколько преимуществ:

• Снижение зависимости от зарубежных инструментов
• Соответствие требованиям к хранению данных
• Прозрачная интеграция с Яндекс Метрикой
• Снижение рисков при дальнейшем масштабировании аналитики

В результате Rendez-Vous не просто заменил один инструмент другим, а подтвердил качество нового решения на реальных данных.

Дополнительные материалы