Атрибуція в маркетингу: моделі, пастки і як рахувати чесно

Якщо скласти конверсії з кабінету Google Ads, кабінету Meta і з GA4, сума майже завжди буде більшою за реальну кількість замовлень у CRM. Ніхто не бреше — кожна система просто зараховує собі продаж за власними правилами. Атрибуція — це і є ці правила.

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

#Що таке атрибуція

Атрибуція — спосіб розподілити заслугу за конверсію між точками контакту. Клієнт міг побачити рекламу в Instagram, через тиждень знайти вас у Google, а купити після email-розсилки. Хто «привів» клієнта? Відповідь залежить від моделі.

#Основні моделі

У GA4 за замовчуванням використовується data-driven атрибуція для звітів про атрибуцію; правила й доступні моделі описані в довідці Google. Важливо знати, що Google з часом прибрав частину евристичних моделей, тому порівнюючи старі звіти з новими, ви можете дивитися на різні правила.

#Чому кабінети показують різне

Причин кілька, і вони складаються:

1. Різні моделі. Google Ads і Meta зараховують конверсію собі, якщо був клік або (у Meta) перегляд у межах вікна.
2. Різні вікна атрибуції. Наприклад, 7 днів після кліку і 1 день після перегляду проти 30 днів у іншій системі.
3. Дата конверсії. Кабінети часто записують конверсію на дату кліку, а CRM — на дату оплати.
4. Моделювання. Через consent mode і обмеження трекінгу частину конверсій системи моделюють (про consent mode).
5. Перегляди без кліку. Meta зараховує view-through конверсії, GA4 — ні.

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

#Як я будую власну атрибуцію

#Крок 1. Одна точка правди про продажі

Замовлення і виручку беремо з CRM або бекенду магазину, а не з GA4. Кожне замовлення має ID, дату, суму, статус (оплачено/повернено).

#Крок 2. Зв'язати замовлення з візитом

Найнадійніше — передавати transaction_id у подію purchase GA4 і зберігати UTM та gclid/fbclid у CRM разом із лідом. Тоді в BigQuery можна з'єднати замовлення з сесіями (експорт GA4 у BigQuery).

#Крок 3. Нормалізувати джерела

Без дисципліни UTM-міток атрибуція неможлива: facebook, fb, Facebook, meta — це чотири канали замість одного. Правила — у статті про UTM-мітки.

#Крок 4. Порахувати кілька моделей поруч

Я майже завжди показую дві-три моделі в одній таблиці. Розбіжність між ними сама по собі інформативна.

Цифри умовні. Тут видно класичну картину: Meta приводить нових людей, а пошук і email їх «закривають». Вимкнувши Meta через низький last-click ROAS, ви згодом побачите падіння і пошуку.

#Крок 5. Перевіряти експериментами

Жодна модель не доводить причинність. Для великих рішень — інкрементальні тести: вимкнути канал у частині регіонів, порівняти з контролем; або geo-lift / conversion-lift тести, які пропонують самі рекламні платформи.

#Атрибуція в мобільних застосунках

Для застосунків джерело встановлення визначає MMP — наприклад, AppsFlyer. Там свої вікна, свої правила для iOS після ATT і SKAdNetwork. Як звести це з виручкою і поведінкою — у статті про атрибуцію AppsFlyer.

#Як показувати атрибуцію в дашборді

• Один екран «Канали»: витрати, замовлення й виручка з CRM за обраною моделлю, ROAS/CAC.
• Перемикач моделі — last click / first click / лінійна.
• Окремий рядок «Без джерела» — не ховайте його; його частка є метрикою якості трекінгу.
• Примітка про вікно атрибуції біля таблиці.
• Тренд за 8–12 тижнів, а не за 3 дні — атрибуція шумна на коротких відрізках.

Як зібрати витрати Google Ads і Meta в одну таблицю — у статті про зведений рекламний звіт. А як від ROAS перейти до прибутку — у статті ROAS і POAS.

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

• Складати конверсії з різних кабінетів і порівнювати з CRM.
• Оцінювати канали верхньої воронки за last click.
• Ігнорувати повернення і скасовані замовлення.
• Міняти модель атрибуції і не позначати, з якої дати.
• Робити висновки за тиждень даних.

#Чекліст

