Архитектура базы, которая не ломается на истории залива всей команды

Архитектура базы, которая не ломается на истории залива всей команды

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

Базовый слой:
— raw_events: все входящие события как есть, без агрегаций
— campaigns, flows, offers, users: справочники с нормализацией названий и ID
— fact_conversions: факт конверсий с внешними ключами на справочники
— fact_spend: расходы по связке source/campaign/adset/creative
— audit_log: кто и что поменял в маппингах

Ключевые правила:
— партиционирование по дате события, иначе история начинает тормозить
— дедупликация по transaction_id, click_id, postback_id
— отдельный слой для конвертации валют и таймзон, а не вычисления в BI
— никакой записи руками в факт-таблицы, только ETL и API-хуки

Для анализа истории команды нужны не только расходы и доходы, но и контекст: кто запускал связку, какой оффер был на входе, какие правки вносили в крео и куда потом уехал трафик. Без этого вы смотрите на ROI, но не понимаете, где именно течет профит?

Практика простая: сырые логи — в immutable storage, справочники — отдельно, витрины — только для чтения. Данные не врут, в отличие от байеров.