У performance-маркетингу назрівала криза точності: з одного боку, алгоритми Smart Bidding вимагають дедалі більше якісних сигналів для навчання, з іншого — клієнтські скрипти на сайтах (tag-based tracking) втрачають від 10% до 35% реальних дій. Причини знайомі кожному фахівцю: блокувальники реклами, політики Safari ITP / Firefox ETP, збої під час завантаження важких сторінок, відмови від передачі cookie в Consent Mode та переривання сесій на етапі оплати.
Донедавна у рекламодавця існувало два ізольованих світи:
- Вебтеги (Google Tag / GTM), які фіксували дії на сайті «тут і зараз», але страждали від втрати даних на боці браузера.
- Офлайн-імпорт (Offline Conversion Tracking / OCI), який налаштовувався як окрема дія конверсії та часто призводив до дилеми: або задвоєння метрик, якщо враховувати і тег, і CRM, або втрата швидкого зворотного зв'язку для автостратегій, якщо повністю перейти на завантаження постфактум.
Google Ads викотив ключове архітектурне оновлення: Multi-Source Conversions (доповнення тегів зовнішніми джерелами даних). Тепер система дозволяє об'єднати вебтег і серверні/офлайн-дані всередині однієї й тієї самої дії конверсії. Офлайн-завантаження більше не конкурують із пікселем, а закривають його прогалини та коригують цінність замовлень.
Розбираємося, як влаштована механіка, у чому фундаментальна вигода для Smart Bidding і що необхідно налаштувати, аби алгоритми не спотворили статистику.
Як працює гібридна атрибуція Multi-Source
Суть оновлення — злиття двох потоків даних (онлайн та офлайн) в єдину точку з автоматичною дедуплікацією на боці Google.
Механіка дедуплікації: роль Transaction ID
Головною сполучною ланкою стає унікальний ідентифікатор транзакції (transaction_id або order_id).
- Якщо тег спрацював штатно: Google фіксує конверсію в момент оформлення замовлення на сайті, прив'язує її до кліку й передає сигнал у Smart Bidding. Пізніше, коли CRM передає офлайн-файл із тим самим
transaction_id, система розпізнає дубль. Вона не створює другу подію, але оновлює дані (наприклад, якщо в CRM змінилася сума замовлення через знижку або повернення частини позицій). - Якщо тег заблокований або зірвався: Браузер закрили до спрацьовування сторінки Thank You, спрацював AdBlock або стався збій скрипта. У вебаналітиці події немає. Проте у вашій CRM чи базі замовлень транзакція зафіксована. Під час регулярного вивантаження Google Ads знаходить відповідний перехід (за супутніми даними сесії / хешованими контактами /
gclid) і дописує конверсію заднім числом, прив'язуючи її до вихідної кампанії та ключового слова.
Чому це змінює ефективність Smart Bidding
Для контекстної реклами з оплатою за результат (tCPA) або повернення інвестицій (tROAS) це оновлення усуває фундаментальний перекіс:
- Запобігання заниженню ставок (Bid Suppression): Коли кампанія втрачає 15–20% конверсій через приватність браузерів, алгоритм вважає, що аудиторія або ключові фрази не конвертуються. Ставки знижуються, покази падають. Відновлення реального обсягу замовлень повертає кампаніям правильний аукціонний пріоритет.
- Передача реального LTV та чистого чека: В e-commerce поширена проблема — невідповідність кошика на сайті й факту оплати (скасування, апсейли оператором, заміна позицій на складі). Нова модель дозволяє тегом ловити факт наміру, а офлайн-потоком актуалізувати точну суму закритих угод.
- Згладжування довгих циклів угоди: У B2B та сфері послуг (нерухомість, авто, медицина, складний консалтинг) первинний клік фіксується пікселем, а кваліфікація ліда та оплата відбуваються за кілька тижнів. Гібридна атрибуція об'єднує ці фази в безперервну лінію цінності.
Архітектура впровадження: три кроки до запуску
Інтеграція офлайн-джерел до наявної вебдії конверсії вимагає інженерної точності. Помилки тут загрожують подвійним обліком або просіданням ефективності навчання кампаній.
Крок 1. Уніфікація ідентифікаторів (Web + CRM)
Обов'язкова умова: на боці фронтенду тег Google (через GTM або gtag.js) повинен генерувати або захоплювати transaction_id.
У коді події покупки параметр має суворо збігатися з номером замовлення в CRM:
У CRM цей самий ORDER_128945 має бути первинним ключем запису.
Крок 2. Налаштування каналу передачі через Data Manager
Google поступово прибирає потребу писати кастомні парсери під застарілий API. Основний інструмент сьогодні — Google Ads Data Manager:
Підключення конекторів без коду (Google BigQuery, HubSpot, Salesforce, Google Cloud Storage, SFTP, Zapier).
Зіставлення полів:
Transaction ID,Conversion Time,Conversion Value,Currency, а також параметрів Enhanced Conversions (хешовані за стандартом SHA-256emailтаphone number).
Важливо: Не створюйте нову дію конверсії! В інтерфейсі конверсій знайдіть вашу поточну вебдію та скористайтеся опцією підключення додаткового джерела даних («Boost website measurement using additional data sources»).
Крок 3. Врахування 14-денного адаптаційного періоду (Monitoring Period)
Google впровадив захисний механізм: під час підключення офлайн-джерела до активної конверсії система автоматично вмикає 14-денний період моніторингу (Diagnostics Only).
- Протягом цих двох тижнів офлайн-дані відображаються лише у звітах і діагностиці.
- Вони не беруть участі в розрахунку ставок Smart Bidding. Це необхідно, щоб алгоритм оцінив відсоток розбіжностей, відкалібрував дедуплікацію й не спричинив різких стрибків ставок у кампаніях.
- На 15-й день об'єднані дані стають повноправним сигналом для оптимізатора ставок.
Чек-лист: де найчастіше припускаються помилок
Перед активацією перевірте критичні вузли:
Підсумок
Об'єднання тегів та офлайн-джерел ставить крапку в багаторічній суперечці про те, чий облік пріоритетніший — пікселя чи бази даних. Тепер це симбіотична система: тег забезпечує миттєву реакцію для алгоритмів у реальному часі, а офлайн-завантаження слугує гарантом достовірності та фінансової точності.
Для бізнесу це прямий шлях до зростання ROAS: алгоритми навчаються не на гіпотетичних кліках і скриптах, що зірвалися, а на фактично сплачених угодах із вашої CRM.
👉🏻 Усі ключові новини, інсайди та оновлення — в Telegram-каналі «Новини Арбітражу».
Нема коментарів