Measurement ломается не в отчёте, а на этапе события: проверь 7 мест до запуска

Measurement ломается не в отчёте, а на этапе события: проверь 7 мест до запуска

Сначала фиксируйте не «как отправить event», а где он может исказиться. Типовые точки отказа: дубли из разных триггеров, отсутствие уникального ключа, разные названия у одного действия, пустые параметры, отправка до загрузки consent, а также потеря данных при SPA-переходах и редиректах.

Дальше идёт контроль структуры. Для каждого ключевого события заранее задайте: event_name, обязательные параметры, типы значений, правило дедупликации и источник правды — GTM, сервер или приложение. Если одно и то же действие можно поймать двумя способами, выбирайте один primary-path и второй оставляйте только как fallback.

На практике помогает простой чек-лист перед релизом:
• событие не стреляет дважды
• параметр transaction_id / order_id всегда уникален
• в dataLayer нет «плавающих» имён
• consent не режет критичные события молча
• в DebugView и raw-данных совпадают счётчики

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

Если хотите, чтобы measurement жил дольше одной кампании, проектируйте его как контракт: одно действие — одно имя — один источник — одна схема параметров.