-
Карта
События, цели и условия
-
Перенос
Теги и триггеры нового контейнера
-
Тест
Одно действие — одно событие
-
Запуск
Отключение прежних обработчиков
Переход с Google Tag Manager на Яндекс Тег Менеджер начинается с инвентаризации событий. Сначала определите, что и когда отправляется, затем перенесите переменные и триггеры, проверьте их на тестовой выборке и только после этого отключите старую отправку. Одновременно работающие одинаковые теги могут считать одну заявку дважды.
Составьте карту событий
Откройте контейнер GTM и код сайта. Счётчик может быть установлен одновременно в шаблоне, модуле CMS и менеджере тегов. Поэтому экспорт одного контейнера не даёт полной картины. Для каждого события запишите источник, условие срабатывания, получателя и способ проверки.
| Событие | Когда отправляем | Как проверяем |
|---|---|---|
| Открытие формы | Пользователь открыл окно | Один сигнал за открытие, не заявка |
| Заявка принята | Сервер подтвердил сохранение | Есть локальный ID обращения |
| Заказ создан | Сохранён заказ с ID | Сумма и товары совпадают с заказом |
| Ошибка формы | Отправка не завершилась | Не увеличивает успешные заявки |
Названия в таблице условные: оставьте действующие имена, если они уже используются в отчётах и рекламных стратегиях. Переименование цели одновременно с переносом усложнит сравнение. Важнее исправить смысл: клик по кнопке и принятое сервером обращение — разные события.
Отделите событие сайта от аналитического тега
Data Layer служит договором между разработчиком и аналитиком. Приложение сообщает, что произошло, а менеджер тегов решает, куда передать разрешённые данные. Не привязывайте основную конверсию к случайному CSS-классу кнопки: после редизайна он может исчезнуть.
Учебный вариант события после успешного ответа сервера: dataLayer.push({event: 'lead_saved', form_type: 'consultation'}). Он не содержит телефона, email или текста обращения. Реальное имя слоя, порядок загрузки контейнера и переменные должны соответствовать используемой платформе; один пример нельзя без проверки вставлять в любой сайт.
При повторной отправке обработчик должен понимать, что обращение уже сохранено. Иначе защищённая от дублей CRM получит одну сделку, а аналитика — две конверсии. Свяжите обработку события с успешным состоянием заявки, а не с каждым повторным ответом интерфейса.
Переносите теги небольшими группами
Начните с измерений, которые проще проверить: открытие страницы и служебное тестовое событие. Затем перенесите формы и электронную коммерцию. Для каждой группы проверьте соответствие переменных, ограничения запуска и условия согласия пользователя. Не переносите устаревшие пиксели только потому, что они лежали в контейнере.
В Яндекс Тег Менеджере изменения тегов и их состояния нужно публиковать. Сохранённая настройка и работающая версия — не одно и то же. Запишите номер версии до изменения, содержание релиза и способ возврата к предыдущему варианту.
Параллельная проверка не означает двойную отправку в рабочую цель. Используйте отдельный тестовый получатель либо режим проверки без записи в рабочую статистику. После сверки выключите старый тег и убедитесь, что он не остался в другом контейнере или коде CMS.
Матрица проверки после переключения
- Первый визит с отказом от необязательной аналитики: соответствующие теги не запускаются.
- Разрешение аналитики: нужные события начинают передаваться по принятой политике.
- Ошибка обязательного поля: успешной заявки нет.
- Успешная форма: одно событие и одна сохранённая заявка.
- Повторное нажатие, обновление страницы и возврат назад: нет повторного заказа.
- Мобильное меню, модальная форма и обычная страница: события имеют одинаковый смысл.
В журнале сети проверяйте не только количество запросов, но и получателя, имя события и значения параметров. Скриншот «тег сработал» не подтверждает, что в отчёт ушли правильные данные. Через сопоставимый период сравните принятые заявки с CRM по единому определению конверсии.
Когда перенос не решит проблему
Менеджер тегов не исправляет потерю UTM при переходе между доменами, отсутствие статусов сделок и ошибки отправки форм. Эти задачи требуют изменения сайта и CRM. Для связи рекламы с квалифицированными обращениями и оплатами используйте схему Метрика → Битрикс24 → продажа. Если нужен план внедрения, начните с сквозной аналитики.
Что записать в карту событий перед переносом
Для каждого события укажите бизнес-смысл, место возникновения, условия запуска, параметры и назначение. Например, «заявка принята» возникает после успешного ответа серверной формы, а «нажатие кнопки отправки» — до валидации. Если перенести оба триггера в одну цель, число обращений станет больше числа сохранённых заявок. Сначала исправьте смысл измерения, затем переносите техническую реализацию между контейнерами.
Отдельной строкой отметьте страницы, где счётчик установлен напрямую в шаблоне, и страницы, где он загружается менеджером тегов. Проверьте корзину, поддомены, личный кабинет и страницы оплаты. Они могут использовать разные шаблоны и разные разрешения на запуск скриптов. Наличие тега на главной не означает, что он работает во всём процессе покупки.
В параметрах оставляйте только данные, необходимые для отчёта. Название инструмента или тип формы полезны для группировки. Телефон, email, свободный текст обращения и полный URL с секретным параметром передавать в обычную веб-аналитику не нужно. Для передачи идентификаторов клиентов и офлайн-событий используется отдельный согласованный процесс с правилами обработки данных, а не произвольное добавление полей в Data Layer.
Учебная приёмка одного события
Откройте страницу в чистой сессии и запишите действия: пустая отправка, ошибка телефона, успешная отправка, повторное нажатие и обновление страницы. Сравните список событий в отладчике с сохранёнными тестовыми обращениями. Пустая форма и ошибка контакта не должны становиться успешной заявкой. Обновление страницы с сообщением «спасибо» не должно повторно фиксировать ту же отправку.
Затем повторите сценарий с выбранными настройками согласия на аналитику. Перенос контейнера не должен менять согласованный режим обработки данных. Если часть тегов запускается после согласия, это условие сохраняют и проверяют отдельно. Не оценивайте корректность только по появлению сетевого запроса: проверьте название цели и параметры конкретного события.
Перед переключением сохраните предыдущую конфигурацию и опишите возврат к ней. Включайте новый вариант вместе с отключением прежних обработчиков по согласованному плану. После публикации сверьте счётчик с серверным числом принятых обращений за один интервал: различия требуют разбора, но сами по себе не означают, что одна из систем обязательно неисправна.
