BigQuery как хранилище server-side событий: не склад, а слой контроля качества

BigQuery как хранилище server-side событий: не склад, а слой контроля качества

Если sGTM шлёт события в BigQuery «на всякий случай», через месяц вы получаете не аналитику, а дорогой мусорный ящик. Рабочая схема другая: сырые события кладём отдельно от нормализованных, а в витрину — только то, что прошло проверку на schema, dedup и обязательные поля.

Что важно хранить:
— raw payload целиком: чтобы пересобрать логику маппинга без повторной отправки
— event_id, client_id, user_id, fbp/fbc: для склейки и поиска дублей
— timestamp received / timestamp event: чтобы видеть лаги между браузером, сервером и DWH
— routing metadata: какой client, tag template, source domain, trigger

Дальше строится простой контроль:
— `COUNT(*)` vs `COUNT(DISTINCT event_id)` — ловит дубляж
— `NULL` по email_hash/phone_hash — показывает, где ломается enrichment
— доля событий без `user_agent` или `ip` — сигнал, что server context теряется
— сравнение inbound и outbound объёма по каждому event_name — помогает найти обрыв в маршрутизации

Главная ошибка — использовать BigQuery как единственный источник истины для CAPI. Истина там только после нормализации: один и тот же `Purchase` может прийти три раза с разным quality, а в хранилище это будут три строки. Поэтому raw и curated должны жить отдельно.

Если держать BigQuery как слой проверки, а не свалку, вы быстрее находите потери в sGTM и не спорите с отчётами — вы видите, где именно сломалась цепочка.