Як вибрати модель атрибуції для наскрізної аналітики

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

Це і є атрибуція. Обрана модель напряму впливає на те, які кампанії ви масштабуєте, а які вимикаєте. Далі в матеріалі розкажу:

1. Що таке модель атрибуції простими словами.
2. Конкретні сценарії: що обрати різним бізнесам.
3. Три речі, які ламають наскрізну атрибуцію ще до вибору моделі.
4. Типові помилки при виборі атрибуції.
5. Довідник: як працює кожна модель.

Що таке модель атрибуції простими словами

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

Різні моделі «побачать» цю покупку по-різному:

• Last Click віддасть усі 5000 грн прямому заходу (або email, якщо ігнорувати direct);
• Linear розділить порівну — по 1250 грн кожному каналу;
• Data-driven розподілить нерівномірно — на основі того, як подібні шляхи зазвичай завершуються конверсією у ваших даних.

Жодна модель не є «істиною». Це різні лінзи, через які ви дивитесь на одні й ті самі дані.

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

Конкретні сценарії: що обрати різним бізнесам

Малий e-commerce (до ~400 покупок на місяць)

Рекомендація: Last non-direct click.

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

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

Середній і великий e-commerce (400+ покупок на місяць)

Рекомендація: Data-driven у GA4 + linear або позиційна логіка на сирих даних у BigQuery для перевірки.

Типовий шлях покупця в e-commerce — 4–8 точок контакту: 

• соцмережі на етапі знайомства; 
• пошук на етапі порівняння; 
• ремаркетинг; 
• прямий захід для покупки. 

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

B2B і послуги з довгим циклом угоди (нерухомість, авто, enterprise-софт)

Рекомендація: власна атрибуція на даних CRM + сирих даних GA4, а не стандартні моделі GA4.

Причини дві. Перша — вікно атрибуції: цикл угоди на 3–6 місяців не вміщається у стандартні налаштування, і верх воронки систематично недооцінюється.
Друга — конверсія відбувається не на сайті: заявка це ще не гроші, а GA4 не бачить, яка з 50 заявок стала угодою на мільйон. 

Тут наскрізна аналітика обов’язкова: зіставте client_id з угодами в CRM і порахуйте атрибуцію по виграних угодах, а не по лідах. Модель — linear або position-based (U-shaped — 40/20/40) як стартова точка: вони прості, пояснювані і не потребують ML-обсягів. Якщо угод достатньо, наступний крок — W-shaped (перший дотик, створення заявки, створення угоди в CRM) або алгоритмічні підходи: ланцюги Маркова і вектор Шеплі, про них у довіднику в кінці статті.

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

Лідогенерація з коротким циклом (доставка, локальні послуги, інфопродукти)

Рекомендація: Last click і не ускладнюйте.

Якщо клієнт конвертується за 1–2 сесії, розподіляти цінність нема між чим. Ресурси краще вкласти в якість передачі даних (валідні UTM, коректний імпорт конверсій у рекламні кабінети), ніж у складну модель.

Мобільні застосунки

Рекомендація: атрибуція MMP (AppsFlyer, Adjust, Branch.io) як основа, GA4  як допоміжне джерело.

Мобільна атрибуція — це окремий світ: SKAdNetwork на iOS, view-through конверсії, фрод. MMP вирішують саме ці задачі. Порівнювати цифри AppsFlyer і GA4 «в лоб» не можна — у них різна логіка (наприклад, MMP рахує і покази, а GA4 тільки кліки, що згенерували сесію). Обирайте одне джерело істини для рішень про бюджет.

Коротка шпаргалка

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

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

1. Склейка ідентифікаторів

Фраза «зшиваємо client_id з угодами в CRM» звучить як простий технічний крок, а на практиці це найважча частина всього пайплайну. Що за нею стоїть:

1. Збереження gclid / utm-міток у приховані поля форми і подальша їх передача в CRM — без цього угода приходить в систему взагалі без джерела.

2. Дзвінки й офлайн-угоди. Заявка телефоном не має client_id за визначенням. Тут потрібен колтрекінг із підміною номерів і зв’язуванням сесії з дзвінком.

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

Практичний висновок: перш ніж сперечатися про linear vs data-driven, порахуйте, який відсоток угод у CRM взагалі має валідне джерело. Якщо це 60% — модель атрибуції ви обираєте для 60% бізнесу.

2. У BigQuery-експорті GA4 немає ваги атрибуції

Вага критично важлива саме для зв’язки «DDA + проста модель на сирих даних», хоча це й неочевидно.

Сирий event-level експорт GA4 у BigQuery містить події, параметри сесій і джерела трафіку, але не містить розподілу цінності конверсії між точками контакту. Вага, яку ви бачите у звітах інтерфейсу, там відсутня, і вивантажити її не можна.

