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

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

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

Базовый слой: raw_events, clicks, conversions, costs, accounts, users. В raw не трогаем payload, только сохраняем сырьё и технические поля: source_id, campaign_id, ts, request_id. Дедупликация идёт по request_id + event_hash, иначе один и тот же постбек размножит конверсии. Для истории критично партиционирование по дате и индексы по campaign_id, adset_id, user_id.

Следующий слой — mapping. Здесь связываются внешние IDs из кабинетов с внутренними сущностями команды. Без этой таблицы вы не восстановите путь: кто заливал, из какого аккаунта, на какой оффер и в какой период. Обязательно храните историю изменений: кампания переименовалась, аккаунт переехал, связка сменилась — аналитика должна помнить оба состояния.

Финальный слой — витрина team_funnel_daily или team_funnel_hourly. В ней считаются spend, clicks, CTR, CR, approved, rejected, ROI, а также срезы по байеру, источнику, офферу и гео. Отдельно держите audit_log: кто и когда поправил маппинг, загрузил файл, пересобрал партицию. Иначе потом никто не объяснит, откуда взялась дельта.

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