Сообщить об ошибкеКороткий ответ
Скрипт по расписанию обращается к API каждой платформы, получает данные за нужный период, приводит их к единому формату и записывает в промежуточное хранилище, откуда строится отчёт или дашборд.
Как это работает подробнее
Для каждой платформы используется её API с OAuth-авторизацией; скрипт запрашивает нужные метрики и измерения, обрабатывает ответ (обычно JSON) и записывает строки в унифицированную таблицу с одинаковыми названиями полей. Кроме расписания запуска важно учитывать лимиты API каждой платформы (количество запросов в сутки), чтобы при добавлении новых отчётов скрипт не начал упираться в эти ограничения.
Пример кода
normalize_ads_api_rows.py
source_rows = [
{"date": "2026-10-01", "channel": "google-ads", "cost": 12000, "conversions": 18},
{"date": "2026-10-01", "channel": "meta-ads", "spend": 9000, "conversions": 14},
]
normalized_rows = [
{
"date": row["date"],
"channel": row["channel"],
"spend": row.get("cost", row.get("spend", 0)),
"conversions": row["conversions"],
}
for row in source_rows
]Что использовать на практике
- Практика. На практике важно предусмотреть обработку ошибок и повторные попытки при сбоях
API, логирование и алерт при неудачном запуске, а также отслеживать токены доступа, которые могут истекать. Для надёжности рекомендуется хранить не только агрегированные, но и «сырые» ответыAPIза последние несколько дней, чтобы можно было пересчитать отчёт при обнаружении ошибки в логике обработки. - Пример. Плановый запуск получает строки за последние семь дней, нормализует названия показателей и сохраняет результат в общий слой; проверяйте last_updated_at и поднимайте алерт при задержке.
Подводные камни
- Риск. Частая ошибка — не предусматривать мониторинг самого скрипта, из-за чего при молчаливом сбое (например, истёкшем токене) отчёт продолжает показывать старые данные без явного предупреждения.