<b>BigQuery как хранилище server-side событий: когда это лучше логов и CSV</b>

<b>BigQuery как хранилище server-side событий: когда это лучше логов и CSV</b>

Если sGTM уже шлёт события на несколько endpoint’ов, BigQuery удобно использовать как слой сырого факта. Не как отчётный BI-слой, а как место, где лежит полный event stream: входящие payload’ы, debug-флаги, ошибки валидации, повторные отправки.

Главное правило: в таблицу надо писать не только “успешные” события. Иначе вы теряете возможность искать, почему рассыпались дедупликация, match_keys или routing. Полезно хранить:
— event_name, event_id, timestamp
— user_data в хэшированном виде
— fbp/fbc, ip, user_agent
— source, client_id, request_id, status_code
— raw_payload в отдельном поле или отдельной таблице

Структурируйте хранение сразу. Для аналитики по времени — партиционирование по дате события. Для быстрых разборов — кластеризация по event_name, event_id, request_id. Если кладёте всё в одну широкую таблицу, следите, чтобы raw JSON не ломал стоимость запросов.

Практика, которая спасает дебаг:
— одна таблица для “чистых” событий
— одна таблица для ошибок и невалидных запросов
— одно поле для correlation id между sGTM, CAPI и downstream-системами

Такой слой позволяет быстро сравнить: что пришло на вход, что ушло в Meta/Google/TikTok, и где именно событие потерялось. Для server-side атрибуции это часто важнее, чем сама витрина в Looker.

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