Skip to content
RiverCore
Google убирает офлайн-конверсии из Ads API: что делать командам
offline conversions migrationGoogle Ads APIattribution pipelineGoogle Ads API offline conversion import changesoffline conversion pipeline rebuild strategy

Google убирает офлайн-конверсии из Ads API: что делать командам

6 июн 20266 мин. чтенияMarina Koval

Вопрос, который каждый лид перформанс-маркетинговой платформы должен задать своему VP по инженерии на этой неделе, — не нужно ли пересобирать пайплайн офлайн-конверсий, а кто владеет бюджетом на миграцию и какой пункт Q3-роадмапа придётся срезать ради её финансирования. Google переносит импорт офлайн-конверсий из Google Ads API, и эта одна фраза меняет стек, который тысячи рекламодателей, агентств и martech-вендоров тихо строили последнее десятилетие. Команды, воспринимавшие импорт офлайн-конверсий как стабильный примитив, скоро узнают, насколько дорогой в действительности была эта «стабильность».

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

Как сообщил MSN, Google переносит импорт офлайн-конверсий за пределы поверхности Google Ads API. Импорт офлайн-конверсий — это механизм, с помощью которого рекламодатели передают обратно сигналы о событиях, происходящих за пределами рекламного клика: закрытая сделка, конвертированный телефонный звонок, изменение стадии в CRM, розничная покупка, привязанная к Google Click ID (GCLID). Для лидогенерационных вертикалей, B2B SaaS, авторегиона, финансовых услуг и любого бизнеса с циклом продаж длиннее, чем оформление заказа, этот пайплайн является сигналом для оптимизации ставок. Без него Smart Bidding оптимизируется по заполненным формам, а не по выручке.

Конкретные детали нового эндпоинта, временны́е рамки и расписание депрекации выходят за рамки этого материала, и я не стану их домысливать. Конкретно одно: архитектурное направление — возможность, которая находилась внутри Ads API, выносится наружу. Это само по себе говорит о том, что Google хочет управлять данным процессом в более контролируемой среде: будь то выделенная поверхность для приёма данных, продукт Google Cloud или более тесная интеграция со слоями согласия и идентификации.

Для контекста: Ads API исторически был единственной точкой интеграции, на которую ориентировались martech-вендоры. Один набор учётных данных, одна модель лимитов, один auth-флоу. Разделение рабочих процессов между поверхностями означает, что каждый партнёр по интеграции теперь поддерживает как минимум двух клиентов, два пути обработки ошибок и два набора квотной экономики. Это немалая нагрузка для вендоров, которые рассчитывали цену лицензий исходя из единой интеграционной поверхности.

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

Импорт офлайн-конверсий — это неприглядная «сантехника», благодаря которой машинное обучение в ставках реально коррелирует с выручкой. Уберите эту «сантехнику» из API-поверхности, которую инженеры уже знают, — и три вещи произойдут последовательно. Первое: каждый martech-вендор с функцией «отправить офлайн-конверсии в Google» получает принудительную миграцию в свой бэклог. Второе: внутренние дата-команды, построившие собственные мосты GCLID-to-CRM (а таких больше, чем вендоры готовы признать), сталкиваются с той же миграцией, не имея вендора, на которого можно переложить ответственность. Третье: команды, которые и без того рассматривали серверный тегинг или подход с медиацией через CDP, получают удобный повод для масштабной пересборки, которую откладывали с 2024 года.

Вопрос юнит-экономики острее, чем кажется на первый взгляд. Среднерыночный рекламодатель с годовыми затратами на платный поиск от $2M до $10M, как правило, имеет одного-двух инженеров, частично занятых на конверсионном пайплайне, плюс контракт с вендором стоимостью от $30K до $200K в зависимости от того, включена ли атрибуция в пакет. Принудительная переинтеграция сжигает от 80 до 300 инженерных часов на стороне клиента, плюс всё, что вендор передаёт как «надбавку за модернизацию платформы» при следующем продлении. Умножьте это на агентскую книгу из 40 клиентов — и получится реальная цифра, которую кому-то придётся поглотить.

Есть и регуляторный аспект, который платформенным лидам не стоит игнорировать. Импорт офлайн-конверсий несёт хешированные персональные данные, GCLID, привязанные к пользовательским сессиям, и данные о выручке. Любое изменение в том, как Google принимает эти данные, повлечёт обновлённые требования к согласию, скорее всего более тесное соответствие примитивам Privacy Sandbox, и почти наверняка обновлённое соглашение об обработке данных. Юридический отдел захочет ознакомиться с новыми условиями до запуска интеграции, что добавляет недели в календарь, а не дни.

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

