Розширені конверсії Google Ads — це доповнення до звичайного відстеження, яке передає хешовані дані клієнта для точнішого зіставлення рекламної взаємодії з результатом.
Уявімо просту ситуацію. Людина натиснула оголошення, але між кліком і заявкою змінився браузерний контекст. Звичайний ідентифікатор не дійшов до кінця шляху. У формі, однак, залишилася електронна адреса, яку клієнт добровільно передав бізнесу. Саме цей сигнал може доповнити вимірювання — за умови, що його правильно зібрали, нормалізували й передали.
Слово «доповнити» тут важливіше за слово «розширені». Функція не ремонтує неправильну подію, не замінює згоду і не перетворює кожну заявку на гарантовано зіставлену конверсію.
З чого складається розширена конверсія
Розширені конверсії працюють лише як система з кількох частин. Спочатку має існувати справна базова подія, потім до неї додаються дозволені дані першої сторони, а Google використовує їх для зіставлення рекламної взаємодії з результатом.
За довідкою Google Ads, дані першої сторони передаються після одностороннього хешування SHA-256. Хеш — не шифрований лист, який можна відкрити ключем. Це стандартизований відбиток нормалізованого значення, потрібний для зіставлення.
Електронна адреса зазвичай найзручніша: вона достатньо унікальна й рідше змінює формат. Телефон має містити код країни. Для поштової адреси потрібен комплект полів, а не один фрагмент. Хешування не скасовує правил роботи з персональними даними: коли впроваджено Consent Mode, автоматичний збір у Google tag залежить від стану ad_storage.
Два сценарії визначає місце цінного результату
Google описує два робочі сценарії: результат стається на сайті або пізніше повертається з бізнес-системи. У новому інтерфейсі налаштування можуть об’єднуватися, але логіка даних від цього не змінюється.
Результат на сайті
- рахує покупку, реєстрацію або заявку
- передає дані разом із тегом конверсії
- потребує доступного поля в момент події
- завершує вимірювання в онлайн-шляху
Результат після обробки ліда
- рахує кваліфікацію, угоду або оплату
- повертає подію після зміни статусу в CRM
- зіставляє дані з форми та імпорту
- доповнює GCLID, коли він доступний
Якщо оплата завершується на сайті, немає сенсу будувати CRM-імпорт лише заради модної назви. Якщо заявка на сайті ще нічого не означає, оптимізація на сам факт заповнення форми теж не вирішує бізнес-завдання. Потрібно повернути ту подію, після якої лід справді набув цінності.
Це продовжує базову логіку налаштування відстеження конверсій: спочатку визначити подію, а вже потім обирати технічний маршрут.
Спосіб збору визначає рівень контролю
Google може сам знайти значення на сторінці, отримати його з конкретного селектора чи змінної або прийняти через фрагмент коду. Вибір залежить від того, як побудована форма й у який момент у ній з’являються дані.
| Спосіб | Коли доречний | Що контролювати |
|---|---|---|
| Автоматичне визначення | проста стабільна форма | чи знаходить Google потрібне поле після змін сторінки |
| CSS-селектор або змінна | поле має відоме місце або значення | чи доступні дані саме під час спрацювання тега |
| Фрагмент коду | складна форма, віджет або асинхронна дія | нормалізацію, хешування й відсутність повторного передавання |
Явно передані дані мають пріоритет. Не змішуйте автоматичне хешування з уже підготовленим хешем.
Автоматичний варіант не є «поганим», а код — «професійним» за замовчуванням. Для простої форми автоматичного визначення може бути достатньо. Якщо значення з’являється після асинхронної дії, лежить усередині віджета або перезаписується, явне передавання прибирає невизначеність.
Чому статус «увімкнено» ще не означає, що все працює
Перевірка має йти тим самим шляхом, що й дані.
Спершу — основна конверсія. Вона має спрацьовувати рівно на потрібну дію. Якщо тег дублюється або не спрацьовує, розширення лише успадковує поломку.
Потім — значення. У момент події має існувати електронна адреса, телефон або допустимий набір адресних полів. Порожня змінна може виглядати правильно в контейнері й не нести жодного сигналу.
Далі — згода. Перевіряють не банер як картинку, а стан згоди, з яким фактично пішла подія. Заборонений сигнал не слід «повертати» обхідним маршрутом.
Після цього — формат і діагностика. Неправильний код країни, подвійне хешування чи випадкові пробіли знижують шанс зіставлення. Діагностика Google Ads показує, чи надходять дані та чи є помилки реалізації, але результат треба оцінювати після накопичення реальних подій.
Для сценарію з лідами додається ще одна перевірка: імпорт має повертати саме кваліфіковану дію під тим самим ім’ям конверсії та з коректним часом. Інакше кампанія отримує не зворотний зв’язок про продаж, а ще одну копію первинної заявки.
Що вважати готовим налаштуванням
Готовність — це не зелений перемикач. Є справна базова подія, законна підстава для використання даних, стабільне значення в потрібний момент, один узгоджений формат і діагностика без помилок. Для лідів до цього додається контрольований імпорт реального бізнес-результату.
Не варто обіцяти, що розширені конверсії повернуть кожну втрату. Зіставлення залежить від наявності придатного сигналу, а різниця у звіті не завжди означає втрату: інколи системи просто рахують за різними правилами.
Почніть із одного контрольного результату й простежте його шлях від форми до діагностики Google Ads, не перескакуючи жодної ланки.