Це означає, що будь-яка атрибуція на сирих даних будується з нуля: ви самі збираєте шляхи користувачів, самі пишете логіку розподілу, самі валідуєте. Кастомна модель на BigQuery — це не «експорт DDA в SQL», це окремий аналітичний продукт.

3. Consent Mode і змодельовані конверсії

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

У BigQuery-експорт змодельовані конверсії не потрапляють.

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

Кейс: коли consent з'їдає половину ідентифікаторів

На одному з наших проєктів згода відсікала близько 50% GA-ідентифікаторів. Будувати атрибуцію звичним шляхом — за сирими подіями у BigQuery — на таких даних було безглуздо: половини шляхів там просто немає, а моделювання, яким GA4 закриває цю прогалину в інтерфейсі, в експорт не приходить.

Рішення виявилось простішим за спроби «полагодити» сирі дані. 

У GA4 є два принципово різні канали доступу до даних: сирий event-level експорт у BigQuery та агрегований Data API. Ми почали вивантажувати транзакції з джерелами саме через API, адже він віддає дані уже за тією моделлю атрибуції, яка налаштована в інтерфейсі, з урахуванням моделювання.

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

Ширший висновок: за низького рівня consent сирі дані перестають бути «більш правдивим» джерелом. Іноді агрегований API з моделлю Google дає чеснішу картину, ніж власна атрибуція, побудована на урізаних шляхах.

Типові помилки

1. Вірити, що DDA працює, коли вона фактично не працює. GA4 не повідомляє, що моделі бракує даних. Перевіряйте це через Model Comparison: якщо data-driven і last click дають ідентичні цифри — ви дивитесь на last click.

2. Порівнювати конверсії GA4 і Meta Ads і шукати «правильну» цифру. Meta рахує view-through і будь-які взаємодії з рекламою, GA4 — тільки кліки з сесією. Це різні методології, а не помилка трекінгу.

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

4. Дивитись на session source і вважати, що це data-driven. Налаштування атрибуції в GA4 впливають лише на параметри без префіксів session/first user. Звіт із session source — це завжди last click, незалежно від налаштувань.

5. Міняти модель і порівнювати результати «до/після» як динаміку каналів. Після зміни моделі показники в каналах міняються, хоча в реальності вони стабільні. Фіксуйте дату зміни й не порівнюйте такі періоди напряму.

6. Обирати модель раз і назавжди. Модель атрибуції — це інструмент під конкретне питання. «Які кампанії масштабувати?» — дивіться DDA або linear. «Скільки коштує остання взаємодія перед покупкою?» — last click. Тримайте дві моделі поруч і приймайте рішення там, де їхні висновки збігаються.

Довідник: як працює кожна модель

Last Click (останній клік)

100% цінності передається останньому каналу перед конверсією. У варіанті last non-direct click прямі заходи ігноруються, якщо перед ними був інший канал.

Плюси: 

• максимально проста і прозора, будь-хто в команді зрозуміє звіт; 

• не потребує великих обсягів даних; 

• легко звіряти між системами (Google Ads, GA4, CRM).

Мінуси: 

• систематично недооцінює верхні етапи воронки — медійку, соцмережі, контент-маркетинг; 

• переоцінює брендовий пошук і ремаркетинг, тобто канали, які «добивають» уже теплого клієнта; 

• рішення на її основі часто ведуть до вимикання кампаній, які насправді генерують попит.

Правило-базовані моделі, яких більше немає в інтерфейсі GA4

У листопаді 2023 року Google прибрав з GA4 одразу чотири моделі: linear, first click, time decay і position-based. В інтерфейсі залишились три опції:  data-driven, last click і Google paid channels last click.

Чому Google їх прибрав. Офіційна аргументація: правило-базовані моделі розподіляють цінність довільно. Логіка на кшталт «порівну» чи «40/20/40» не випливає з даних, це припущення, зафіксовані в коді. Google робить ставку на data-driven як на модель, що рахує внесок каналів на основі фактичної поведінки користувачів, і паралельно потребує єдиної моделі для автостратегій в Ads. Спрощення інтерфейсу стало приємним побічним ефектом.

Чому ми все одно ними користуємось. У наскрізній аналітиці ці моделі нікуди не зникли: якщо ви будуєте атрибуцію на сирих даних у BigQuery, на даних CRM або в сторонніх системах, вони доступні і часто корисні. Причини три: їхню логіку легко пояснити як клієнту, так і керівнику, вони не потребують значних наборів даних для машинного навчання (яких у B2B не буде ніколи), і вони працюють як контроль для «чорної скриньки» DDA.

Коротко про кожну:

