Offline Conversion Import (OCI) — це механізм, який відправляє постклікові події з вашого CRM — кваліфікований лід, створена можливість, виграна угода (closed-won) — назад у Google Ads, щоб Smart Bidding оптимізувався під дохід, а не під заповнення форм. Для B2B SaaS маркетологів це різниця між призначенням ставок на "будь-кого, хто заповнив демо-форму" і на "людей, які насправді стали клієнтами" (Google Ads Help, 2025-09-18).
Що таке OCI
Offline Conversion Import — це конверсійна дія Google Ads, джерелом якої є "офлайн" — зазвичай CRM, білінгова система або платформа відстеження дзвінків — а не пиксель на сайті. Ви оголошуєте конверсійну дію в Google Ads (Tools → Conversions → New → Import → CRM, files, or other data sources), потім відправляєте події за ключем ідентифікатора кліка, який було прив'язано до початкового кліка по оголошенню (Google Ads Help, 2025-09-18).
Підтримувані ідентифікатори кліка — GCLID (веб), GBRAID (iOS-додаток, ATT-дозволено) і WBRAID (iOS-додаток, ATT-відмовлено). Ідентифікатор додається до URL цільової сторінки автотегуванням (auto-tagging); ваша лід-форма, приховане поле або first-party data layer захоплює його і записує в запис CRM поряд з email, телефоном і станом згоди. Коли угода просувається, ви завантажуєте {click_id, conversion_action_name, conversion_value, currency_code, conversion_time} — Google з'єднує рядок із початковим кліком і атрибутує його до кампанії, групи оголошень, ключового слова й аудиторії.
OCI відрізняється від Enhanced Conversions for Leads (ECL), що використовує хешований email/телефон замість ідентифікатора кліка і є рекомендованим запасним варіантом, коли захоплення GCLID ненадійне. Обидва можуть співіснувати на одній конверсійній дії — Google спочатку дедуплікує за ідентифікатором кліка, з відкатом на збіг user-data (Google Ads Help, 2025-11-04).
Як OCI працює end-to-end
П'ять компонентів мають збігтися. Зламайте будь-який — і висновок аудиту той самий: "Smart Bidding оптимізується під неправильний сигнал":
- Захоплення ідентифікатора кліка. Автотегування ввімкнено на рівні акаунта. Лід-форма містить приховане поле, що читає
gclid/gbraid/wbraidз URL або з first-party cookie. Cookie має пережити навігацію між піддоменами і стани відмови від consent-mode. - Поле CRM + шлях запису. На об'єкті Lead / Contact / Opportunity існує виділене поле
gclid(абоclick_id). Обробник web-to-lead записує його на submit форми; downstream-автоматизація переносить його з Lead у Opportunity під час конверсії. - Маппінг конверсійних дій. Кожна значуща стадія —
MQL,SQL,Opportunity,Closed-Won— має власну офлайн-конверсійну дію в Google Ads з правильно встановленою категорією і коректною моделлю атрибуції цінності. - Шлях завантаження. Або bulk upload через UI Google Ads (ручний CSV), або Google Ads API
ConversionUploadService, або — загальнодоступний з грудня 2025 — Data Manager API, який Google тепер позиціонує як уніфікований шар прийому даних для OCI, Customer Match і сегментів аудиторій (Google Ads Help, 2026). - Вікно свіжості. Конверсії мають бути завантажені в межах 90 днів від оригінального кліка по оголошенню (жорсткий OCI-дедлайн завантаження, незалежний від налаштування click-through window конверсійної дії, яке може бути сконфігуровано до 90 днів для більшості категорій і до 540 днів для деяких). Запізнілі завантаження відхиляються мовчки і ніколи не доходять до Smart Bidding.
Smart Bidding включає завантажені конверсії в наступний цикл оновлення моделі призначення ставок. Затримка від завантаження до впливу на живі ставки зазвичай 1-3 дні; для стратегій tCPA/tROAS на 30-денному lookback перше стабільне зчитування на оновленому OCI-фіді — приблизно через 14 днів.
Що змінилось у 2025-26
Дві зміни домінують у ландшафті OCI 2025-26, і вони не повністю узгоджуються між собою.
Позиція Google — консолідація на Data Manager API. Data Manager API досяг загальної доступності у грудні 2025 як рекомендований шлях прийому для OCI, завантажень Customer Match і керування сегментами аудиторій (Google Ads Developers blog, 2025-12-09). Data Manager уніфікує валідацію полів, хешування, прапорці згоди (Consent Mode v2) і партнерські конектори (Salesforce, HubSpot, Snowflake, BigQuery) в одну схему. Заявлені Google переваги: вищі match-rate, менше помилок "invalid GCLID", швидше налаштування пайплайна для рекламодавців без власних інженерних команд.
Реальність агенцій — спостережено в полі. Сигнал від третіх сторін менш чистий. Search Engine Land відзначив, що міграція впроваджується поетапно, а не одночасно: завантаження Customer Match через Google Ads API почали падати для developer-токенів з basic-доступом з 1 квітня 2026, а офлайн-конверсійний імпорт через UploadClickConversions Google призначив до виведення 15 червня 2026 — отже, рекламодавцям доводиться тримати два різні пайплайни щонайменше до весни 2026 (Search Engine Land, 2026-03-04; Search Engine Land, 2026-05-15). Агенційний коментар із міграційного посібника ALM Corp за травень 2026 повідомляє, що B2B-акаунти лідогенерації, які оптимізуються під офлайнові стадії воронки, — найвищий за пріоритетністю когорт міграції, і що чистіший playbook — спершу класифікувати акаунти за поточною імплементацією (custom API users, Data Manager users, file upload users), а потім мігрувати високобюджетні B2B-пайплайни першими (ALM Corp, 2026-05-17).
Чесний підсумок: Google позиціонував Data Manager як апгрейд "перемкнув — і готово", але графік примусу розбито на хвилі — Customer Match переключили першим, OCI йде слідом у червні 2026. Безпечна тактика до середини 2026 — тримати чинний OCI-пайплайн на ConversionUploadService аж до 15 червня, паралельно розбудовуючи Data Manager під Customer Match і нові конверсійні дії.
Методологічна нотатка. Аудит-движок Whitead позначає пропуски OCI на B2B SaaS акаунтах за чотирма сигналами: (1) хоча б одна Search або PMax кампанія зі Smart Bidding (tCPA, tROAS, Maximize Conversions/Value), але нуль налаштованих офлайн-конверсійних дій; (2) захоплення GCLID відсутнє в основних лід-формах (підтверджено мережевим перехопленням на цільовій сторінці); (3) налаштована офлайн-конверсійна дія без завантажень за останні 30 днів (застарілий пайплайн); (4) Smart Bidding оптимізується під ціль "заповнення форми", цінність якої — або однорідний $0, або однорідно-довільна (наприклад, кожен лід = $100). Коли сигнали (1) + (2) спрацьовують разом, висновок отримує рівень HIGH, тому що призначення ставок доказово сліпе до доходу. Заяв про частоту в популяції аудитів ми не публікуємо до розкриття вибірки в наступній хвилі.
Поширені непорозуміння
Об'єднання слова "офлайн" із "ручним CSV-завантаженням" штовхає багато B2B-команд до того, щоб ставитися до OCI як до квартальної рутини, а не як до щоденного пайплайна. Наступні два питання витягують найдорожчі помилкові прочитання.
Чи Enhanced Conversions for Leads замінює OCI?
Ні — вони вирішують перетинні, але різні задачі. ECL відправляє хешовані email/телефон на submit форми і використовує це, щоб ідентифікувати користувача пізніше, коли ви завантажуєте подію конверсії. Це правильний запасний варіант, коли захоплення GCLID ненадійне (крос-девайс шляхи, сесії з відмовою у згоді, довгі цикли продажу, у яких cookie кліка вже минув). OCI на ідентифікаторі кліка точніший на рівні події, тому що з'єднання детерміноване по унікальному ідентифікатору, а не ймовірнісне по хешованим PII. Рекомендований патерн 2025-26 — запускати обидва на одній конверсійній дії: завантаження за GCLID як основне, ECL із хешованими user-data як fallback для рядків, де ідентифікатор кліка відсутній або прострочений (Google Ads Help, 2025-11-04).
Чи OCI працює на сесіях із відмовою у згоді в EEA?
Частково. Якщо користувач відмовив у маркетинговій згоді і впроваджено Consent Mode v2 Advanced, клік усе ще відбувається, але GCLID не записується в cookie браузера користувача — отже, ваша лід-форма не може його захопити, щоб надіслати в CRM. Змодельовані конверсії статистично закривають частину розриву, але OCI як пряме з'єднання для цього користувача ламається. ECL на хешованому email частково відновлює сигнал там, де користувач дав окрему згоду на email-комунікацію. Аудит-playbook тут — вимірювати рівень захоплення GCLID на трафіку EEA окремо від не-EEA: різке падіння на EEA без паралельного зростання змодельованих конверсій зазвичай вказує на неправильне налаштування Consent Mode v2, а не на проблему з OCI.
Чи треба мігрувати на Data Manager API вже сьогодні?
Так — для нових пайплайнів і з уже визначеним жорстким дедлайном. Завантаження Customer Match через Google Ads API почали падати для developer-токенів з basic-доступом ще з 1 квітня 2026, а OCI через UploadClickConversions призначено до виведення 15 червня 2026 — після цієї дати нових розробників на legacy-шлях не пускатимуть взагалі. Розумна позиція на 2026: негайно підняти Data Manager для нових конверсійних дій і керування списками Customer Match, а міграцію OCI завершити до 15 червня, щоб сигнал Smart Bidding на B2B лідогенерації не "осліп" (Search Engine Land, 2026-05-15; ALM Corp, 2026-05-17).
Пов'язані поняття
OCI залежить від захоплення ідентифікатора кліка, тож аудитуйте його разом із GCLID / GBRAID / WBRAID і парте з Enhanced Conversions for Leads як стійким до згоди запасним каналом. Сигнал, який ви подаєте, прямо тече у Smart Bidding і впливає на призначення кредиту в Data-Driven Attribution. Після того як OCI працює, моніторте розбіжність конверсій GA проти Ads — здоровий пайплайн OCI часто розширює розрив із GA4, тому що Google Ads тепер бачить події доходу, яких GA4 ніколи не отримує.
Джерела
- About offline conversion imports — Google Ads Help, 2025-09
- About enhanced conversions for leads — Google Ads Help, 2025-11
- Using Google Ads Data Manager with enhanced conversions for leads — Google Ads Help, 2026
- The Data Manager API is now generally available — Google Ads Developers blog, 2025-12-09
- Google to disable Customer Match uploads in Ads API — Search Engine Land, 2026-03-04
- Google is moving offline conversion imports out of the Google Ads API — Search Engine Land, 2026-05-15
- Google Ads Offline Conversion Imports in 2026: June 15 API Change, Data Manager Migration — ALM Corp, 2026-05-17