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

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

Минимальный каркас:
— raw_clicks, raw_conversions, raw_spend — только append-only, без UPDATE.
— dim_campaign, dim_offer, dim_traffic_source — справочники с версионированием.
— fact_funnel — связка клика, лида, апрува, выплаты, расхода по общему ключу атрибуции.
— Партиционирование по дате события и индексы по campaign_id, sub_id, click_id.

Критичный момент — дедупликация. Один и тот же конверт может прилететь из трекера, кабинета и postback API. Храним event_id, source_priority, ingested_at и правила выбора главной записи. Тогда проверяем сходимость дельты в трекере и кабинете не глазами, а SQL-джойном.

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

Сначала проектируйте не отчёт, а путь данных: от API-хука до витрины. Данные не врут, в отличие от байеров.