Для трафиковой и привлекательной стороны воронок в iGaming, финтехе и DeFi-онбординге это важнее, чем для среднестатистического интернет-магазина. Эти вертикали зависят от офлайн-сигналов конверсии, потому что конверсия, которая действительно имеет значение (пополненный счёт, пройденная KYC-верификация, первый депозит выше порога), происходит через дни или недели после клика. Оптимизация ставок без этого сигнала — это оптимизация по регистрациям, а это неверная целевая функция, которая производит именно тот низкоLTV-трафик, на который финансовые команды жалуются каждый квартал.

Последствия для инженерных организаций следуют напрямую. Команды, укомплектовавшие единственного инженера по «интеграциям платных медиа», потому что Ads API был одной поверхностью, теперь нуждаются либо во втором найме, либо в вендоре. Рынок найма для инженеров, реально разбирающихся и в API рекламных платформ, и в моделировании конверсий, узкий; те, кто есть, уже работают внутри Google, Meta или крупных холдинговых агентств. Ожидайте давления на компенсацию в этой роли во второй половине 2026 года.

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

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

Три сигнала покажут, насколько разрушительным это в действительности окажется. Первое: следите за таймлайном депрекации, который опубликует Google. Закат за 12 месяцев — управляемо, за 6 месяцев — пожарная тревога, а что-либо короче вынуждает к экстренным контрактам. Второе: следите, потребует ли новая поверхность наличия проекта Google Cloud или биллинговых отношений, которых Ads API не требовал. Это индикатор того, является ли это также мягким монетизационным ходом — переводом приёма конверсионных данных в тарифицируемый продукт. Третье: следите за Meta. Marketing API и Conversions API Meta имеют собственное архитектурное разделение между управлением рекламой и приёмом конверсий, а платформенные изменения на этом уровне, как правило, сходятся между дуополией в течение 12–18 месяцев.

Моя точка зрения: это начало формального разделения Google «рекламных операций» и «измерительной инфраструктуры» на уровне API, а следующий шаг — ужесточение принудительного исполнения consent-mode на стороне приёма данных. Команды, которые пересоберут всё сейчас с этим допущением в основе, не будут пересобирать снова в 2027 году.

Вот абзац для стейкхолдеров, который имеет значение. CFO любой компании, тратящей более $5M в год на Google Ads, должен задать Руководителю по платформе конкретный вопрос на этой неделе: какова совокупная стоимость — инженерная, вендорная и альтернативная — поддержания текущего пайплайна офлайн-конверсий в ходе миграции, и при каком уровне затрат становится дешевле отдать весь измерительный слой на аутсорс управляемому вендору, а не держать его внутри? Эта цифра поддаётся расчёту, и если никто в команде не может предоставить её в течение десяти рабочих дней, у организации есть разрыв в платформенном владении, который данная миграция вот-вот обнажит.

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

  • Google переносит импорт офлайн-конверсий из Google Ads API, разбивая рабочий процесс, который martech-вендоры и внутренние команды воспринимали как единую интеграционную поверхность.
  • Каждый вендор с функцией офлайн-конверсий теперь имеет принудительную миграцию, и её стоимость проявится в ценах при продлении — вне зависимости от того, будет ли она выделена отдельной строкой.
  • Вертикали с длинными окнами конверсии (депозиты в iGaming, пополненные счета в финтехе, B2B-пайплайн) наиболее уязвимы, поскольку оптимизация их ставок зависит от этого сигнала.
  • Платформенным лидам следует рассматривать это как повод пересмотреть архитектуру серверного тегинга и CDP, а не как разовую замену эндпоинта.
  • Следите за таймлайном депрекации, за тем, потребует ли новая поверхность биллинговых отношений с Google Cloud, и за Meta на предмет параллельного шага в течение 18 месяцев.

Часто задаваемые вопросы

В: Что такое импорт офлайн-конверсий в Google Ads?

Импорт офлайн-конверсий — это механизм, с помощью которого рекламодатели передают в Google данные о конверсиях, происходящих за пределами непосредственного рекламного клика: закрытая сделка, квалифицированный лид или изменение стадии в CRM. Как правило, они привязываются к рекламным кликам с помощью Google Click ID (GCLID) и необходимы для того, чтобы Smart Bidding оптимизировался по выручке, а не по верхнеуровневым действиям воронки.

В: Почему Google переносит эту возможность за пределы Ads API?

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

В: Что инженерным командам следует делать прямо сейчас?

Проинвентаризировать каждую систему, которая в настоящее время записывает офлайн-конверсии в Ads API, включая инструменты вендоров и любые внутренние скрипты. Оценить трудозатраты на миграцию в инженерных часах и представить эту цифру финансовому отделу вместе с календарём продления вендорных контрактов. Затем оценить, является ли этот момент подходящим для консолидации приёма конверсий за уровнем серверного тегинга или CDP, вместо того чтобы пересобирать точечную интеграцию, которую, возможно, придётся снова менять в течение двух лет.

MK
Marina Koval
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// RELATED ARTICLES
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU