Архитектура базы для истории залива команды: без ручных таблиц и потери контекста

Архитектура базы для истории залива команды: без ручных таблиц и потери контекста

История залива — это не одна таблица с кликами. Нужны минимум 4 сущности: campaigns, adsets, creatives, daily_facts. В campaigns хранится статика, в daily_facts — факты по дням: spend, leads, revenue, clicks, installs. Ключи связи должны быть стабильными: campaign_id, adset_id, creative_id, source_account_id. Иначе дедупликация превращается в археологию.

Сырые данные лучше складывать отдельно от витрины: raw_* для API-хуков и постбеков, stg_* для нормализации, mart_* для BI. В raw не правим ничего, только фиксируем payload, timestamp, source, request_id. В staging приводим валюты, таймзоны, статусы, схему атрибуции. Это снимает спор “почему цифры не сходятся” — проверяем сходимость дельты в трекере и кабинете.

Критично партиционировать факты по дате и, если объем большой, по source_account_id. Индексы — на все поля, по которым фильтрует аналитик: date, campaign_id, team_id, geo, funnel. Для истории изменений держите SCD2 или хотя бы таблицу snapshot_campaign_daily: так видно, когда команда поменяла креатив, бюджет или источник трафика, а не только итоговый PnL.

Дальше строится витрина: расходы, лиды, апрув, выручка, ROI, CAC, hold-rate, фрод-метки. Всё, что не автоматизировано — это потенциальный убыток. Если схема не позволяет ответить, где именно течет профит, значит она не про аналитику, а про склад логов.