<b>Архитектура БД для истории залива команды: без дублей, ручного хаоса и потерь</b>

<b>Архитектура БД для истории залива команды: без дублей, ручного хаоса и потерь</b>

Если вся команда пишет расходы, лиды и постбеки в разные таблицы, аналитика быстро превращается в свалку. Нужна схема, где каждый факт залива живёт в одной сущности, а остальное — это производные витрины.

База строится в 3 слоя:
• <code>raw</code> — сырые ответы API, логи трекера, постбеки без правок
• <code>staging</code> — нормализация полей, приведение валют, дедупликация по external_id
• <code>mart</code> — агрегаты по связкам campaign/adset/creative/buyer/team

Ключевая таблица — факт-залив. В ней должны быть: source_id, team_id, buyer_id, campaign_id, spend, clicks, leads, approvals, timestamp, load_batch. Без batch_id потом невозможно отловить повторную загрузку и объяснить расхождение с кабинетом.

Связи делайте справочниками: team, buyer, offer, traffic_source, geo, creative. Историю изменений храните через surrogate key и valid_from/valid_to. Иначе при переименовании кампании сломается весь ретроанализ. Партиционирование по дате залива и индексы по source_id + campaign_id ускоряют сверки и поиск аномалий ⚙️

Проверяем сходимость дельты в трекере и кабинете, считаем повторные загрузки и не даём людям править цифры руками. Всё, что не автоматизировано — это потенциальный убыток.