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

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

Если история залива живёт в одном Excel — у вас не аналитика, а склад случайных правок. Нормальная схема начинается с сырого слоя: туда падают postback, конверсии, клики, расходы, статусы из кабинетов и логов. Ничего не затираем, только партиционируем по дате и источнику. Это база для аудита: <code>raw_events</code> должен хранить исходный payload, <code>received_at</code>, <code>source</code>, <code>campaign_id</code>, <code>click_id</code>.

Дальше нужен слой нормализации. Там выравниваются названия кампаний, офферов, потоков, валют, таймзон и статусов. Главная задача — одна сущность на одну бизнес-событие. Для этого вводите суррогатный ключ и дедупликацию по комбинации <code>click_id + event_type + event_time + source</code>. Иначе один и тот же лид размножится между трекером, кабинетом и BI. Проверяем сходимость дельты в трекере и кабинете, а не верим красивым таблицам.

Для анализа истории залива нужны отдельные факты и справочники: <code>fact_spend</code>, <code>fact_leads</code>, <code>fact_approvals</code>, <code>dim_team</code>, <code>dim_offer</code>, <code>dim_traffic_source</code>. Так вы строите срезы по байеру, связке, вертикали и источнику без JOIN-ада. Индексы — по датам, <code>campaign_id</code>, <code>team_id</code>, <code>offer_id</code>. Всё, что не автоматизировано — это потенциальный убыток.

Финал простой: сначала проектируете схему под вопросы бизнеса, потом подключаете ETL, и только потом рисуете дашборды. Иначе отчёт будет красивым, но бесполезным. Где именно течет профит? Ответ всегда лежит в сырой истории, если она хранится без ручного вмешательства.

—
Если понравилось — посмотри @arb_burnout_prevent_arb