Google Виводить Офлайн-Конверсії з Ads API: Що Робити Командам

Питання, яке кожен лід performance-маркетингової платформи має поставити своєму VP Eng цього тижня, — це не те, чи треба перебудовувати пайплайн офлайн-конверсій, а хто контролює бюджет на міграцію і який пункт 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-вендори. Один набір облікових даних, одна модель обмежень, один потік автентифікації. Розподіл процесів між різними поверхнями означає, що кожен партнер з інтеграції тепер підтримує щонайменше два клієнти, два шляхи обробки помилок і два набори квотної економіки. Це не дрібниця для вендорів, які формували ціну на свої місця, виходячи з припущення про єдину поверхню інтеграції.

Чому це важливо для performance-маркетингу

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

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

Є також регуляторний аспект, який платформним лідам не варто ігнорувати. Імпорт офлайн-конверсій містить хешовані персональні дані, GCLID-и, прив'язані до сесій користувачів, та дані про виручку. Будь-яка зміна у способі прийому цих даних Google супроводжуватиметься оновленими вимогами до згоди, імовірно, щільнішим узгодженням із примітивами Privacy Sandbox, і майже напевно — оновленим додатком до угоди про обробку даних. Юридичний відділ захоче ознайомитися з новими умовами до відвантаження інтеграції, а це додає тижні до календарного плану, а не дні.

Вплив на галузь

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

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

Розрахунок «будувати чи купити» також змінюється. Вендори на кшталт провідних CDP та постачальників серверного тегування позиціонували себе як рівень абстракції, що захищає клієнтів від саме такого платформного хаосу. Цей крок — найкращий продажний аргумент для них за рік. Чи справді вони забезпечать захист, чи просто передадуть витрати на міграцію з націнкою — ось питання, яке відділ закупівель має ставити перед підписанням будь-чого нового.

На що звертати увагу

Три сигнали покажуть, наскільки руйнівним це реально стане. По-перше, стежте за графіком відключення, який опублікує Google. Дванадцятимісячне завершення підтримки — керовано, шестимісячне — це пожежна тривога, а будь-що коротше змушує укладати аварійні контракти. По-друге, стежте за тим, чи вимагатиме нова поверхня наявності проекту Google Cloud або білінгових відносин, яких не вимагав Ads API. Це ознака того, чи є цей крок також неявним монетизаційним ходом — переведенням прийому конверсій до продукту з тарифікацією за використання. По-третє, стежте за тим, що зробить Meta. Marketing API Meta та Conversions API мають власний архітектурний поділ між управлінням рекламою та прийомом конверсій, і платформні зміни на цьому рівні, як правило, синхронізуються між дуополією протягом 12–18 місяців.

Моя думка: це початок того, як Google формально розділяє «рекламні операції» та «інфраструктуру вимірювання» на рівні API, а наступним кроком стане посилення примусового виконання режиму згоди на стороні прийому даних. Команди, які перебудуються зараз із цим припущенням в основі, не матимуть потреби перебудовуватись знову у 2027 році.

Ось ключовий абзац для стейкхолдерів. CFO будь-якої компанії, яка витрачає понад $5M на рік на Google Ads, має поставити Head of Platform конкретне питання цього тижня: яка загальна вартість — інженерна, вендорна та альтернативна — підтримки нашого поточного пайплайну офлайн-конверсій через міграцію, і при якому рівні витрат стає дешевше передати весь шар вимірювання на аутсорс керованому вендору, ніж тримати його всередині? Ця цифра може бути розрахована, і якщо ніхто в команді не здатен надати її протягом десяти робочих днів, в організації є прогалина у платформній відповідальності, яку ця міграція ось-ось оголить.

Ключові висновки

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