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

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

Если история залива лежит в одном листе, через месяц там уже нет ни сходимости, ни нормальной дедупликации. Нужна схема с раздельными слоями:
— raw: сырые ответы API, постбеки, логи кабинетов;
— normalized: единые поля campaign/adset/creative, приведение валют, таймзон и статусов;
— mart: витрина для BI, где считаются CPI, ROI, CR, spend, revenue, delta.

Ключевая идея: не перезаписывать факт, а версионировать его. Каждое событие должно иметь source_id, event_time, loaded_at и hash_payload. Это позволяет ловить повторные постбеки, разъехавшиеся статусы и ручные правки. Данные не врут, в отличие от байеров, но только если вы не стираете историю загрузок.

На уровне таблиц нужны партиционирование по дате события и индексы по campaign_id, team_id, offer_id. Для сравнения кабинета и трекера держите отдельную таблицу reconciliation: там сходятся spend, leads, approvals и payout. Проверяем сходимость дельты в трекере и кабинете без Excel-магии.

Если команда большая, не складывайте всё в одну сущность «кампания». Разделяйте кампанию, связку, креатив, оффер, поток и команду. Иначе любая аналитика по открутке превращается в ручной аудит логов.

Схема проста: raw для хранения, normalized для чистки, mart для решений. Всё, что не автоматизировано — это потенциальный убыток.