Google Ads API теперь требует ключи доступа для новых токенов обновления

Любой, кто хоть раз автоматизировал онбординг нового рекламодателя в пятницу в четыре часа дня, знает цену единственного OAuth-вызова, который просто работает. Теперь в этот вызов добавляется шаг с ключом доступа. Google обязал использовать аутентификацию по ключу доступа для любого нового токена обновления OAuth 2.0, создаваемого через Google Ads API, и поэтапное внедрение уже началось.

Для инженеров платформ, работающих поверх Google Ads, это из тех тихих изменений API, которые не ломают продакшн в первый день, но незаметно ломают следующую миграцию клиента два месяца спустя. Область применения узкая. Последствия, если проигнорировать это, — совсем нет.

Ключевые детали

Требование, о котором сообщил ALM Corp, стало обязательным 5 августа 2026 года с поэтапным распространением на аккаунты в течение нескольких последующих недель. Любой пользователь, следующий стандартному потоку OAuth 2.0 для создания нового токена обновления через Google Ads API, теперь должен пройти аутентификацию с помощью ключа доступа вместо пароля и кода двухэтапной проверки.

Механика проста. Ключи доступа используют криптографические ключи, при этом закрытый ключ генерируется и хранится на устройстве пользователя. Если у пользователя не настроен ключ доступа, при аутентификации его заставят создать его. Нет ключа доступа — нет токена обновления.

Есть два нюанса, которые важнее самого заголовка изменения.

Первый: существующие токены обновления в безопасности. Токены, созданные до 5 августа, продолжают работать. Это не массовый отзыв. Изменение затрагивает только тех, кто настраивает новую интеграцию, подключает нового рекламодателя или ротирует учётные данные.

Второй: существует семидневная задержка доверия. Свежесозданный ключ доступа функционален, но считается ненадёжным в течение первой недели. Google прямо рекомендует создавать ключи доступа заблаговременно, чтобы этот период истёк до момента, когда аутентификация действительно понадобится. Для агентств, подключающих клиента менее чем за неделю, — это проблема планирования, замаскированная под функцию безопасности.

Область применения шире, чем просто прямые API-вызовы. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service и Looker Studio — все они затронуты. Обычные пользователи Scripts и Looker Studio тоже подпадают под требование, а не только бэкенд-разработчики. Любая интеграция, связывающая аккаунт Google Ads с другим приложением, в итоге потребует ключ доступа.

Единственное чёткое исключение: организации, использующие сервисные аккаунты. Поскольку сервисные аккаунты не используют стандартный поток аутентификации пользователя, они полностью выходят за рамки этого требования. Это единственное предложение является самой важной строкой в объявлении для всех, кто проектирует новые интеграции с нуля.

Почему это важно для performance-маркетинга

Каждое агентство, с которым я работал за последнее десятилетие, имеет один и тот же скелет в шкафу: общий аккаунт Google, токен обновления, созданный много лет назад кем-то, кто давно уволился, и cron-задача, которая тихо выгружает отчёты каждое утро. Этот токен по-прежнему работает. Нормально. Но как только вы подключаете нового клиента, запускаете новую sub-MCC-интеграцию или мигрируете на новый стек отчётности — вы попадаете в новый режим.

Операционное воздействие делится на три части. SaaS-платформы, продающие инструменты управления Google Ads, должны переработать UX онбординга. Старый поток «нажмите здесь, войдите через Google, готово» теперь включает шаг настройки ключа доступа для пользователей, у которых его нет. Это не огромная задача, но это нагрузка на поддержку. Ожидайте волну обращений от клиентов, которые не знают, что такое ключ доступа, и не могут понять, почему их Yubikey не работает так, как раньше работал менеджер паролей.

Агентства, подключающие новых рекламодателей, сталкиваются с семидневным окном доверия как с ограничением по расписанию. Если ваш стандартный SLA гласит «мы перенесём ваши кампании в течение 48 часов», это обещание теперь расходится с позицией Google по умолчанию. Мой совет: агентствам следует добавить пункт о настройке ключа доступа в предстартовый чек-лист, рядом с настройкой биллинга и доступом к пикселю отслеживания.

Производственные инциденты, которые я наблюдал при похожих миграциях аутентификации, следуют предсказуемой схеме. Что-то работает на стейджинге, потому что там используются долгоживущие токены. Затем production-токен истекает или ротируется, поток повторной аутентификации сталкивается с новым требованием, и отчётность тихо останавливается. Никто не замечает, пока клиент не спрашивает, куда делись данные за прошлый вторник. Внедрение ключей доступа особенно подвержено этому, потому что режим отказа часто выглядит как «пользователь получает запрос на настройку ключа доступа в headless-контексте», что просто зависает.

