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

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

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

Базовый каркас:
— <code>raw_events</code>: сырые постбеки, API-ответы, логи кабинетов без правок
— <code>fact_conversions</code>: конверсии с дедупликацией по external_id и времени события
— <code>dim_team_member</code>, <code>dim_offer</code>, <code>dim_campaign</code>, <code>dim_creative</code>: справочники без бизнес-логики
— <code>history_change_log</code>: кто, что и когда поменял в связке, бюджете, статусе

Историю залива лучше строить как SCD2-подход: не перезаписывать строку, а закрывать старую версию и открывать новую. Тогда можно ответить на вопрос: какой оффер, креатив и источник были активны в момент конверсии, а не «что сейчас лежит в кабинете». Проверяем сходимость дельты в трекере и кабинете уже на уровне схемы, а не ручной сверкой.

Для команды критичны три вещи: единый timezone, неизменяемый surrogate key и партиционирование по дате события. Без этого отчеты начинают «прыгать», а пересчёт бэкфилла превращается в археологию. Всё, что не автоматизировано — это потенциальный убыток.

Правильная БД для команды не хранит хаос, она фиксирует факт, версию и контекст. Посмотрим, что там в сырых логах — и сразу станет видно, где именно течет профит?