Data Layer: как в BigQuery-аналитике не «замораживать» значение переменной на момент события

Data Layer: как в BigQuery-аналитике не «замораживать» значение переменной на момент события

Если вы отправляете в BigQuery события из Google Tag Manager (GTM), важно помнить: у GTM Data Layer переменные по триггеру обычно “замораживаются” в состояние именно на момент, когда сработало событие. Это надёжно, пока бизнес-логика одна и та же для всех тегов. Но в маркетинге часто возникает потребность взять “самое актуальное” значение на момент выполнения тега/обработки — и тогда стандартный подход мешает.

Чек-лист для правки схемы передачи в BigQuery:

— Разведите “значение на событии” и “значение сейчас”
Определите, какие поля должны соответствовать конкретному действию пользователя (например, UTM на момент клика), а какие — актуальному контексту (например, текущий статус воронки).

— Проверьте, какие теги полагаются на Data Layer переменные
Если несколько тегов и переменных рассчитываются на одном триггере, проверьте, что все они действительно должны видеть одно и то же значение.

— Добавьте отдельный этап обновления контекста перед нужным тегом
Схема: событие фиксирует факт, но “контекстные” поля подтягивайте отдельным обновлением Data Layer до конкретного тега/серии тегов.

— Транслируйте “актуальное значение” в отдельные поля события в BigQuery
Вместо перезаписи исходного поля создайте новое (например, `campaign_current` рядом с `campaign_at_event`), чтобы не ломать воспроизводимость атрибуции.

— Сделайте валидацию в BigQuery на согласованность значений
Постройте проверки: различаются ли `*_at_event` и `*_current` в реальных сессиях, и совпадает ли это с ожидаемым поведением (например, при смене статуса после загрузки страницы).

— Зафиксируйте логику в документе схемы атрибутов
Коротко пропишите правила: какое поле всегда “на момент триггера”, какое — “после обновления контекста”, и для каких отчётов каждое используется.

— Проверьте влияние на отчёты маркетинга и RevOps
Если у вас выстраиваются MQL/SQL-переходы (в стиле Revenue Operations, ответственность за выручку), убедитесь, что вы не подменяете историческое значение на текущее и не искажаете cohort/воронки.

когда это пригодится: когда в цепочках GTM→BigQuery вы замечаете несостыковки между UTM/статусом/кампанией в разных тегах, хотя событие одно и то же.

— @BigQuery4MarketingPro