Чому кліки є, а конверсій немає в Adgora

Чи трекінг насправді записує подію конверсії?

Перш за все треба з’ясувати просту річ: чи спрацьовує подія конверсії взагалі? Якщо Adgora показує кліки, а в налаштуваннях нуль конверсій, почніть із перевірки точної назви події, бо одна помилка в тегу може зробити весь звіт порожнім. Саме тут найчастіше й виникає питання: чому немає конверсій при наявності кліків.

Перевірте сторінку подяки, сторінку покупки або етап підтвердження ліда. Якщо там немає пікселя чи тега, клік може відстежитися, а конверсія так і не з’явиться. У цьому немає нічого загадкового. Це просто помилка в налаштуванні.

Згода користувача теж може блокувати подію. Людина може клікнути, дійти до фінальної сторінки й усе одно не запустити конверсію, якщо банер згоди не дає змоги зберігати аналітичні дані. Такий самий ефект буде, якщо тригер чекає на елемент сторінки, який ніколи не завантажується.

Допомагає швидка перевірка: відкрийте сторінку, заповніть форму або завершіть замовлення й у реальному часі дивіться в debugger або tag assistant. Якщо ви шукаєте, як перевірити трекінг конверсій Adgora, спершу підтвердьте, що подія взагалі спрацьовує, а вже потім шукайте проблему далі. Якщо вона спрацювала двічі, це вже інша історія.

Чи не прив’язаний клік до неправильної кампанії, оголошення або плейсменту?

Іноді клік справжній, але конверсія прикріплюється до іншого джерела. Таке буває, коли UTM-параметри «пливуть», ID змінюються під час редиректів або трекер губить дані між рекламою та лендингом. Тоді Adgora показує клік в одному рядку, а конверсію — в іншому, і акаунт виглядає зламаним, хоча продаж насправді відбувся.

Кросдоменний трекінг досить часто стає причиною цього, тож його варто перевірити особливо ретельно. Якщо користувач починає на одному домені, а завершує на іншому, початкові дані кампанії можуть зникнути, якщо передачу не збережено правильно. Наприклад, оформлення на платіжному домені може зламати шлях, навіть якщо сам лендинг працює нормально.

Подивіться на точну URL-адресу кліка і порівняйте її з збереженими значеннями кампанії. Якщо реклама передає один набір ID, а платформа отримує інший, мапінг неправильний. Це проблема прив’язки трекінгу, а не проблема лендингу.

Саме тому той самий трафік може ніби конвертуватися в одному звіті й зникати в іншому. Якщо вам потрібен ширший контекст щодо того, як взаємодіють плейсмент, джерело та логіка виплат, корисно переглянути гайд CPC проти CPM і CPA. Але тут завдання простіше: переконатися, що клік і конверсія належать одному запису кампанії.

Чи не відбуваються конверсії поза вікном відстеження?

Так, і це часто застає людей зненацька. Налаштування може бути активним, подія може працювати, але продаж усе одно не отримає атрибуцію, якщо він стався занадто пізно для вікна Adgora. Правило на 30 хвилин або в межах однієї сесії достатньо жорстке, щоб втратити цілком реальні конверсії.

Уявіть покупця, який клікає вранці, читає відгуки й повертається ввечері з закладки або напряму. Продаж цілком реальний, але початковий клік уже не входить у період обліку. Системи трекінгу не вміють читати думки.

Логіка «в межах однієї сесії» може бути ще вужчою. Якщо користувач перемикає пристрій, очищує cookies або робить паузу на обід перед покупкою, конверсія може статися вже поза тією сесією, яку платформа ще вважає активною. У звіті це виглядає як «кліки є а конверсій немає», хоча проблема насправді в таймінгу, а не в попиті.

Перевірте вікно атрибуції в Adgora та порівняйте його зі своїм циклом покупки. Вікно на 1 день працює зовсім інакше, ніж на 7 днів. Якщо ваш оффер потребує більше часу на роздуми, занадто жорстке вікно приховає конверсії, які ви реально заробили.

Для трафіку, який приймає рішення довше, наприклад оферів у нішах форекс і трейдингу, помилки в таймінгу проявляються швидко, бо користувачі часто клікають, йдуть і повертаються пізніше. Це нормальна модель поведінки. Але звіт усе одно має враховувати її правильно.

Чи не рахується конверсійна дія на неправильному етапі?

Таке дуже часто трапляється після свіжого налаштування. Подію ставлять занадто рано, занадто пізно або на крок, який користувачі пропускають. Якщо відстежувана дія стоїть, наприклад, на необов’язковій сторінці опитування, урахують лише тих, хто справді дійшов і заповнив її.

Уявіть воронку оформлення замовлення з трьома сторінками. Якщо конверсія спрацьовує на сторінці кошика замість сторінки підтвердження замовлення, ви можете врахувати майже-покупку, а не завершений продаж. Якщо вона спрацьовує на сторінці підтвердження, яка не з’являється для повторних клієнтів, ви втратите частину обсягу. Розташування події важить більше, ніж багатьом командам здається.

Тестуйте шлях по кроках. Відкрийте лендинг, пройдіть далі й зафіксуйте точну URL-адресу, де має спрацювати конверсія. Якщо користувачі можуть конвертуватися, навіть не побачивши цю сторінку, подію треба ставити в інше місце.

Одна невелика помилка може перекосити все. Натискання кнопки з написом «Продовжити» — це не конверсія. Надсилання форми після останнього кроку валідації — краще. Сторінка подяки після успішної оплати — ще краще.

