Заявки йдуть, бюджет витрачається, а менеджер закриває угоду по телефону чи в офісі — і рекламний кабінет про це ніколи не дізнається. У звіті Google Ads красується дешевий лід, але чи справді він перетворився на оплату — загадка. Це класичний розрив між маркетингом і продажами, через який ROAS у кабінеті стає фікцією.
Рішення — відстеження офлайн-конверсій. Розберемо, що це таке, якими способами дані передаються назад у рекламні системи і як налаштувати процес так, щоб алгоритми навчалися на реальних грошах, а не на «сирих» заявках.
Що таке офлайн-конверсії і чим вони відрізняються від онлайн
Онлайн-конверсія фіксується прямо на сайті: заявка, дзвінок з колбеку, оплата в інтернет-магазині. Офлайн-конверсія — це дія, яка відбувається за межами сайту: клієнт залишив заявку, а купив за тиждень у шоурумі або підтвердив угоду по телефону з менеджером.
Проблема в тому, що між заявкою (MQL) і реально закритим продажем (SQL) — прірва. Користувач міг клікнути по оголошенню, залишити контакти, а потім передумати, взяти паузу чи просто не додзвонитися. Без передачі офлайн-даних рекламний кабінет вважає конверсією сам факт заявки, хоча реальних грошей може не бути взагалі. У підсумку звітний ROAS виглядає гарно, а фактична рентабельність реклами — зовсім інша історія.
Навіщо передавати офлайн-дані назад у рекламні системи
Повернення даних про реальні продажі в Google Ads чи Meta Ads вирішує одразу кілька задач: алгоритми отримують точний сигнал, які кліки привели до грошей, бюджет перерозподіляється на користь джерел з якісними лідами, а не просто дешевими заявками. Це також допомагає знайти нові ключові слова і сегменти аудиторії, які частіше доходять до оплати.
Як GCLID, FBCLID та інші ідентифікатори пов’язують клік з офлайн-угодою
Ключову роль у зв’язці кліка й угоди відіграють унікальні ідентифікатори: GCLID та його модифікації GBRAID і WBRAID для Google Ads, FBCLID — для Meta. При переході за рекламою система присвоює користувачу такий код, який зберігається в CRM разом із карткою ліда. Коли угода переходить у статус «оплачено», ідентифікатор разом із Transaction ID або Order ID відправляється назад у рекламний кабінет — так система розуміє, який конкретно клік привів до продажу.
Способи передачі офлайн-конверсій — від ручного завантаження до Server-Side
Є кілька підходів, які відрізняються за трудовитратами і масштабованістю.
Ручне завантаження через файл. Найпростіший спосіб — вивантажити дані про угоди з CRM у CSV або Google Таблиці за шаблоном Google Ads, вказавши GCLID, назву конверсії, час, цінність і валюту. Підходить для невеликого обсягу угод, але вимагає регулярної ручної роботи і не дає миттєвої синхронізації.
Автоматична інтеграція через CRM і конектори. Bitrix24, AmoCRM, HubSpot і Salesforce можна пов’язати з рекламними кабінетами через сервіси на кшталт Albato, Zapier, Make або ROMI Center. Щойно угода змінює статус у CRM, конектор автоматично передає дані в Google Ads чи Meta без участі людини.
Server-Side GTM і Conversions API. Найбільш стійкий до блокувань метод — передача подій через серверний контейнер Google Tag Manager і API конверсій (CAPI). Дані йдуть напряму з сервера в рекламну систему, минаючи браузер і cookies користувача, що критично в умовах обмежень iOS і блокування сторонніх cookies.
Google Ads Data Manager. Google консолідував розрізнені сценарії імпорту конверсій в єдиний інтерфейс всередині рекламного кабінету. Data Manager дозволяє підключити CRM, BigQuery, Google Таблиці та сторонні аналітичні сервіси без написання складного коду — налаштування зводиться до вибору джерела даних і зіставлення полів.
Data Manager API. Це інтерфейс для розробників, що прийшов на зміну застарілому протоколу OCI (Offline Conversion Import) у складі Google Ads API. Він дозволяє передавати події воронки і First-Party Data напряму з бекенда компанії, що зручно при високому обсязі угод і необхідності синхронізації в реальному часі.
Розширені конверсії для лідів — як працюють без GCLID
Якщо ідентифікатор кліка втрачено (наприклад, через закінчення терміну зберігання cookies чи обмеження браузера), на допомогу приходять Enhanced Conversions for Leads. Механізм зіставляє конверсію з кліком за хешованими (SHA-256) даними користувача — email чи телефоном, які він залишив у формі заявки. Це дозволяє відновити зв’язку навіть там, де класичний GCLID недоступний.
Колтрекінг — як фіксувати дзвінки як офлайн-угоди
Якщо основна частина заявок приходить по телефону, без колтрекінгу (Ringostat, Calltouch) дані про дзвінки просто загубляться. Сервіс підміняє номер телефону на сайті для кожного джерела трафіку і фіксує, який дзвінок прийшов з якої кампанії. Далі статус дзвінка (відбулася угода чи ні) можна передати в CRM і далі — в рекламний кабінет як офлайн-конверсію.
Відстеження офлайн-конверсій у Google Ads — налаштування покроково
Процес налаштування загалом зводиться до такого: увімкнути автоматичне маркування тегами в акаунті, забезпечити збереження GCLID разом із карткою ліда в CRM, створити в розділі «Конверсії» нову дію типу «Імпорт» і вказати параметри — категорію, цінність, вікно конверсії. Далі дані завантажуються або вручну файлом, або через налаштовану інтеграцію чи Data Manager.
Важливий нюанс: термін зберігання GCLID у Google Ads обмежений — зазвичай до 90 днів. Якщо цикл угоди у вас довший (наприклад, B2B з довгими переговорами), частина конверсій ризикує не зв’язатися з вихідним кліком, і це варто враховувати при плануванні звітності.
Типові помилки при налаштуванні відстеження офлайн-конверсій
Найчастіше розбіжності в даних виникають через:
- пропущений або неправильно збережений GCLID на етапі передачі форми в CRM;
- невірний формат дати й часу конверсії (Google Ads вимагає суворий формат);
- дублювання однієї й тієї самої транзакції при повторному вивантаженні; а також невідповідність валюти й формату суми конверсії між CRM і рекламним кабінетом.
Як офлайн-конверсії навчають Smart Bidding: статуси Primary і Secondary
Автостратегії Google Ads, орієнтовані на цінність конверсій (Value-Based Bidding), навчаються саме на тих даних, які ви їм передаєте. Впроваджувати офлайн-конверсії в автостратегії потрібно поетапно, інакше алгоритм різко «перенавчиться» на неповних даних.
На етапі тестування угода з CRM додається в кабінет зі статусом Secondary (другорядна) — вона видна у звітах і дозволяє спостерігати за динамікою, але не впливає на автоматичне призначення ставок. Після накопичення статистики — як правило, від 30–50 успішних імпортів офлайн-угод на місяць — закриту продаж переводять у статус Primary (основна), а вихідну заявку з сайту, навпаки, понижують до Secondary. Така послідовність запобігає подвійному обліку однієї й тієї самої угоди (заявка плюс продаж) і дозволяє Smart Bidding коректно оптимізуватися саме на реальну виручку, а не на кількість лідів.
Офлайн-роздріб і POS-системи: як відстежувати продажі у фізичних магазинах
Якщо угода відбувається не через CRM з менеджером, а на касі фізичного магазину, застосовуються інші механіки склейки кліка й покупки.
Програми лояльності. На касі клієнт називає номер телефону чи email, які раніше вказував при реєстрації на сайті чи в онлайн-формі. Ці дані хешуються за алгоритмом SHA-256 і відправляються в рекламний кабінет — система зіставляє їх з вихідним кліком, не розкриваючи реальні контакти покупця.
POS-системи й імпорт чеків. Касове програмне забезпечення можна напряму інтегрувати з Google Ads Data Manager, щоб закриті транзакції — суми чеків і список позицій — автоматично підтягувалися в рекламний кабінет без ручного вивантаження.
Динамічні промокоди і QR-коди. Користувач отримує унікальний код на сайті чи в рекламному оголошенні і пред’являє його продавцю в точці продажу. Такий код працює як офлайн-аналог GCLID: він однозначно пов’язує конкретний візит у магазин з конкретною онлайн-кампанією.
Google Store Visits (візити в магазин). Google автоматично оцінює відвідування фізичних філій на основі анонімізованої геолокації користувачів, які клікнули по локальній чи пошуковій рекламі. Метрика доступна лише за наявності мережі з кількох точок і достатнього обсягу кліків і показів — це радше агрегована оцінка, ніж точна прив’язка конкретної угоди до клієнта.
Офлайн-конверсії в Meta Ads — Facebook Offline Events і Conversions API
В екосистемі Meta аналогічну роль відіграє Offline Events Manager у Meta Ads Manager — туди завантажуються дані про продажі, здійснені після взаємодії з рекламою, але поза сайтом. Надійніший спосіб — Conversions API (CAPI), який передає події напряму з сервера, не залежачи від пікселя в браузері користувача. Це особливо важливо після впровадження App Tracking Transparency на iOS і повсюдного блокування сторонніх cookies: CAPI компенсує частину втрачених даних і дозволяє алгоритмам Meta продовжувати оптимізацію за реальними конверсіями.
Хешування SHA-256 — як захистити персональні дані
Передаючи email, телефон чи інші персональні дані клієнта в Google Ads чи Meta, їх необхідно хешувати алгоритмом SHA-256. Це вимога самих рекламних платформ і одночасно умова відповідності нормам захисту персональних даних (GDPR, 152-ФЗ). Хешоване значення дозволяє системі зіставити користувача, не розкриваючи його реальні контактні дані.
Server-Side GTM для офлайн-конверсій — коли без розробника не обійтися
Ручне завантаження файлів, готові конектори і Data Manager закривають базові сценарії, але за великого обсягу угод і необхідності передавати події в реальному часі знадобиться серверний контейнер GTM. Налаштування sGTM вимагає розміщення серверного середовища, написання тегів і тригерів під конкретну CRM чи POS-систему — тут без участі веброзробника чи технічного аналітика обійтися, як правило, не вийде.
Висновок — офлайн-конверсії як основа чесної аналітики
Без передачі даних про реальні угоди рекламний кабінет бачить лише верхівку воронки — кліки й заявки, але не гроші. Автостратегії в такій ситуації навчаються на «сирому» потоці лідів, включно з тими, хто ніколи не заплатить, а бюджет витікає в сегменти, які виглядають ефективними лише на папері. Налаштування офлайн-конверсій — чи то через CRM, колтрекінг, POS-інтеграцію чи Google Ads Data Manager — закриває цей розрив і перетворює рекламну аналітику з набору здогадок на інструмент, заснований на фактичних продажах.