Зміст матеріалу
Що важливо зрозуміти
Для зв’язку реклами з оплатою потрібен сталий ідентифікатор звернення, перенесений у CRM та рахунок. Джерело зберігають при вході, а втрату атрибуції показують окремо.
Створити послідовний зв’язок між різними подіями
Рекламний клік, заявка, угода й платіж можуть зберігатися в різних системах. Щоб оцінити результат, потрібен відтворюваний зв’язок між ними. Починають із унікального ідентифікатора звернення та правила, як воно переходить у замовлення, не втрачаючи історію джерела.
Одне замовлення може мати кілька платежів, а один клієнт — кілька звернень. Тому простий підрахунок усіх записів завищує кількість продажів. Окремо визначають, як обліковуються повторні покупки, повернення та випадки, коли початкове джерело невідоме.
Зібрати мінімальний ланцюжок для звірки
- Ідентифікатор заявки, дату й збережене джерело звернення.
- Ідентифікатор угоди, зв’язок із заявкою, клієнтом і погодженою сумою.
- Платежі, часткові оплати, повернення та їхнє віднесення до замовлення.
- Правило атрибуції, невідомі джерела й повторні контакти різними каналами.
Перевірити на своїх даних
- Калькулятор вартості залучення клієнтаЗіставте повні витрати залучення з новими клієнтами.
- Калькулятор окупності маркетингуЗіставте внесок продажів із витратами маркетингу.
- Шаблон аналізу рекламних каналівЗведіть витрати, звернення та результати каналів.
Часткові оплати не є окремими продажами
| Умовний запис | Подія | Сума, грн |
|---|---|---|
| Заявка L-1 | Звернення з реклами | — |
| Угода O-1 | Погоджене замовлення | 20 000 |
| Платіж P-1 | Перша оплата O-1 | 12 000 |
| Платіж P-2 | Залишок O-1 | 8 000 |
Маємо одну угоду, два платежі та 20 тис. грн надходжень. Якщо система передає дві покупки по 20 тис. грн, рекламний дохід буде завищений удвічі. Подію заявки також не можна називати оплатою.
Перевірити кілька операцій від початку до банку
Вибирають замовлення з різними сценаріями: повна оплата, частини, повернення та повторний покупець. Для кожного відновлюють джерело й суми. Помилки виправляють у правилах зв’язку, а не ручним коригуванням лише підсумкового звіту.
У Google Analytics рекомендовані події для звернення та покупки мають різний зміст; налаштування звіряють з офіційною документацією. Внутрішні ідентифікатори не повинні містити контактні дані клієнта. Для управлінського звіту персональні поля залишають у призначеній для цього системі з належним доступом.
Не вважати останній канал єдиною причиною покупки
Клієнт міг спочатку побачити рекламу, потім прочитати статтю й повернутися напряму. Атрибуція розподіляє записаний результат за правилом, але не доводить причинний приріст. Обране правило та його обмеження мають бути видимими.
Отримати звіт, який сходиться з реальними оплатами
Результат — пов’язаний реєстр заявок, угод і платежів із невідомими джерелами та поверненнями. Суми звіряються з фактом, а кількість угод не дублюється. На такій основі можна оцінювати внесок каналів і змінювати бюджет без хибних конверсій.