Breakdown-отчёты в Facebook Ads с 6 августа 2026: Meta отдаёт пустые данные без ошибки — что делать арбитражнику

Опубликовано

admin

Вкл 14 августа, 2026

Ads Insights API в Facebook Ads с 6 августа 2026 перестал отдавать три разбивки отчётов тем аккаунтам, которые не подключили их отдельно. Разбивки impression_device, почасовая статистика и frequency_value теперь требуют включения на уровне каждого рекламного аккаунта, а запрос без включения возвращает не ошибку, а пустой массив данных с кодом 200. Для арбитражника это означает, что дашборд не сломается визуально — он просто покажет нули там, где раньше были устройства, часы и частота показов.

Три разбивки, которые Ads Insights API закрыл 6 августа 2026

Ads Insights API с 6 августа 2026 требует account-level enablement для трёх разбивок: impression_device (устройство показа), hourly_stats_aggregated_by_audience_time_zone и hourly_stats_aggregated_by_advertiser_time_zone (почасовая статистика по таймзоне аудитории и рекламодателя), frequency_value (распределение по частоте). Ограничение затрагивает не все аккаунты сразу: Meta формулирует его как «account-level enablement requirement for certain Insights API breakdowns on some ad accounts», то есть выкатывает выборочно. Подтверждение изменения независимо опубликовали Qlik (бюллетень по коннектору Facebook Ads в Qlik Stitch с датой 6 августа 2026) и Dataslayer, чьи запросы по этим разбивкам начали отдавать пустые значения. Практический вывод для арбитражника: проверить именно те три параметра в своих отчётах, а не искать общую поломку интеграции.

Почему поломка отчётов молчаливая: HTTP 200 и пустой массив

Ads Insights API на запрос с отключённой разбивкой возвращает статус 200 и пустой массив data — без кода ошибки, без предупреждения в ответе и без письма на почту владельца аккаунта. Такое поведение опаснее явной ошибки: скрипт-обёртка не падает, ретрай не срабатывает, алерт не приходит, а BI-дашборд отрисовывается штатно и показывает нули. Обзор изменения у Elevarus описывает эффект дословно как «no error, no warning, no email»: строки просто становятся пустыми. Действие: добавить в свои репортинговые скрипты проверку «200 + пустой data при непустом периоде» и трактовать её как сбой доступа, а не как нулевой открут.

Где включить разбивки в Ads Manager вручную

Ads Manager позволяет вернуть отключённые разбивки через переключатель «Additional Breakdowns» в интерфейсе отчётов: раздел «Отчёты» → «Разбивка» → «Дополнительные разбивки». Доступ запрашивает администратор рекламного аккаунта, после чего запросы к Ads Insights API по этим параметрам снова отдают данные. Dataslayer прямо указывает: после получения доступа нужно обновить запросы в коннекторе, иначе кэшированный пустой ответ останется в отчёте. Действие: пройти по каждому активному аккаунту в Ads Manager и включить дополнительные разбивки до того, как понадобится сравнение периодов.

Как включить разбивки программно через Marketing API

Marketing API поддерживает включение разбивок запросом POST /act_<ad-account-id>/insights/feature-settings — это тот же opt-in, что и тумблер в Ads Manager, но пригодный для массового прогона по списку аккаунтов. Для медиабайера с десятками аккаунтов ручной обход интерфейса занимает часы, а скрипт по списку act_-идентификаторов отрабатывает за минуты. Действие: собрать список всех рекламных аккаунтов через GET /me/adaccounts, прогнать по ним enablement-запрос и залогировать ответ по каждому — так остаётся аудит того, какие аккаунты уже открыты.

Почему включение не наследуется от Business Manager

Business Manager не передаёт включённые разбивки дочерним рекламным аккаунтам: opt-in делается отдельно для каждого act_. Это ключевая деталь для арбитражной связки, где под один оффер заводится десяток аккаунтов, а часть из них добавляется в БМ уже после старта кампаний. Elevarus фиксирует ограничение прямо: включить один раз на уровне Business Manager и унаследовать вниз невозможно. Действие: встроить enablement-запрос в собственный чек-лист заведения нового аккаунта — рядом с проставлением пикселя, доменной верификацией и настройкой платёжки.

Стоимость промедления: данные до момента opt-in могут не вернуться

Разбивки, включённые позже 6 августа 2026, по оценке Elevarus не восстанавливают исторические данные: диапазон до opt-in остаётся пустым. Часть отраслевых обзоров (в частности, августовский чейнджлог AdMake) утверждает обратное — что после включения данные подтягиваются примерно за сутки. Источники расходятся, и проверить это можно только на собственном аккаунте, поэтому осторожная стратегия одна: включать немедленно и параллельно выгружать в свой storage срезы по устройствам и часам за август. Действие: до конца текущей недели выгрузить device- и hourly-отчёты за 1–14 августа 2026 в CSV, чтобы иметь эталон для сверки после включения.

Что ломается в дейпартинге и автоправилах

