Відстеження конверсій після втрати файлів cookie: практичний посібник щодо підвищення якості сигналу

Вступ

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

Чому показники конверсій на основі браузера стали менш повними

Відстеження в браузері залежить від наявності сигналів у той момент, коли відвідувач заходить на сайт і виконує дію. Обмеження на сторонні файли cookie можуть ускладнити зв’язування активності між сайтами. Налаштування конфіденційності в iOS можуть обмежувати сигнали, доступні рекламодавцям, тоді як блокувальники реклами можуть заважати роботі деяких тегів або надсиланню запитів. Ці ефекти варіюються залежно від браузера, налаштувань користувача, конфігурації сайту та каналу; вони не означають, що кожна конверсія в браузері зникла.

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

Створіть основу на основі власних даних про події

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

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

Що насправді змінюють API відстеження та конверсії на стороні сервера

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

Платформи реалізують ці завдання по-різному. У посібнику щодо Conversions API від Meta описано використання серверних подій разом із Meta Pixel, а також зіставлення назв подій та ідентифікаторів, щоб запобігти подвійному підрахунку подій, що перекриваються. Функція «Розширені конверсії для веб-сайтів» у Google Ads доповнює існуючий тег конверсії хешованими даними про клієнтів від першої сторони, які Google може спробувати зіставити, за умови дотримання вимог щодо налаштування та політики. Це не просто замінний серверний тег. У документації до Conversions API від LinkedIn також описано дедуплікацію ідентифікаторів подій, коли події браузера та API використовуються разом.

Доставлена подія не обов’язково є зіставленою або атрибутованою подією. Кожна платформа застосовує власні правила зіставлення та звітності, тому підтвердження API слід розглядати як доказ доставки, а не як доказ того, що кожна конверсія з’явиться у звіті про кампанію.

Забезпечте точність подій за допомогою зіставлення, дедуплікації та контролю якості

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

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

Пов’язуйте сигнали кампаній із потенційними клієнтами та доходом

Для B2B-команд та підприємств із довшими циклами продажів заповнення форми часто є проміжною подією. Деякі запити перетворюються на кваліфіковані можливості, інші — ні. Пов’язування інформації про залучення з наступними етапами CRM допомагає команді відрізнити кампанії, що генерують активність, від тих, що приносять цінний результат. Для цього потрібен надійний спосіб збереження відповідної інформації про джерело та оновлення статусу потенційного клієнта у міру просування процесу продажів.

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

Практична процедура вимірювання для маркетологів

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

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