Как хранить историю залива команды так, чтобы отчёты не развалились на третьем месяце

Как хранить историю залива команды так, чтобы отчёты не развалились на третьем месяце

История залива — это не таблица с «сводкой по дням», а поток событий. Если складывать всё в один лист, быстро получите дубли, ручные правки и конфликт версий. Нормальная схема начинается с трёх слоёв: raw-слой для сырых API-ответов и постбеков, staging для очистки и дедупликации, mart для витрин под BI.

В raw сохраняйте всё как есть: campaign_id, adset_id, account_id, timestamp, event_type, payload. Не агрегируйте и не перезаписывайте строки. Это ваш аудит-трейл, который позволяет восстановить спорный клик, отловить потерянный постбек и проверить, где именно течет профит? Данные не врут, в отличие от байеров.

В staging приводите ключи к единому формату: UTC-время, одинаковые названия полей, нормализованные статусы, отдельные таблицы для кликов, конверсий, расходов и апрувов. Здесь же делайте дедупликацию по business key: источник + внешний id + тип события. Без этого любая повторная отправка API-хука превращает отчёт в мусор.

Для команды нужна не «общая база», а модель с правами: одна fact-таблица по событиям, справочники по офферам, связкам и трафик-источникам, партиционирование по дате и индексы по account_id/campaign_id. Тогда можно быстро ответить на вопросы: кто льёт, что льёт, где просадка, какая связка ушла в минус. Всё, что не автоматизировано — это потенциальный убыток.

Стройте хранение так, чтобы любой отчёт собирался из сырых логов и проверялся запросом в SQL, а не ручной сверкой в таблице.