AI-система атрибуції конверсій (Multi-Touch Attribution AI)

Чому мультиканальна атрибуція розходиться з реальністю

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

Частина переходів не доносить мітку джерела: редиректи через проміжні домени, перехід із застосунку в браузер, дзвінок або оплата в точці продажів.

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

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

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

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

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

Вимірювані ефекти: швидкість, точність, частка ручних операцій

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

У розподіл потрапляють дотики, які раніше не враховувалися взагалі: переходи з листів, збережені посилання, повторні візити з іншого пристрою.

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

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

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

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

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

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

Порівняння моделей розподілу конверсій за каналами

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

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

Правила на даних розподіляють внесок за послідовностями дотиків — статистично або методами теорії ігор. Вони чутливі до якості зв’язування ідентифікаторів: на тонких сегментах ваги стають шумовими.

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

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

Етапи впровадження: від аудиту даних до передачі

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

Порядок робіт

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

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

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

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

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

6. Передача системи замовнику. Віддаємо розрахункове ядро, правила склеювання, регламент оновлення даних і звітність. Навчаємо команду: як читати звіт, додавати джерело і що робити при зміні розмітки на сайті.

Схеми потоків даних, правила розмітки та регламенти

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

• Схема потоків даних: які системи віддають події, у який момент і в якому вигляді, де лежить сирий шар, де — агрегати. За нею новий канал підключається правкою одного вузла, а не перезбиранням усього ланцюжка.
• Правила дедуплікації дотиків: вікно склеювання, пріоритет джерела, обробка повторних і порожніх подій. Один візит не перетворюється на п’ять дотиків і не завищує внесок окремого каналу.
• Довідник розмітки: обов’язкові мітки, допустимі значення, поведінка при невідомих — інакше частина трафіку йде в «прямі заходи» і звітність розходиться з реальністю.
• Розмежування доступу до звітів: ролі маркетингу, аналітики та керівництва, знеособлення персональних даних, журнал вивантажень.
• Регламент оновлення моделі: періодичність перенавчання, вікно спостереження за конверсією, хто погоджує зміну версії і як повернутися до попередньої.
• Каталог визначень: як рахуються дотик, конверсія й атрибутований внесок — цифри у звітах збігаються з даними суміжних систем.
• Порядок приймання та звірки: контрольні сценарії на історичних даних, звірка з джерелом, розбір розбіжностей і відповідальний за кожен крок.

Кейс: мультиканальна атрибуція замість останнього кліку

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

Бюджети перерозподіляли за викривленою картиною: майданчики, що формують попит, недооцінювали й поступово вимикали.

Що змінили

Дотики з Google Analytics 4, рекламних кабінетів і облікової системи зібрали в одне сховище й пов’язали з угодами за ідентифікатором клієнта та знеособленими ознаками пристрою.

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

Метрики до і після

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

Розподіл зусиль за каналами ліг в основу планування: пріоритет отримали майданчики, які раніше у звіт не потрапляли взагалі.

Що робити, якщо вже є своя аналітика та звітність?

Атрибуційна система не замінює вашу облікову систему та BI — вона стає поряд: читає лог подій, відновлює шлях клієнта до угоди й повертає ваги дотиків за каналами.

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

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

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

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

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

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

Обмеження методу та типові технічні сумніви

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

Як зіставляються пристрої одного користувача?

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

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

Що станеться, якщо змінюється розмітка кампаній?

Модель чутлива до стабільності UTM-міток і правил іменування. Перейменування кампанії або зміна схеми міток розриває історичні ряди, і частина трафіку йде в «невідоме».

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

Обговоримо задачу та повернемося з оцінкою й планом

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

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

Щоб обговорити задачу предметно й не розтягнути підготовку даних для старту, з вашого боку достатньо:

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

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