Google Ads об'єднує Enhanced Conversions для веб і Enhanced Conversions for Leads (ECL) в один перемикач on/off із паралельним прийомом даних через gtag + Data Manager + Google Ads API. Кожен гайд із налаштування EC, написаний до квітня 2026, тепер структурно неправильний — а найдорожча помилка в аудиті — це залишені EC-теги, які стріляють паралельно з Data Manager-завантаженнями і подвоюють той самий сигнал у Smart Bidding.
Що означає уніфікація + бенчмарк
До квітня 2026 рекламодавець обирав ОДИН метод імплементації Enhanced Conversions на кожний conversion action: або Google tag, або Google Tag Manager, або Google Ads API. ECL був окремим продуктом зі своїм перемикачем, термінами і діагностичним звітом. З квітня 2026 Google Ads приймає user-provided data з тегів сайту (gtag/GTM), Data Manager-конекторів (BigQuery, HubSpot, Shopify, Google Drive, Salesforce) і API-підключень (новий Data Manager API плюс старий ConversionUploadService) ОДНОЧАСНО (PPC Land, 2026-04-12). З червня 2026 інтерфейс вибору методу прибирають повністю, а EC + ECL зливаються в один перемикач на рівні акаунта (Goals → Settings → Customer data use) і на рівні кожного conversion action (Search Engine Land, 2026-04-10).
Дві суміжні дедлайни формують контекст аудиту:
- 15 червня 2026 — нові developer tokens блокують від
ConversionUploadService.UploadClickConversions; нові інтеграції offline-імпорту мають використовувати Data Manager API (PPC Land, 2026-05-18). - Грудень 2025 — Data Manager API став основною кінцевою точкою прийому first-party даних у Google Ads, GA4 і DV360, з уніфікованою схемою та OAuth-scope, відмінним від Google Ads API.
Операційний бенчмарк: у чистому пост-уніфікаційному налаштуванні діагностика Receiving на conversion action має показувати ≤ 1 активний шлях на тип сигналу, якщо на всіх шляхах немає ключів дедуплікації. Все інше — ризик подвійного підрахунку.
Топ причин (за частотою в аудитах)
- Старий gtag-EC досі стріляє після переходу на Data Manager API — найпоширеніше. Маркетинг переніс вимірювання лідів на Data Manager API у Q1 2026; ніхто не зняв оригінальний gtag-EC сніпет зі сторінки thank-you. Результат: той самий лід прилітає двічі.
- Конфігурація тільки ECL, що сприймається як «EC увімкнено» — акаунти, де ввімкнули лише Leads, веб-EC ніколи не налаштовували, а аудитор ставить позначку «EC зроблено», не помічаючи, що веб-конверсії досі тільки на голому gclid.
- Конфігурація тільки веб-EC без пайплайну лідів — обернений випадок. EC увімкнено на дії покупки на сайті; conversion action для form-fill взагалі не має шляху Customer Data, тож CRM-завантажені closed-won-значення прилітають без ключів user-provided data.
- Автомігрований стек без ключів дедуплікації — автоміграція Google у червні 2026 зберігає те, що було активним. Якщо gtag-EC стріляє без event ID І Data Manager заливає ту саму подію без
order_id— Google не може дедуплікувати; Smart Bidding бачить роздутий сигнал. - Застаріле прийняття Customer Data Terms — акаунти, де термсам сказали «так» за старим адміном, який пішов; новий перемикач тихо неактивний хоча б на одному шляху прийому.
- Кілька API-інтеграцій від агенції + in-house команди — ConversionUploadService досі працює зі стеку агенції, а in-house інженери підняли Data Manager API-завантаження. Жодного власника, який мапить, який шлях покриває який conversion action.
- Діагностика ECL сприймається як здоров'я всього акаунта — старий ECL-звіт діагностики покривав лише шлях Leads; після уніфікації він не відображає match-rate на веб-стороні, але аудитори продовжують на нього посилатися.
Діагностичний чекліст
Проходьте згори вниз для кожного conversion action — виправлення одного шляху, поки інший дублює ту саму подію, просто зміщує над-підрахунок.
| # | Перевірка | Де в інтерфейсі / API | Поріг |
|---|---|---|---|
| 1 | Стан уніфікованого перемикача EC (рівень акаунта) | Goals → Settings → Customer data use | ON + Data Processing Terms прийняті чинним адміном |
| 2 | Шляхи прийому на кожному conversion action | Goals → Conversions → дія → Diagnostics | Перелічити КОЖНИЙ активний шлях: gtag, Data Manager-конектор, API |
| 3 | Ключ дедуплікації на кожному шляху | gtag: transaction_id; Data Manager: order_id; API: order_id | Однакове значення ключа на всіх шляхах для тієї самої події, або активний ЛИШЕ один шлях |
| 4 | ConversionUploadService досі в роботі? | Логи викликів Google Ads API / runbook агенції | Якщо так, планувати міграцію на Data Manager API до 15 червня 2026 |
| 5 | Match rate на кожному шляху прийому | Conversion action → стовпець User-provided data | ≥ 50% match для веб-EC; ≥ 30% для CRM-джерельного ECL (за Google) |
| 6 | Перехресна звірка з GA4 для тієї самої події | GA4 → Conversions за той самий період | Кількість у Google Ads > ніж у GA4 на >20% → підозра на дублювання |
| 7 | Мапа власників кожного шляху прийому | Внутрішній док / нотатки аудиту Whitead | На кожному шляху іменований власник; якщо ні — вимкнути |
Шляхи виправлення
Порядок має значення — вимкнути дублюючі шляхи треба ДО полювання на match rate, інакше тюнитимете сигнал, який уже роздутий.
Інвентаризація всіх шляхів прийому на кожному conversion action. Для кожного
conversion_action_idперелічіть: (а) gtag/GTM-теги, що стріляють зараз, (б) активні Data Manager-конектори, (в) API-інтеграції (новий Data Manager API і будь-які залишковіConversionUploadService-джоби). Будь-який шлях без іменованого людського власника — кандидат на видалення.Оберіть основний шлях на тип сигналу і додайте ключі дедуплікації на всіх інших. Чиста форма: веб-purchase через gtag з
transaction_id; offline closed-won через Data Manager API з тим самимorder_id. Там, де два шляхи мусять співіснувати тимчасово, обидва МАЮТЬ нести одне й те саме значення ключа; Google автоматично дедуплікує поorder_id + conversion_action_id(Довідка Google Ads — About offline conversion imports, 2026).Вимкніть надлишкові шляхи. Якщо gtag-EC ніс form-fill до того, як ECL пішов live, і форму тепер покривають завантаження Data Manager API з CRM — ВИДАЛІТЬ gtag user-provided-data сніпет зі сторінки thank-you. Не покладайтеся лише на дедуп Google — він вимагає, щоб ключ був присутній і ідентичний.
Перебазуйтеся через 14 днів після кожної зміни. Smart Bidding споживає той обсяг, що приходить; зняття дублюючого шляху виглядатиме як падіння конверсій. Анотуйте кампанію і тримайте ставки без змін до 14д чистих даних — див. фазу навчання Smart Bidding.
Мігруйте залишкові
ConversionUploadService-джоби на Data Manager API. Нові developer tokens блокують відUploadClickConversionsз 15 червня 2026; існуючі токени мають тимчасовий доступ під час міграції, але схема й OAuth-scope відрізняються — заплануйте інженерний час.Повторно прийміть Customer Data Terms чинним адміном. Якщо користувач, який прийняв терми у 2024, більше не має Admin-доступу, прийміть повторно під уніфікованою панеллю; інакше перемикач тихо неактивний. Див. fix-admin-access-excessive щодо governance-сторони.
Оновіть runbook аудиту. Замініть будь-які доквітневі-2026 EC-інструкції у вашій командній wiki. Екрана вибору методу більше не існує; цитуйте шлях уніфікованої панелі натомість.
Методологічна примітка. Перевірка enhanced_conversions_unified Whitead розгортається на кожен conversion action і перелічує всі активні шляхи прийому через діагностичний endpoint conversion-action у Google Ads API плюс скан GTM-контейнера (коли підключено GTM-credentials). Правило позначає conversion action, коли активні ≥ 2 шляхи прийому І на ≥ 1 шляху відсутній ключ дедуплікації. Тіри тяжкості: 2 шляхи з повними ключами дедупу (попередження), 2 шляхи з одним відсутнім ключем (high), ≥ 3 шляхи без єдиного власника (critical). Логіка пріоритету фіксу виносить нагору шлях-без-власника, бо саме він найімовірніше тихо подвоює і його найдешевше вимкнути. Перевірка явно НЕ рекомендує вимикати Data Manager API-завантаження на користь старих шляхів — таймлайн depreцiації робить це неправильним напрямком.
Коли ескалювати
Ескалюйте акаунт на review архітектури вимірювання (а не тактичний фікс в UI), якщо:
- Conversion actions показують ≥ 3 активних шляхи прийому І кожним володіє інша команда (агенція, in-house інженерія, marketing ops) — потрібна зустріч з мапою власників до того, як вимкнути будь-який шлях, інакше зламаєте звітність вниз по течії, яку ніхто не задокументував.
- Кількість конверсій у Google Ads перевищує кількість у GA4 на >30% на тій самій цілі протягом 14 днів І match rates виглядають здоровими на всіх шляхах — дублювання структурне, а Smart Bidding імовірно вже навчився на роздутому сигналі; призупиніть зміни bid-стратегії до прибирання, потім увійдіть у фазу навчання усвідомлено.
- Будь-який залишковий
ConversionUploadService-джоб досі обслуговує нове вимірювання лідів після травня 2026 — інженерне рішення, не Ads UI; cutover 15 червня блокує нові токени, і ваш in-house API-клієнт може не пережити міграцію схеми без dev-роботи.
Пов'язані поняття
- Enhanced Conversions — базовий глосарій про те, що таке EC і як user-provided data хешуються та матчаться.
- Enhanced Conversions for Leads — тепер злитий sibling-продукт; цитуйте для до-уніфікаційного пайплайну лідів.
- Offline conversion import — ширший плейбук OCI; Data Manager API тепер основний шлях прийому.
- Conversion tracking — батьківське поняття; EC — один із трьох шарів вимірювання поверх нього.
- fix-enhanced-conversions-not-enabled — finding-стаття, що тригериться, коли жоден EC-шлях не активний на акаунті.
- Data-driven attribution — точність DDA залежить від чистого, дедуплікованого сигналу конверсій; цей плейбук — вище по течії.
- GA4 → Google Ads import — поєднуйте цей аудит з аудитом GA4-імпорту, щоб не нашаровувати дублювання поверх дублювання.
Джерела
- Updates to your enhanced conversions settings — Довідка Google Ads, 2026-04
- About enhanced conversions for leads — Довідка Google Ads, 2026-04
- About offline conversion imports — Довідка Google Ads, 2026-04
- Google Marketing Live 2026: Turn your data into decisions — Google Blog, 2026-05-05
- Google Ads simplifies enhanced conversions into a single switch — Search Engine Land, 2026-04-10
- Google Ads finally collapses enhanced conversions into a single toggle — PPC Land, 2026-04-12
- Google blocks new offline conversion imports via Ads API from June 15 — PPC Land, 2026-05-18