Пікселі ретаргетингу на посиланнях сторінки попереднього перегляду: як вони працюють і на що звернути увагу
Що таке посилання на сторінку попереднього перегляду і чому вони важливі
Посилання на сторінку попереднього перегляду трапляються у воронках продажів, процесах перевірки реклами, чернетках листів і демо продуктів. Це не завжди остаточна сторінка, яку бачить людина, і саме ця проста деталь змінює трекінг. Сторінка попереднього перегляду може бути staging-сторінкою, тимчасовим переходом або цільовою сторінкою для перевірки посилання. Один клік для маркетолога може означати нічого, а для пікселя ретаргетингу на сторінці попереднього перегляду — усе.
На практиці посилання на сторінки попереднього перегляду часто стоять між рекламою та офером. Команда продажів може надіслати клієнту чернетку сторінки о 9-й ранку, а живу кампанію запустити опівдні. Це два різні потоки трафіку. Якщо обидва потрапляють у ту саму систему трекінгу, піксель може зібрати змішані сигнали й підживити ретаргетинг не тією аудиторією.
Це важливо, тому що трафік попереднього перегляду зазвичай менший, більш повторюваний і менш «чистий», ніж живий трафік. Рецензент може відкрити те саме посилання 5 разів, оновити сторінку або переслати його в чаті. Піксель не знає різниці, якщо ви йому цього не скажете.
Що робить піксель ретаргетингу
Піксель ретаргетингу — це невеликий фрагмент коду, який розміщують на сторінці, щоб рекламна платформа могла зафіксувати відвідування або подію. Зазвичай він спрацьовує, коли сторінка завантажується, а в деяких налаштуваннях — ще й після натискання кнопки або надсилання форми. Потім піксель додає відвідувача до аудиторії або позначає дію для подальшого використання в рекламі.
Уявіть його як тиху печатку. Людина її не бачить, але рекламна система — так. Якщо сторінка завантажилася, піксель може спрацювати. Якщо браузер блокує скрипт, піксель може не спрацювати. Ця одна прогалина може змінити, кому покажуть вашу наступну рекламу.
Один поширений сценарій — побудова аудиторії після перегляду продукту, а інший — відстеження конверсій після реєстрації. Обидва залежать від того, чи спрацює піксель на правильній події. Якщо ви вже працюєте з пікселями ретаргетингу на коротких посиланнях, тут діє та сама обережність: сторінка, що завантажується, — це лише половина історії.
Як пікселі поводяться на посиланнях сторінок попереднього перегляду
Піксель може спрацювати на сторінці попереднього перегляду в момент завантаження HTML, навіть якщо ніхто не збирається нічого купувати. У цьому й полягає перша пастка. Якщо сторінка попереднього перегляду публічна або її запитує перевірка посилань, піксель може порахувати цей запит як реальне відвідування. Бот може стати «відвідувачем» менш ніж за 1 секунду. Саме тому важливо розуміти, як працює піксель на preview-сторінці.
Деякі сторінки попереднього перегляду блокують скрипти, доки користувач не прийме cookie-банер, не натисне «продовжити» або не пройде парольний захист. У таких випадках піксель може не спрацювати взагалі, і це звучить безпечніше, поки ви не зрозумієте, що тестові дані будуть неповними. У підсумку ви отримуєте прогалину в трекінгу, а не чисту перемогу.
Кліки по посиланнях поводяться інакше. Клік на посиланні сторінки попереднього перегляду може запустити редирект, відкрити нову сторінку або перевести на фінальну сторінку офера, де піксель спрацює знову. Через це шлях від попереднього перегляду до конверсії легко неправильно прочитати. Один клік, дві сторінки, дві можливі події.
Є також питання пікселів ретаргетингу на посиланнях сторінок попереднього перегляду, де саме посилання є частиною шляху трекінгу. Якщо preview-посилання веде людей через відстежуваний редирект, рекламна платформа може зафіксувати перехід через редирект ще до появи цільової сторінки. Якщо редирект не спрацює, піксель може взагалі не побачити клік, а ретаргетинг на посиланнях сторінки попереднього перегляду стане неточним.
Поширені варіанти впровадження
Найпростіше рішення — розмістити піксель безпосередньо в шаблоні сторінки попереднього перегляду. Кожна сторінка, зібрана на основі цього шаблону, успадковує той самий скрипт. Це працює нормально, доки сторінку попереднього перегляду не починають використовувати для чернеток, внутрішніх погоджень і живого трафіку. Один шаблон може перетворитися на три аудиторії.
Другий варіант — використовувати тег-менеджер. Піксель спрацьовує лише тоді, коли збігається правило, наприклад URL path, query string або title сторінки. Це зручно, але правило має бути точним. Якщо фільтр надто широкий, трафік попереднього перегляду просочується всередину. Якщо надто вузький — зникають реальні відвідувачі.
Деякі команди підключають піксель на рівні платформи — всередині рекламного кабінету або інструмента для лендінгів. Конструктор може пропонувати чекбокс для трекінгу сторінки, поле для ID пікселя або вбудовану опцію події. Це робить налаштування швидким. Але це ж ускладнює пошук помилок, коли скрипт захований за шарами налаштувань.
Redirect-потоки ускладнюють усе ще більше. Якщо посилання сторінки попереднього перегляду перескакує з одного URL на інший, піксель може спрацювати на першій сторінці, на другій або на обох. Точний результат залежить від того, чи редирект виконується на сервері, у браузері або з затримкою через JavaScript. 302-редирект може поводитися інакше, ніж 301, тож перевірте весь потік, перш ніж довіряти звітам. Якщо потрібно освіжити пам’ять, дивіться 301 vs 302 redirects.
Ризики відстеження не тієї сторінки або дії
Подвійне спрацювання — одна з найпоширеніших проблем. Якщо сторінка попереднього перегляду завантажує піксель, а цільова сторінка завантажує той самий піксель ще раз, одне людське відвідування може зарахуватися двічі. Це може роздути розмір аудиторії й зробити слабку сторінку здоровішою, ніж вона є насправді. Дашборд може ввічливо брехати.
Пропущені події — протилежна проблема. Сторінка може виглядати як завантажена, але піксель так і не спрацьовує, бо браузер зупинив скрипт, користувач закрив вкладку зарано або правило події чекає на дію, яка так і не відбулася. Тоді команда вирішує, що в сторінки попереднього перегляду немає трафіку. Насправді може не бути лише трекінгу.
Хибна атрибуція складніша для помітити. Колега натискає на посилання сторінки попереднього перегляду з внутрішнього треда в Slack, і це відвідування потрапляє в ретаргетинг. Пізніше та сама аудиторія бачить рекламу, призначену для реальних покупців. Рекламна платформа не знає різниці між клієнтською перевіркою та шопінг-сесією, якщо її явно не налаштували.
Є ще четверта проблема: preview-трафік, який не видно кінцевому користувачеві, може спотворювати рішення по кампанії. Якщо 12 співробітників відкриють те саме посилання під час перегляду запуску, аудиторія може наповнитися внутрішньою активністю, а не потенційними клієнтами. Це впливає на frequency, оптимізацію й звітні шляхи конверсії. Першими це відчувають невеликі команди.
Найкращі практики для точного ретаргетингу
Почніть із розділення preview-трафіку та публічного трафіку. Використовуйте окремий шлях, субдомен або environment flag, щоб правило пікселя могло ігнорувати внутрішні сторінки. Чистий поділ кращий за хитрий обхід. Якщо потрібна брендована структура, власний домен для коротких посилань допоможе тримати review-посилання окремо від живих посилань.
Уважно налаштовуйте правила подій. Піксель на завантаження сторінки — це не те саме, що піксель на клік кнопки, а подія початку заповнення форми — не те саме, що покупка. Якщо сторінка попереднього перегляду містить усі три, не спрацьовуйте на всі три за замовчуванням. Обирайте ту дію, яку справді хочете виміряти. Менше шуму, менше суперечок.
Перевіряйте все в інструментах браузера ще до запуску. Відкрийте developer tools, подивіться вкладку Network і переконайтеся, чи з’являється запит пікселя на посиланні сторінки попереднього перегляду та на цільовій сторінці. Перевірте, що відбувається при оновленні сторінки, при натисканні кнопки «назад» і на мобільному. Тест на 30 секунд може зекономити 3 дні листування з підтримкою.
Використовуйте умови завантаження сторінки, які відповідають реальному шляху користувача. Якщо сторінка попереднього перегляду призначена лише для співробітників, вимагайте пароль або токен і не допускайте цей трафік у ретаргетинг. Захищену сторінку все ще можна вимірювати, але список аудиторій не повинен поглинати всіх, хто вгадав URL. Для пов’язаного налаштування дивіться посилання, захищені паролем.
Запишіть, яка сторінка який подію запускає. Достатньо простої таблиці. У ній мають бути URL, піксель, тригер і аудиторія, яку він наповнює. Цей запис стане в пригоді, коли через три тижні кампанія зміниться й ніхто вже не пам’ятатиме, чому взагалі відстежували сторінку попереднього перегляду.
Як тестувати й усувати проблеми зі спрацюванням пікселя
| Крок тесту | Що перевірити | Типовий результат |
|---|---|---|
| Відкрийте посилання сторінки попереднього перегляду в новому браузері | Чи з’являється запит пікселя? | Завантажився один раз, двічі або не завантажився взагалі |
| Оновіть сторінку | Чи спрацьовує піксель знову? | Подвійне спрацювання або одне зафіксоване відвідування |
| Натисніть посилання всередині сторінки попереднього перегляду | Чи відстежується цільова сторінка окремо? | Дві події, одна подія або лише хіт редиректу |
| Тимчасово заблокуйте скрипти | Чи все ще відображається сторінка? | Візуально — так, піксель — ні |
Використовуйте консоль браузера, якщо вкладки Network недостатньо. Невдалий запит скрипта часто залишає помітну помилку, і ця помилка скаже вам більше, ніж рекламний дашборд. Якщо бібліотека пікселя завантажується вже після того, як користувач закрив сторінку, платформа все одно може показувати дивну неповну подію.
Порівняйте очікувану поведінку з реальною. Якщо ви очікуєте одне відвідування зі сторінки попереднього перегляду, а бачите 7, щось не так. Якщо ви очікуєте 4 події, а бачите 2, це теж проблема. Це невеликі числа, а невеликі числа легше перевірити, ніж великі.
Перевірте, чи не відкривається посилання сторінки попереднього перегляду через crawler, preview bot або link scanner. Деякі інструменти отримують сторінку ще до того, як її побачить людина. Це може спрацювати піксель і зіпсувати список аудиторії. Виправленням може бути виключення відомих user agents.
Коли залучати рекламну платформу або розробника
Звертайтеся до служби підтримки рекламної платформи, коли піксель спрацьовує не на тому URL або коли подія з’являється з неправильною назвою. Це не проблема контенту, а проблема правила трекінгу. Вони можуть підтвердити, чи платформа читає завантаження сторінки, клік або обидва.
Розробник має переглянути будь-який кастомний редирект, інжекцію скриптів або захищений потік попереднього перегляду. Якщо сторінка попереднього перегляду працює через JavaScript routing, піксель може ніколи не побачити повне перезавантаження. Якщо сторінка використовує серверні редиректи, шлях запиту може приховати початкове джерело. Ці деталі важливіші, ніж сам текст сторінки.
Просіть про допомогу, коли сторінка попереднього перегляду потребує спеціальної обробки у ширшому стеку кампанії. Це стосується рекламних тегів, аналітичних тегів, обгорток для посилань у листах і правил аудиторій на рівні акаунта. Зміна в 1 рядок може змінити аудиторію на наступні 30 днів, тож краще перевірити це зараз, ніж потім пояснювати, чому внутрішнім рецензентам показували рекламу конверсії. Якщо ваша команда також відстежує ефективність посилань у кількох кампаніях, A/B-тестування посилань допоможе відокремити поведінку сторінки від шуму трекінгу.
Деякі команди залишають трекінг попереднього перегляду, бо хочуть бачити QA-трафік. Це нормально, але лише якщо аудиторія чітко позначена й виключена зі сплачуваного ретаргетингу. Піксель — не проблема. Проблема в тому, щоб вдавати, ніби одна сторінка одночасно є і пісочницею, і продажним активом.