• Продажі беруться з CRM/бекенду, а не з рекламних кабінетів
• transaction_id однаковий у GA4 і CRM
• UTM і click ID зберігаються з лідом
• Є словник каналів і правила нормалізації
• У звіті 2+ моделі атрибуції поруч
• Частка «без джерела» відстежується
• Великі бюджетні рішення перевіряються тестом

#Приклад: ті самі продажі — три відповіді

Щоб побачити, чому вибір моделі важить, візьмемо п'ять ілюстративних шляхів клієнтів, кожен закінчився замовленням на 1 000 грн:

Кредит каналам за трьома моделями (прямі заходи пропускаються, як у моделі last non-direct click):

(У лінійній моделі 1 000 кожного замовлення ділиться порівну між непрямими дотиками: по 500 для A, B і D, по 333 для трьох дотиків E. Числа округлені.)

За останнім кліком Meta виглядає марною, а email — зіркою. За першим кліком Meta принесла більшість виручки. Жодна відповідь не «правдива». Брендовий пошук і email здебільшого збирають попит, який створило щось інше. Практичні висновки:

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

#SQL: остання непряма взаємодія на власних даних

Якщо є сесії з джерелом і ID клієнта чи користувача (наприклад, з експорту GA4 у BigQuery, з'єднаного із замовленнями), остання непряма взаємодія рахується віконною функцією:

WITH touches AS (
  SELECT o.order_id, o.revenue, s.channel, s.session_start,
         ROW_NUMBER() OVER (PARTITION BY o.order_id ORDER BY s.session_start DESC) AS rn
  FROM orders o
  JOIN sessions s
    ON s.user_id = o.user_id
   AND s.session_start <= o.created_at
   AND s.session_start >= TIMESTAMP_SUB(o.created_at, INTERVAL 30 DAY)
  WHERE s.channel <> 'direct'
)
SELECT channel, COUNT(*) AS orders, SUM(revenue) AS revenue
FROM touches
WHERE rn = 1
GROUP BY channel
ORDER BY revenue DESC;

Замініть DESC на ASC у вікні — отримаєте перший клік. Замовлення, що мали лише прямі сесії, з цього запиту випадають: поверніть їх як «direct» через LEFT JOIN, інакше підсумок не збіжиться з виручкою. Вікно у 30 днів — це ваш вибір; запишіть його у визначення метрик.

#Тестувати інкрементальність замість суперечок про моделі

Будь-яка модель лише ділить заслугу. Жодна не відповідає на «що ми втратимо, якщо це вимкнути?». Для цього потрібен експеримент. Три підходи, які реально провести невеликій команді:

1. Гео-контроль. Призупиніть канал в одному чи кількох регіонах на 3–4 тижні і порівняйте динаміку з подібними регіонами, де він працював. Найкраще працює, якщо ви продаєте в багатьох схожих регіонах.
2. Lift-дослідження платформ. Meta і Google мають тести conversion lift, що випадково приховують рекламу від контрольної групи (доступність залежить від бюджету й налаштувань акаунта). Результат стосується лише цієї платформи, але метод коректний.
3. Періоди «увімкнено/вимкнено». Найгрубіший варіант: вимкнути канал на кілька тижнів і дивитися на загальну кількість нових клієнтів і виручку, а не на конверсії з кабінету. Шумно, залежить від сезонності — довіряйте лише великим ефектам.

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

#Вибір підходу за етапом бізнесу

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

#Вікна атрибуції: налаштування, яке ніхто не записує

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

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

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

#Як часто дивитися

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

#Часті запитання

#Яка модель атрибуції найкраща?

Універсальної немає. Для щоденної оптимізації зручна last click або data-driven з кабінетів; для розподілу бюджету між каналами краще дивитися кілька моделей поруч і перевіряти висновки тестами.

#Чому в Meta конверсій більше, ніж у GA4?

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

#Чи потрібен BigQuery для атрибуції?

Для простих звітів — ні. Для власної моделі, яка з'єднує замовлення з CRM і сесії GA4, BigQuery або інше сховище майже обов'язкове.

#Що робити з трафіком «без джерела»?

Спершу зменшити: перевірити UTM, редіректи, які обрізають параметри, оплату через сторонні сторінки (LiqPay, monobank), що підмінює реферер. Решту показувати окремим рядком.