Атрибуція без сліпих зон: як відстежити справжнє джерело конверсій

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

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

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

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

Ключові висновки

• Початкове джерело трафіку, останній реферер, точка взаємодії, якій зараховано конверсію, і напрямок маршрутизації – це різні сутності.
• UTM-параметри класифікують трафік, ідентифікатори кліків визначають окремі взаємодії, sub ID надають детальну інформацію про джерело, а ідентифікатори подій визначають події конверсії.
• Трекінг збирає події; атрибуція розподіляє цінність конверсії; інкрементальність вимірює причинний вплив.
• Необроблене надсилання форми не повинно автоматично вважатися схваленою конверсією або подією отримання доходу.
• Надійна атрибуція залежить від безперервності ідентифікаторів, зворотного зв’язку протягом життєвого циклу, дедуплікації, контролю шахрайства та звірки даних між системами.

Що означає «справжнє джерело» конверсії

Справжнє джерело конверсії – це найраніше надійно збережене джерело або ідентифікатор партнера, пов’язаний із трафіком, який привів до підтвердженого результату.

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

Тому справжнє джерело слід розглядати як відстежуваний факт залучення, а не як висновок про причинно-наслідковий зв’язок.

Розглянемо шлях у лідогенерації:

Паблішер → афілейт-мережа → трекінговий домен → лендинг → маршрутизатор трафіку → покупець → схвалення в CRM

Паблішер є початковим джерелом трафіку. Афілейт-мережа є посередником. Трекінговий домен фіксує клік. Маршрутизатор вибирає напрямок. Покупець отримує лід. CRM фіксує остаточний комерційний статус.

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

Корисна модель атрибуції зберігає ці сутності окремо, а не об’єднує їх в одному загальному полі source.

Чому дашборди атрибуції показують різні дані

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

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

Системи спостерігають за різними подіями.

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

Ці записи відповідають на різні запитання.

Рекламна платформа може відповідати на запитання: «Якій кампанії було зараховано конверсію відповідно до наших правил атрибуції?» Трекер може відповідати: «Який ідентифікатор кліку було прикріплено до цього постбека?» Маршрутизатор може відповідати: «Який покупець отримав лід?» CRM може відповідати: «Чи став цей лід клієнтом?»

Жодна з цих відповідей не повинна автоматично замінювати інші.

Визначення конверсії відрізняються.

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

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

Назва події повинна визначати фактичний бізнес-стан. conversion – надто загальна назва для схеми подій.

Вікна атрибуції відрізняються.

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

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

Мета не обов’язково полягає в отриманні повністю однакових підсумкових значень. Вона полягає в наявності задокументованого пояснення того, чому ці значення відрізняються.

Ланцюжок ідентифікаторів, необхідний для надійної атрибуції

Масштабована система атрибуції потребує кількох ідентифікаторів, оскільки кожен із них розв’язує окрему проблему.

• UTM-параметр описує метадані кампанії. Він може визначати джерело, канал, кампанію, варіант контенту або ключове слово, але зазвичай повторюється в багатьох відвідуваннях.
• Ідентифікатор кліку визначає конкретну відстежувану взаємодію. Він пов’язує запис про клік із подальшою конверсією або оновленням статусу.
• Sub ID афілейта надає детальний контекст, визначений партнером, наприклад паблішера, плейсмент, креатив, email-розсилку, групу оголошень або сегмент трафіку.
• Ідентифікатор події визначає одну логічну подію конверсії. Він дає змогу розпізнавати кілька повідомлень про ту саму подію як дублікати, а не як окремі конверсії.

Ці ідентифікатори не слід використовувати як взаємозамінні.

Створюйте запис про залучення до маршрутизації

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

Зрозумілі для людини назви кампаній слід зберігати як метадані, а не використовувати як первинні ключі. Назви змінюються. Внутрішні ідентифікатори мають залишатися стабільними.

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

Фіксуйте маршрутизацію як окрему подію

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

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

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

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

Повертайте результати з нижчих рівнів до початкового запису.

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

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

надіслано → прийнято → встановлено контакт → кваліфіковано → продано → оплачено → повернено кошти

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

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

Клієнтські пікселі та серверні постбеки

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

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

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

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

Від проблеми атрибуції до операційного результату

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

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

Недійсний трафік – це проблема атрибуції.

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

Media Rating Council широко визначає недійсний трафік як трафік або пов’язану з медіа активність, що не відповідає застосовним критеріям якості чи повноти або не є легітимною активністю, яку слід враховувати під час вимірювання. Це визначення охоплює не лише навмисне шахрайство та застосовується до вимірювання результатів так само, як і до кліків та показів.

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

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

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

Засоби контролю конфіденційності визначають межі вимірювання.

Серверний трекінг змінює місце оброблення даних, але не усуває зобов’язань щодо конфіденційності.

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

Коли оброблення даних відповідно до GDPR ґрунтується на згоді, Європейська рада із захисту даних зазначає, що згода повинна відповідати сукупності умов дійсності та забезпечувати реальний вибір і контроль; серверна реалізація не змінює цих вимог.

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

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

Обмеження конфіденційності можуть знижувати спостережуваність. Правильна реакція – описати цю невизначеність, а не непомітно замінювати відсутні детерміновані дані необґрунтованою впевненістю.

Атрибуція не є інкрементальністю. Атрибуція відповідає на запитання: «Яке спостережуване джерело або точка взаємодії отримує зарахування за цю конверсію?»

Інкрементальність відповідає на запитання: «Скільки додаткових конверсій відбулося завдяки маркетинговій активності?»

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

Це різні завдання вимірювання.

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

Тому зріла система вимірювання не повинна автоматично подавати атрибутований дохід як інкрементальний дохід.

Операційне керування атрибуцією у великих масштабах

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

Перша вимога – канонічний контракт подій. Кожна подія повинна мати стабільну назву, визначення, відповідального власника, унікальний ідентифікатор, правило фіксації часу, обов’язкові поля, дозволені статуси та визначену поведінку дедуплікації. lead_submitted, lead_accepted і sale_paid є зрозумілішими, ніж три системи, кожна з яких незалежно передає подію conversion.

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

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

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

Поширені сценарії помилок атрибуції

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

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

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

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

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

Поширені запитання

Що таке наскрізна атрибуція конверсій?

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

Що таке справжнє джерело конверсії?

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

Чому рекламна платформа, трекер і CRM показують різну кількість конверсій?

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

У чому різниця між UTM, ідентифікатором кліку, sub ID та ідентифікатором події?

UTM класифікує метадані кампанії. Ідентифікатор кліку визначає окрему відстежувану взаємодію. Sub ID додає детальну інформацію про партнера або плейсмент. Ідентифікатор події визначає одну логічну подію конверсії та підтримує дедуплікацію.

Чи є server-to-server трекінг кращим за піксельний трекінг?

Server-to-server трекінг краще підходить для результатів, які виникають у бекенді, і забезпечує більше контролю над моніторингом доставлення та повторними спробами. Піксельний трекінг корисний для подій у браузері. Жоден із цих методів не є автоматично точним, а гібридні конфігурації потребують безперервності ідентифікаторів і дедуплікації.

Як слід атрибутувати офлайн-конверсії або конверсії із затримкою?

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

Яка система повинна бути системою-джерелом?

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

Висновок

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

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

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