Якщо ви працюєте з вертикалями, де фінальна дія не є першою дією, порівняйте відстежуваний крок із реальною воронкою. Та сама логіка діє і для кампаній із встановлення мобільних застосунків, де один неправильний тригер може рахувати спробу встановлення замість підтвердженого інсталу. Різниця в коді мінімальна, а в звітності — величезна.

Чи можуть браузер, згода або обмеження скриптів пригнічувати конверсію?

Так. Функції приватності браузера, відмова від cookies, блокувальники реклами та затримане завантаження скриптів можуть зупинити подію конверсії, хоча клік при цьому залишиться відстеженим. Клік часто спрацьовує на боці рекламної платформи, а конверсія залежить від скрипта в браузері, який може так і не запуститися.

Обмеження приватності Safari, жорсткіші налаштування cookies і розширення, які блокують трекери, створюють прогалини. Користувач може зайти на сторінку, заповнити форму і навіть побачити сторінку підтвердження, але платформа нічого не отримає. Це дратує, але технічно цілком звично.

Окремо варто перевірити сценарій згоди. Якщо конверсійний тег чекає на згоду, а користувач відмовляється, клік буде видимий, а конверсія — заблокована. Якщо згоду надано вже після того, як сторінка завантажилася, тег може пропустити момент, якщо не налаштований на пізніший запуск.

Порядок завантаження скриптів також важливий. Якщо конверсійний скрипт завантажується після редиректу сторінки або якщо спочатку ламається інший скрипт, код трекінгу може взагалі не виконатися. Один зламаний файл здатен зупинити все інше. Це не теорія, а звичайна поведінка фронтенд-багів.

Для команд, які питають «чому Adgora показує кліки, але не показує конверсії після налаштування трекінгу», браузерний рівень — одне з найшвидших місць для перевірки. Відкрийте сторінку в приватному вікні, а потім повторіть тест у звичайному браузері з вимкненими розширеннями. Дві перевірки кращі за здогадки.

Чи не перезаписують конверсію дублікати або конфліктні теги?

Дубльовані теги спричиняють більше плутанини, ніж більшість людей очікує. Два контейнери Google Tag Manager, плагін платформи та ручний піксель на одній сторінці можуть конфліктувати, дублювати або взаємно замінювати дані подій. У результаті може бути або нуль конверсій, або конверсія, що з’являється під неправильним іменем дії.

Конфлікти зазвичай з’являються після «швидкого виправлення». Хтось ставить другий тег, бо перший нібито повільний. Хтось інший додає плагін, бо перший складно редагувати. Потім одна й та сама подія спрацьовує двічі або взагалі не спрацьовує.

Перевірте, чи один тег не перезаписує параметри іншого. Якщо один скрипт надсилає порожнє значення після того, як інший уже відправив правильне, другий хіт може стерти перший. Для цього не потрібен великий стек. Досить двох маленьких елементів.

Також перевірте, кому належить контейнер. Плагін форми може відправляти власну подію ліда, а ваш кастомний тег — чекати іншого тригера. Якщо обидва намагаються повідомити про ту саму дію, платформа може дедуплікувати одну подію і відкинути іншу. Через це кількість конверсій виглядає меншою за реальну активність.

Одна з причин, чому багато команд ведуть просту довідкову таблицю в глосарії ad tech, — саме така плутанина. Терміни тут не для краси. Вони допомагають менш ніж за 10 хвилин відрізнити конфлікт тегів від проблеми з таймінгом.

Що перевіряти, якщо кліки є, а сторінка конверсії виглядає нормально?

Починайте з передачі даних, а не з дизайну сторінки. Лендинг може виглядати ідеально й усе одно втрачати конверсію між кліком і оформленням через ланцюг редиректів, зміну домену або платіжного провайдера, який ламає шлях повернення.

Пройдіть шлях користувача по порядку: клік по рекламі, лендинг, надсилання форми, checkout, сторінка повернення. Якщо будь-який із цих кроків переводить на інший домен без збережених параметрів, конверсія може зникнути з Adgora, навіть якщо користувач завершив дію. Це сценарій технічної втрати, а не проблема креативу.

Платіжні провайдери заслуговують окремої уваги. Якщо клієнт завершує оплату на сторонньому домені й ніколи не повертається на сторінку підтвердження, конверсійний скрипт на вашому сайті може так і не отримати шансу спрацювати. Продаж є, а події немає. Такий розрив трапляється дуже часто.

Редиректи також можуть забирати ідентифікатор, потрібний для атрибуції. Один зайвий перехід з HTTP на HTTPS або з одного піддомену на інший може порушити ланцюжок, якщо трекінг не був до цього підготовлений. Перевіряйте весь шлях, а не лише перший клік.

Якщо ви запускаєте офери, які сильно залежать від коректного шляху повернення, наприклад платний трафік на дропшипінг або дейтингові офери, ця перевірка стає ще практичнішою. Одна відсутня сторінка повернення може створити враження, що кампанія мертва, хоча офер усе ще конвертує.

Використовуйте короткий діагностичний шлях: підтвердьте, що подія спрацьовує, підтвердьте прив’язку кампанії, підтвердьте вікно атрибуції, підтвердьте розташування кроку, підтвердьте браузерні обмеження, а потім підтвердьте конфлікти тегів. Шість перевірок саме в такому порядку ловлять більшість випадків швидше, ніж зміна самої реклами.