1. Linear — цінність ділиться порівну між усіма точками контакту. Визнає внесок усіх каналів і не «вбиває» верх воронки, але розмиває картину: банерний показ і фінальний клік отримують однакову вагу. Хороший компроміс, коли даних замало для data-driven.

2. First Click — 100% цінності віддається першому дотику. Відповідає на питання «який канал приводить нових клієнтів». Модель корисна як друга лінза поруч із last click: розрив між ними показує, наскільки різні канали генерують і закривають попит.

3. Time Decay — що ближче дотик до конверсії, то більша його вага (типово — напіврозпад 7 днів). Компроміс між linear і last click для коротких і середніх циклів.

4. Position-based (U-shaped) — 40% першому, 40% останньому, 20% порівну решті. Логіка: найважливіше — привести клієнта до цільової дії. Для B2B існують розширення W-shaped і Z-shaped, які додають вагу моменту створення ліда та закриттю угоди.

Google paid channels last click (Ads-preferred)

Третя опція в налаштуваннях атрибуції GA4: 100% цінності останньому кліку по платних каналах Google, якщо вони були у шляху. Це модель не для аналітики, а для оптимізації Google Ads: з нею конверсії, імпортовані в Ads, «підсвічують» платні кампанії. Для звітів наскрізної аналітики вона не підходить, оскільки за визначенням упереджена на користь одного рекламного джерела.

Data-driven (DDA)

Алгоритмічна модель: машинне навчання аналізує конверсійні та неконверсійні шляхи саме у ваших даних і рахує фактичний внесок кожної точки контакту. Зараз це модель за замовчуванням у GA4.

Плюси: 

• найближча до реальності, враховує порядок, кількість і тип взаємодій; 

• показує цінність асистуючих каналів, яку last click ховає; 

• автоматично адаптується до змін у поведінці аудиторії.

Мінуси:

1. Потребує обсягу даних. Google не публікує точного порога для GA4. На практиці при низьких обсягах конверсій DDA дає результати, майже ідентичні last click, адже моделі просто немає на чому вчитися. Перевіряйте через Model Comparison.

2. «Чорна скринька»: ви не можете пояснити клієнту чи керівнику, чому кампанія отримала саме 23% цінності.

3. Працює тільки на даних, які бачить Google. Офлайн-продажі, дзвінки, угоди з CRM без імпорту в GA4 модель не враховує.

4. Вага не експортується в BigQuery.

У 2026 році GA4 дозволяє налаштовувати модель атрибуції та вікно ретроспективного огляду окремо для кожної ключової події. Раніше єдині налаштування застосовувалися для всього ресурсу (property): підписка на розсилку і покупка на $10 000 оцінювались однаково.

Практично це означає: для покупки можна задати data-driven з довгим вікном, для підписки — last click з коротким. Зробити налаштування можна у розділі Advertising → Conversion Management, окремо для кожної property.

Алгоритмічні підходи на власних даних

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

Ланцюги Маркова рахують removal effect — наскільки впаде загальна конверсія, якщо повністю прибрати канал зі шляхів. Вектор Шеплі — метод з теорії ігор, що справедливо ділить «виграш» між учасниками коаліції; саме на ньому базується DDA Google.

Обидва реалізуються на даних GA4 у BigQuery за допомогою SQL + Python і, на відміну від DDA, це не чорна скринька: ви контролюєте логіку і можете її пояснити.

Окремий випадок: продажі повз сайт

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

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

Робоча конструкція в таких випадках гібридна: 

• базою слугує Last Click на сирих даних GA4;

• замовлення, які вдалося зв'язати із сесією, отримують джерело з GA4;

• незв'язані угоди беруть джерело безпосередньо з CRM;

• для пріоритетних каналів (наприклад, маркетплейсів) CRM-дані перебивають GA4 навіть тоді, коли сесію на сайті було знайдено.

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

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

Висновок

Модель атрибуції — не пошук істини, а вибір лінзи під конкретне бізнес-питання. Але в наскрізній аналітиці вибір моделі — це остання миля, а не перша. Спершу треба відповісти на базові питання: 

• який відсоток угод у CRM має валідне джерело;

• як коректно враховувати телефонні дзвінки;

• наскільки consent на сайті розмиває дані;

• і чи розумієте ви, чому цифри в інтерфейсі не сходяться з розрахунком в BigQuery.

І наостанок: атрибуція — не єдиний спосіб оцінювати ефективність маркетингу. Через деградацію cookie-based трекінгу (обмеження ITP, consent mode, блокувальники реклами) великі бренди все частіше доповнюють її інструментами Marketing Mix Modeling та інкрементальними тестами — підходами, що не залежать від відстеження окремих користувачів. Але це тема окремої статті.