Неудобный вывод: если ваша платформа по-прежнему полагается на пользовательский OAuth для headless-интеграций, Google вежливо говорит вам перейти на сервисные аккаунты.

Влияние на отрасль

Для более широкого стека трафика и performance-маркетинга это скорее толчок, чем пинок, в сторону более защищённой модели аутентификации. Ключи доступа объективно безопаснее, чем пароль плюс TOTP. Закрытый ключ никогда не покидает устройство, защита от фишинга встроена изначально, а поверхность атаки для подбора учётных данных резко сокращается. Никто здравомыслящий не возражает против ключей доступа как такового.

Проблемы — в инфраструктуре. Вендоры ad-tech, менеджеры ставок, инструменты автоматизации фидов, кроссканальные платформы отчётности — все они строили онбординг в предположении, что человек за браузером может завершить OAuth-процесс за один подход. Семидневное окно ненадёжности принуждает к двухфазному онбордингу: сначала настроить учётные данные, потом активировать интеграцию. Команды, которые подойдут к этому как к переработке UX, а не как к простановке галочки, выйдут вперёд.

Есть также вторичный эффект для уровня BI. Если ваш пайплайн маркетинговой аналитики использует BigQuery Data Transfer Service для синхронизации данных Google Ads, и кто-то пересоздаёт этот трансфер под новым аккаунтом — он столкнётся с требованием ключа доступа. Дашборды Looker Studio, принадлежащие физическим лицам, а не сервисным аккаунтам, находятся в той же ситуации. Ожидайте, что в следующем квартале финансовые и аналитические команды будут подавать растерянные обращения в поддержку.

Стратегический сигнал ясен: Google стандартизирует использование ключей доступа по всей своей developer-поверхности, и Ads API — крупный первый доминó. Команды, откладывавшие нормальный аудит управления секретами, миграцию на сервисные аккаунты или консолидацию auth-провайдеров, теперь получили весомый повод действовать. Это полезно. Болезненно, но полезно.

Стоит отметить для тех, кто работает с мультиплатформенными стеками: Marketing API от Meta имеет собственную модель аутентификации с системными пользователями, которая обходит этот класс проблем, и это разумная точка отсчёта для понимания того, насколько хорошо паттерны, аналогичные сервисным аккаунтам, работают на практике.

За чем следить

Три сигнала подскажут, насколько тяжёлым будет следующий квартал.

Следите за тем, как SaaS-вендоры тихо обновляют документацию по онбордингу, добавляя инструкции по ключам доступа. Вендоры, выпустившие чёткие руководства в течение первого месяца поэтапного внедрения, — те, у кого есть инженерная дисциплина. Те, кто в ноябре всё ещё публикует скриншоты с «войдите с паролем Google», — те, кому стоит задавать неудобные вопросы.

Следите за своим календарём ротации токенов. Если у вас есть токены обновления с запланированной ротацией, проверьте, инициирует ли ротация выдачу нового токена или повторно использует существующий. Политики ротации, написанные для мира до 5 августа, могут теперь непреднамеренно втянуть вас в поток ключей доступа в самый неподходящий момент.

Следите за волной миграций на сервисные аккаунты. Google фактически повысил операционную стоимость пользовательского OAuth для headless-нагрузок по сравнению с аутентификацией через сервисный аккаунт. Любая команда, по-прежнему использующая человеческий аккаунт для бэкенд-задач с Google Ads API, должна внести «миграция на сервисный аккаунт» в дорожную карту до конца квартала. Не потому что рушится небо, а потому что альтернатива — объяснять CTO, почему отчётность сломалась из-за окна доверия к ключу доступа во время демо для клиента.

Ключевые выводы

• Только новые токены: существующие токены обновления OAuth, созданные до 5 августа 2026 года, продолжают работать. Паника — не ответ, планирование — ответ.
• Семидневная задержка доверия — это проблема расписания: создавайте ключи доступа как минимум за неделю до того, как вам нужно подключить нового рекламодателя или интеграцию.
• Сервисные аккаунты — запасной выход: headless-нагрузки следует перевести с пользовательского OAuth. Google дал вам повод — воспользуйтесь им.
• UX онбординга требует переработки: SaaS-платформы, управляющие аккаунтами Google Ads от имени клиентов, должны добавить настройку ключа доступа в свой поток и документацию поддержки.
• Охват шире, чем просто API: Google Ads Editor, Scripts, BigQuery Data Transfer и интеграции Looker Studio — все они подпадают под то же требование. Проведите аудит каждой точки, а не только очевидной.