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

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

Когда sGTM начинает собирать события из нескольких источников, BigQuery быстро превращается не в “лог”, а в основной слой разборов. Ошибка здесь одна: складывать всё в одну сырую таблицу без правил по ключам и типам.

Что нужно зафиксировать сразу:
— event_id для дедупликации Pixel + CAPI
— event_name, event_time, user_pseudo_id, client_id
— отдельные поля под fbp, fbc, click_id, IP, User-Agent
— raw payload в JSON или STRING, но не вместо нормализованных колонок

Если хранить только сырой body, вы быстро упрётесь в боль:
— тяжело считать deduplication rate
— сложно искать расхождения между client-side и server-side
— EMQ и матчинг по CAPI приходится разбирать вручную

Хорошая практика — разделить слой на два уровня:
— raw: всё, что пришло от клиента или из sGTM
— normalized: уже распарсенные поля для аналитики и QA

Для больших объёмов сразу закладывайте:
— партиционирование по event_date или event_timestamp
— кластеризацию по event_name, event_id, source
— единые правила нормализации email/phone до хеширования

Так BigQuery становится не “складом мусора”, а источником для сверки атрибуции, качества матчинг-данных и контроля потерь на каждом этапе. Чем раньше вы наведёте порядок в схеме, тем меньше будет ручного дебага через месяц.