<b>Как хранить историю залива команды так, чтобы SQL не превращался в археологию</b>

<b>Как хранить историю залива команды так, чтобы SQL не превращался в археологию</b>

Одна таблица на всё — быстрый путь к мусору. Нужны минимум 3 слоя: raw для сырых постбеков и API-ответов, staging для нормализации, mart для витрин под BI. В raw не правим поля, не дедуплицируем и не склеиваем источники. Там лежит первичный след: campaign_id, adset_id, creative_id, click_id, payout, status, event_time.

В staging уже решаем грязь: приводим timezone, чистим дубликаты по ключу click_id+event_time, маппим статусы к единому справочнику, считаем валидные связки click→lead→sale. Если этого слоя нет, потом невозможно понять, где именно течет профит? Данные не врут, врут ручные выгрузки и хаотичные правки в Excel.

В mart строим факты и измерения: fact_spend, fact_conversions, dim_campaign, dim_team, dim_source. Факты партиционируем по дате события, а не по дате загрузки. Для истории залива это критично: отчеты по retention, hold, approval и ROI должны собираться из одних и тех же зерен, иначе проверяем сходимость дельты в трекере и кабинете на глаз.

Отдельно храните audit_log: кто, когда и чем перезаливал данные, какой job упал, какой диапазон дат пересчитан. Всё, что не автоматизировано — это потенциальный убыток. Если команда растет, без этой схемы вы не строите аналитику, а вручную обслуживаете ошибки ETL-процессов.