✓ Google Ads API v26.1 расширил отчётность по частоте видеорекламы: к уже доступным корзинам добавлены unique_users_six_plus, unique_users_seven_plus, unique_users_eight_plus и unique_users_nine_plus. Теперь через API можно получить непрерывный ряд от 1+ до 10+ показов и точнее увидеть, какая доля охвата перешла в высокую частоту.
Второе изменение не менее важно: у каждой reach-метрики появились поля *_info с состоянием данных. Они помогают отличать настоящий ноль от значения, скрытого из-за приватности, качества или срока хранения. Без этой проверки автоматический отчёт может назвать подавленные данные нулевым охватом и привести к неверному решению о кампании.
Обновление относится к международному Google Ads API и не объявлено как отдельный локальный запуск для конкретной страны. Практическая доступность reach-данных зависит от типа кампании, выбранного периода, объёма данных и поддержки модели уникального охвата.
Что добавил Google Ads API v26.1
В release notes от 28 октября Google сообщил о завершении набора накопительных частотных корзин. Новые поля metrics.unique_users_six_plus — metrics.unique_users_nine_plus дополнили уже существующие значения 1+, 2+, 3+, 4+, 5+ и 10+.
Каждая метрика показывает число уникальных людей, которым видеореклама была показана не меньше указанного количества раз за выбранный период. Например, unique_users_six_plus означает аудиторию с шестью и более показами, а unique_users_nine_plus — с девятью и более. Это не отдельные взаимоисключающие группы.
Google также добавил объекты ReachMetricInfo для unique_users и всех корзин 2+–10+. Поле reach_metric_states внутри такого объекта объясняет состояние соответствующей метрики. Для production-отчётности это принципиальная разница: число и качество этого числа теперь можно получать в одном запросе.
Новые поля не меняют настройки показа и не устанавливают frequency cap. Это отчётные данные. Решение ограничить частоту, изменить охват или обновить креатив принимает рекламодатель после анализа результата.
Почему корзины 1+–10+ нельзя складывать
Частотное распределение Google построено как накопительный ряд. Пользователь, который увидел рекламу десять раз, входит одновременно в 1+, 2+, 3+ и все последующие корзины до 10+. Поэтому сумма значений 1+–10+ не является общим охватом и не должна использоваться как знаменатель.
Чтобы получить приблизительный размер отдельного интервала, нужно вычитать соседние накопительные значения. Аудитория ровно с шестью показами рассчитывается как 6+ − 7+, ровно с девятью — как 9+ − 10+. Значение 10+ остаётся открытым верхним интервалом: оно объединяет людей с десятью, одиннадцатью и большим числом показов.
Пример с условными данными:
- 1+ — 100 000 уникальных пользователей;
- 5+ — 24 000;
- 6+ — 18 000;
- 7+ — 13 500;
- 8+ — 9 800;
- 9+ — 6 900;
- 10+ — 4 500.
В этом примере ровно шесть показов получили около 4 500 человек, а десять и более — 4 500. Доля аудитории 6+ от общего охвата составляет 18%, но интерпретировать её как «перегретую» можно только в контексте цели, периода и креатива.
Непрерывный ряд полезнее прежнего скачка от 5+ к 10+. Он показывает, где именно растёт высокочастотный хвост: пользователи концентрируются на шести-семи контактах или быстро переходят к девяти-десяти и более.
Ноль, подавление и низкое качество — разные состояния
Reach-метрики моделируются и защищаются порогами приватности. Значение может отсутствовать или выглядеть как ноль не только потому, что никто не увидел объявление. Google перечисляет несколько состояний в ReachMetricState:
- COMPLETE — метрика полная, подавления по приватности или качеству нет;
- PRIVACY_SUPPRESSION — данные скрыты из-за требований приватности;
- QUALITY_SUPPRESSION — данные не показаны из-за качества;
- LOW_QUALITY — значение помечено как низкокачественное;
- DATE_RANGE_BEYOND_RETENTION — период выходит за срок хранения reach-данных;
- UNKNOWN или UNSPECIFIED — состояние нельзя уверенно классифицировать.
Если отчёт хранит только числовое поле, он смешивает три разных ситуации: реальный нулевой охват, подавленную метрику и технически недоступное историческое значение. Поэтому в витрине данных нужно сохранять и число, и список состояний.
Практическое правило простое: ноль считается нулём только при согласованном состоянии, например COMPLETE. При подавлении значение маркируют как недоступное и не используют для вычисления долей. При LOW_QUALITY его можно показать с предупреждением, но автоматическое решение о бюджете лучше остановить.
Как построить GAQL-отчёт без ложных выводов
Минимальный безопасный запрос должен выбирать метрику вместе с её companion-полем. Для видеокампаний можно запросить полный ряд и состояние каждой корзины:
SELECT
campaign.id,
campaign.name,
metrics.unique_users,
metrics.unique_users_info,
metrics.unique_users_two_plus,
metrics.unique_users_two_plus_info,
metrics.unique_users_six_plus,
metrics.unique_users_six_plus_info,
metrics.unique_users_seven_plus,
metrics.unique_users_seven_plus_info,
metrics.unique_users_eight_plus,
metrics.unique_users_eight_plus_info,
metrics.unique_users_nine_plus,
metrics.unique_users_nine_plus_info,
metrics.unique_users_ten_plus,
metrics.unique_users_ten_plus_info
FROM campaign
WHERE campaign.advertising_channel_type = 'VIDEO'
AND segments.date DURING LAST_30_DAYSЭто шаблон, а не универсальный запрос для любого ресурса. Перед внедрением нужно проверить совместимость выбранных полей в Google Ads Query Builder и сохранить версию API рядом с выгрузкой.
Поля *_info имеют тип MESSAGE: их можно выбирать в SELECT, но нельзя использовать в WHERE или ORDER BY. Фильтрацию по состоянию выполняют уже после получения ответа. Числовые reach-метрики тоже нельзя суммировать между строками, поэтому при сегментации нельзя механически складывать уникальных пользователей по дням, устройствам или кампаниям.
В хранилище полезно сохранять четыре уровня: идентификатор кампании, границы периода, значение каждой корзины и её состояние. Отдельное поле api_version защищает от незаметного смешивания схем до и после v26.1.
Ограничения периода, типов кампаний и задержки
Google устанавливает разные пределы для общего уникального охвата и частотных корзин. metrics.unique_users можно запрашивать за период до 92 дней. Корзины unique_users_*_plus доступны только для периода не длиннее 31 дня и не агрегируются между строками.
Общая reach-метрика поддерживается для Display, Video, Demand Gen и App, а частотные корзины в API относятся к Video. Это нельзя переносить на Search, Shopping или Performance Max только потому, что поле существует в общей структуре Metrics.
В интерфейсе Google Ads reach-данные также зависят от доступности модели по стране и минимальных порогов показов и уникальных пользователей. Из-за моделирования показатели могут появляться с задержкой до трёх дней. Сравнение «сегодня против вчера» без учёта этой задержки создаёт ложные провалы в конце периода.
Исторические reach-данные хранятся три года. Если запрос выходит за этот срок, companion-поле может вернуть DATE_RANGE_BEYOND_RETENTION. Это не сигнал падения кампании и не основание заменять значение нулём.
Сегментацию тоже стоит ограничивать. Чем мельче разрез, тем выше вероятность подавления и тем труднее получить стабильную картину. Для первого отчёта лучше начать с кампании и 30-дневного периода, а затем добавлять устройство или дату только при достаточном объёме.
Что частота говорит — и чего не говорит
Большая доля 6+ или 10+ сама по себе не доказывает рекламную усталость. Для короткой акционной кампании несколько контактов могут быть запланированы, а для узкой аудитории высокий хвост может возникнуть быстрее. Частота показывает распределение контактов, но не объясняет реакцию аудитории.
Поэтому её нужно сопоставлять с результатом: view rate, стоимостью просмотра, конверсиями, инкрементальным охватом, изменением CTR и качеством лидов. Особенно полезно смотреть динамику по одинаковым 7- или 30-дневным окнам, не меняя сегментацию между периодами.
Нельзя сравнивать накопительные значения разных длительностей как равные. 10+ за 30 дней и 10+ за семь дней описывают разную интенсивность. Нельзя также считать среднюю частоту достаточной: одинаковое среднее может скрывать как равномерное распределение, так и небольшой перегретый хвост.
Отдельно проверяют связь с frequency cap. В интерфейсе распределение может превышать установленный cap из-за разницы между уникальными пользователями и cookie, границами периода или правилами учёта показов. Reach-отчёт и механизм ограничения частоты измеряют не полностью идентичные сущности.
Как превратить новые поля в управленческий контроль
Вместо одного универсального порога полезнее настроить проверяемый процесс:
- Зафиксировать цель. Разделить кампании на охват, частоту, просмотры и performance-задачи.
- Выбрать стабильное окно. Для корзин использовать не больше 31 дня и учитывать трёхдневную задержку.
- Получить полный ряд. Запрашивать 1+–10+ вместе с каждым `*_info`.
- Проверить состояния. Не рассчитывать доли для подавленных или недоступных значений.
- Рассчитать интервалы. Получить ровно 6, 7, 8 и 9 показов вычитанием соседних корзин.
- Сопоставить с качеством. Проверить конверсии, стоимость, view rate и обратную связь по креативу.
- Выбрать действие. Расширить аудиторию, обновить креатив, скорректировать cap или оставить настройку без изменений.
- Сохранить аудит. Записать период, API-версию, состояния полей и причину решения.
Автоматический алерт можно строить не по самому значению 10+, а по сочетанию условий: доля высокочастотного хвоста растёт в сопоставимых окнах, показатели отклика ухудшаются, а reach-поля имеют состояние COMPLETE. Так команда реагирует на проверенный сигнал, а не на подавленный ноль или неполные последние дни.
Если отчёты по охвату, частоте и бизнес-результату расходятся, PIUN Marketing помогает связать API-аналитику, управление видеокампаниями и ведение Google Рекламы в единую систему контроля.
Оставьте отзыв