Розширені конверсії — це два продукти: EC для вебу гешує PII при спрацюванні конверсії; EC для лідів зіставляє GCLID із гешованим email на момент продажу.
Що відновлюють розширені конверсії
Розширені конверсії (Enhanced Conversions) доповнюють стандартний тег конверсії першоджерельними даними клієнта (email, телефон, імʼя, адреса), гешованими алгоритмом SHA-256 у браузері та зіставленими з обліковими записами Google, щоб відновити конверсії, втрачені через зникнення cookies, кросдевайсні шляхи й брак згоди. Google повідомляє, що рекламодавці отримують у середньому +5% додаткових конверсій у Пошуку після увімкнення EC (Google Ads Help, 2026-01-15), а зрілі впровадження відновлюють до +25% на YouTube (Conversios, 2025-09-12). У звʼязці з Consent Mode v2 Advanced та server-side тегуванням сумарне відновлення сягає 30-50% інакше втрачених конверсій (Conversios, 2025-09-12). Гешування відбувається на клієнтській стороні до того, як дані залишають браузер, тож сирі PII до Google не потрапляють.
EC для вебу проти EC для лідів
Обидва варіанти мають однакову назву й один стандарт гешування, але розвʼязують різні задачі. EC для вебу доповнює конверсію на сайті; EC для лідів зіставляє офлайн-подію закритого продажу з початковим кліком — стандарт для B2B, де конверсія відбувається у CRM через тижні.
| Параметр | EC для вебу | EC для лідів |
|---|---|---|
| Тригер | Конверсія на сайті (відправка форми, покупка) | Офлайн-подія з CRM (закритий продаж, MQL) |
| Ідентифікатор | Гешовані дані користувача (email, телефон, імʼя, адреса) | GCLID або гешований email/телефон, привʼязаний до кліку |
| Реалізація | Google Tag, GTM або server-side тегування | Завантаження через інтерфейс Google Ads, OCI API чи CRM-конектор |
| Сценарій | E-commerce, лідогенерація у тій самій сесії | B2B, довгі цикли, мультитач-угоди |
| Приватність | Першоджерельні дані, гешовані до передачі; не для націлювання | Той самий стандарт гешування; сирі PII ніколи не виходять із CRM відкритими |
Типовому B2B-акаунту потрібні обидва: EC для вебу — для відновлення конверсій з форм у реальному часі, EC для лідів — щоб годувати автоматичні стратегії ставок сигналом закритого продажу, який реально передбачає виторг.
Як увімкнути розширені конверсії
Для EC для вебу через Google Tag перейдіть Цілі → Конверсії → Зведення, відкрийте конверсійну дію, розгорніть Розширені конверсії, увімкніть тумблер і оберіть джерело Google tag. Для GTM встановіть Conversion Linker і ввімкніть змінну даних користувача на тегу Google Ads Conversion Tracking. Перевірка через Tag Assistant: переконайтеся, що навантаження enhanced_conversions_data містить гешовані поля em, ph чи addr, і що Match status показує ≥70% протягом 7 днів. Для EC для лідів увімкніть той самий тумблер, але оберіть джерело Customer data, після чого завантажуйте конверсії через інтерфейс Google Ads, API офлайн-імпорту конверсій (OCI) або CRM-конектор. У 2025 році Google почав мігрувати рідну Salesforce-інтеграцію OCI до Google Ads Data Manager — нові підключення Salesforce варто будувати через Data Manager (Google Ads Help, 2025-10-08).
В аудитах Whitead найпоширеніша поломка EC — це не зламана реалізація, а її відсутність. EC для вебу вимкнено приблизно на половині акаунтів, які беремо на онбординг, а EC для лідів повністю відсутні у B2B-акаунтах у ~70% випадків — навіть там, де CRM віддає закриті продажі тривіально. Друга поломка — тиха: EC увімкнено, Google показує «Recording», але відсоток відповідності завмер на 30-40%, бо dataLayer штовхає сирий email_address у поле, яке тег не читає. Здорове впровадження показує ≥70% на вебі та ≥85% на лідах. Будь-що нижче — це баг конфігурації, а не обмеження функції, і шукати його треба у навантаженні Tag Assistant, а не на сторінці налаштувань EC.
Поширені хибні уявлення
EC доповнює стандартний тег конверсії, а не замінює його, і не передає сирі PII до Google. Документація Google формулює це прямо:
"Enhanced conversions uses a secure one-way hashing algorithm called SHA256 on your first-party customer data, such as email addresses, before sending to Google." (Google Ads Help, 2026-01-15)
Які наслідки для приватності?
EC використовує першоджерельні дані, які клієнт сам вам надав. Гешування SHA-256 на клієнтській стороні означає, що Google отримує лише геш. Геші зіставляються з власними гешами Google для авторизованих користувачів; незіставлені відкидаються. Дані EC не використовуються для націлювання — лише для атрибуції. Якщо користувач відмовив у ad_storage під Consent Mode v2, навантаження EC не відправляється.
Де саме відбувається гешування?
На клієнтській стороні, у браузері, силами Google Tag або GTM-контейнера, перед мережевим запитом. Для server-side тегування геш формується у вашому серверному контейнері перед пересиланням до Google. Відкриті PII не доходять до краю мережі Google. SHA-256 — єдиний прийнятний алгоритм.
Чи замінює EC стандартний тег конверсії?
Ні. EC накладається поверх наявної конверсійної дії. Базовий тег фіксує конверсію, EC збагачує її гешованими даними. Якщо вимкнути базовий тег, EC не матиме що збагачувати.
Повʼязані концепції
Розширені конверсії стоять на перетині вимірювання та згоди. Див. Відстеження конверсій — базовий тег, який EC доповнює; Режим згоди (Consent Mode v2) — шар згоди, який пропускає або блокує навантаження EC; та Автоматичне призначення ставок (Smart Bidding) — стратегія, що споживає відновлений сигнал.
Джерела
- About Enhanced Conversions — Google Ads Help, 2026-01
- Set up Enhanced Conversions for Leads — Google Ads Help, 2026-02
- Enhanced Conversions: 2025 implementation guide — Conversios, 2025-09
- About consent mode — Google Ads Help, 2026-04 (моделювання як комплемент до EC)
- Google Ads Data Manager замінює рідну Salesforce-інтеграцію OCI — Google Ads Help, 2025-10
- Enhanced conversions for web нові діагностики — Search Engine Land, 2025-08