Автосбор из Facebook Ads API и TikTok Business API: где ломается аналитика байера

Если данные из двух кабинетов сходятся руками, у вас не аналитика, а лотерея. Правильный ETL-процесс здесь строится вокруг трех слоев: raw-выгрузка, нормализация, витрина. В raw сохраняем ответ API как есть, без «улучшений». В нормализации приводим кампании, adset, adgroup, валюты, часовые пояса и статусы к одной схеме. В витрине уже считаем spend, clicks, leads, approvals, CR и ROI.

Критичные точки отказа:
— разные уровни агрегации в Facebook и TikTok;
— задержка постбеков и повторные события;
— расхождение по времени: UTC, локальный часовой пояс, сдвиг суток;
— дубликаты из-за повторных API-поллов и ретраев;
— пустые поля, которые ломают JOIN и партиционирование.

Нормальная схема: отдельный job для инкрементальной загрузки, отдельный для дедупликации по event_id и external_id, отдельный для сверки с кабинетом. Сырые таблицы партиционируются по дате события, а не по дате загрузки. Иначе при ретро-апдейтах вы потеряете кусок истории или начнете пересчитывать лишнее.

Для контроля качества ставьте rules-based checks: сумма spend по дням, количество конверсий, доля NULL в ключевых полях, расхождение дельты между API и трекером. Всё, что не автоматизировано — это потенциальный убыток. Проверяем сходимость дельты в трекере и кабинете, а потом уже оптимизируем SQL-запрос на лету.

Итог простой: не тяните аналитику напрямую в дашборд. Сначала стабилизируйте сбор, потом нормализацию, потом контроль качества. Иначе вы будете смотреть не на профит, а на ошибки интеграции.