BigQuery для sGTM: как хранить события так, чтобы потом не чинить атрибуцию

BigQuery для sGTM: как хранить события так, чтобы потом не чинить атрибуцию

BigQuery в server-side трекинге лучше использовать не как «лог всего подряд», а как слой сырья для проверки атрибуции: что пришло в sGTM, что ушло в CAPI / Events API / GA4, где потерялся event_id.

Минимальная схема:
— event_name, event_time, event_id
— client_id, user_id, external_id_hash
— fbp, fbc, gclid, ttclid
— ip_country, user_agent_hash
— destination, status_code, payload_hash

Две таблицы удобнее одной: raw_events — неизменяемый входящий поток из sGTM; sent_events — факт отправки в рекламные API. Между ними легко считать потери, дубли, задержку и расхождения по статусам.

Для стоимости и скорости: партиционирование по event_date, кластеризация по event_name и event_id. PII не хранить в чистом виде: email/phone нормализовать и SHA-256 до записи.

Главное правило: BigQuery должен отвечать на вопрос «почему платформа не увидела событие», а не просто копить JSON. Начните со схемы под дебаг, а не под красивый дашборд.