Почасовая разбивка Ads Insights API питает дейпартинг и автоматические правила, поэтому её отключение превращает автоматизацию в стрельбу по пустому массиву. Правило вида «поднять бюджет, если CPA за последние 3 часа ниже целевого» на пустом ответе не находит строк и либо не срабатывает вообще, либо срабатывает по дефолтной ветке — в зависимости от того, как написан обработчик. Аналогично слепнет креативная диагностика по устройствам: разделение мобильного и десктопного трафика — базовый инструмент при разборе связок с лендингом. Действие: прогнать все свои правила и трекерные джобы на кейс «пустой ответ» и убедиться, что они останавливаются с алертом, а не молча меняют ставки.

Как ретеншн-лимиты Meta с 12 января 2026 усиливают проблему

Ads Insights API с 12 января 2026 хранит почасовые разбивки 13 месяцев, разбивку frequency_value — 6 месяцев, уникальные метрики (unique_actions, cost_per_unique_action_type) — 13 месяцев, а агрегированные значения — до 37 месяцев. Тогда же Meta убрала окна атрибуции 7d_view и 28d_view, оставив 1d/7d/28d click, 1d view и 1d engaged view; анонс вышел 13 октября 2025 с 90-дневным окном на подготовку. Наложение двух изменений даёт эффект: разбивка по частоте живёт всего полгода, и если аккаунт не включил её вовремя, часть окна уже безвозвратно ушла за горизонт хранения. Действие: настроить регулярную выгрузку frequency- и hourly-срезов в собственную базу, не полагаясь на API как на архив.

Что ещё сломал Marketing API v26.0 от 29 июля 2026

Marketing API v26.0 вышел 29 июля 2026 и удалил поля оценки открута daily_outcomes_curve, budget_guardrule и estimate_dau без замены, заблокировал 47 эндпоинтов Commerce Order Management, начал отдавать ошибку при указании плейсмента Instagram Explore Feed и молча выбрасывать Messenger Stories из messenger_positions. Отдельно ужесточены спецкатегории: кампании по жилью, найму и финансовым продуктам требуют явного значения advantage_audience (1 или 0) — молчаливый дефолт больше не принимается, вызов падает. Календарь дедлайнов: 6 октября 2026 начинается отключение Marketing API v24.0, 27 октября 2026 ограничения v26.0 распространяются на все поддерживаемые версии, включая безверсионные вызовы. Действие: сделать grep по своим интеграциям на строку v24.0 и на удалённые поля прямо сейчас, а не в октябре.

Messenger Stories: плейсмент выключается 27 августа 2026

Плейсмент Messenger Stories прекращает работу 27 августа 2026, и кампании с ручным выбором плейсментов, где он указан явно, придётся пересобирать. Совмещение с поведением v26.0 создаёт неприятную ловушку: API не отдаёт ошибку, а просто убирает Messenger Stories из ответа, поэтому автоматический сетап может «успешно» создать адсет без части заявленных плейсментов. Действие: до 27 августа 2026 выгрузить список адсетов с ручными плейсментами, убрать Messenger Stories и перепроверить фактический состав плейсментов через GET сразу после создания адсета.

Почему проблема острее всего бьёт по мультиаккаунтным связкам

Арбитражник в Facebook Ads работает не с одним аккаунтом, а с пулом, и требование включать разбивки поштучно масштабирует рутину линейно: 30 аккаунтов — 30 отдельных opt-in. Ситуация усложняется тем, что аккаунты в пуле постоянно ротируются, и каждый новый вводится в бой без истории настроек. При работе с арендованными и агентскими аккаунтами — например, из пула adaccounts.shop — имеет смысл сразу фиксировать в своём регламенте, что enablement разбивок делается в первый же день, до первого залива, наравне с проверкой лимитов и биллинга. Действие: добавить строку «включить Additional Breakdowns» в шаблон приёмки нового рекламного аккаунта.

Чек-лист арбитражника на ближайшую неделю

Прогнать тестовый запрос Ads Insights API с breakdowns=impression_device по каждому аккаунту и отметить те, что вернули 200 с пустым data.
Включить дополнительные разбивки: вручную в Ads Manager либо скриптом через POST /act_<id>/insights/feature-settings.
Выгрузить device-, hourly- и frequency-срезы за 1–14 августа 2026 в собственное хранилище до того, как истекут окна хранения.
Добавить в репортинговые скрипты и автоправила защиту: пустой data при коде 200 = алерт, а не нулевой результат.
Проверить автоправила дейпартинга — убедиться, что на пустом ответе они не меняют ставки и бюджеты.
Сделать grep интеграций на v24.0, daily_outcomes_curve, budget_guardrule, estimate_dau — до 6 октября 2026.
Проставить явный advantage_audience в кампаниях спецкатегорий.
Убрать Messenger Stories из ручных плейсментов до 27 августа 2026 и перепроверять состав плейсментов после создания адсета.
Внести enablement разбивок в чек-лист приёмки каждого нового рекламного аккаунта.

Вывод: тихие поломки отчётности стали нормой Meta

Facebook Ads в 2026 году всё чаще меняет поведение API без явных ошибок: пустой массив вместо разбивки, исчезнувший плейсмент вместо отказа, урезанное окно хранения вместо предупреждения. Арбитражник, который читает только цифры в дашборде, рискует принять техническое ограничение за падение эффективности и начать резать нормальные связки. Единственная рабочая защита — считать API ненадёжным архивом: выгружать сырые срезы к себе, проверять ответы на пустоту и держать enablement разбивок частью регламента запуска аккаунта, а не разовой реакцией на сломанный отчёт.

Блог