Аналітика без ілюзій: які події треба відстежувати, щоб розуміти, звідки приходять гроші
У більшості звітів, які ми бачимо на першій зустрічі, все виглядає добре: трафік росте, покази множаться, час на сторінці пристойний. А потім власник каже фразу, після якої розмова стає чесною: «Дані гарні, але грошей більше не стало».
Це не проблема аналітики як інструменту. Це проблема набору подій, який зібрали за принципом «щоб було»: підключили лічильник, поставили ціль на відправку форми, решту лишили на автозбір. Такий набір непогано описує поведінку відвідувачів – і майже нічого не каже про те, звідки приходять гроші.
Чому дашборд росте, а каса – ні
Метрики на кшталт сеансів, показів і глибини перегляду легко ростуть без жодного впливу на виторг. Реферальний спам, зміна алгоритму видачі, вдалий пост у соцмережах, банальний перезапуск реклами на широку аудиторію – усе це підіймає графік.
Небезпека не в тому, що ці цифри марні. Небезпека в тому, що на них починають ухвалювати рішення: масштабувати канал, який дає багато візитів і нуль угод, або різати той, що дає п’ять заявок на місяць – але всі п’ять закриваються з середнім чеком у півтора рази вищим за решту.
Класичний випадок із практики: клієнт два квартали нарощував бюджет на канал, який давав 60% усього трафіку. Коли нарешті під’єднали статуси з CRM, виявилося, що цей канал дає 8% виторгу. Гроші приносив вузький сегмент, на який припадало 4% візитів.
Рахуйте назад: від грошей до події
Робочий спосіб зібрати аналітику – почати не з інструментів, а з питання «на чому саме ми заробляємо». Далі рухайтесь назад ланцюжком: яка дія клієнта передує оплаті, яка передує їй, і так до першого дотику.
Для послуг ланцюжок зазвичай виглядає так:
оплата → рахунок → зустріч → кваліфікована заявка → заявка → перегляд кейсу або сторінки послуги → перший візит
Кожен перехід у цьому ланцюжку – кандидат на подію. Усе, що в ланцюжок не потрапило, у трекінг не йде. Це головний фільтр, який рятує від сотні непотрібних подій і від контейнера, у якому через півроку ніхто не розбирається.
Мінімальний набір, який закриває 90% питань
Для більшості сайтів послуг і B2B вистачає семи подій. Не сімдесяти.
| Подія | На яке питання відповідає | Коли спрацьовує |
|---|---|---|
form_start | Форму взагалі починають заповнювати? | Фокус у першому полі |
generate_lead | Скільки заявок і з якого джерела | Успішна відправка форми |
contact_click | Скільки звернень повз форму | Клік по телефону, пошті, Telegram |
key_page_view | Які послуги реально цікавлять | Перегляд сторінки послуги або кейсу |
content_engaged | Контент читають чи закривають | 60% прокрутки + 30 секунд |
file_download | Хто на стадії вибору | Завантаження прайсу, презентації |
qualified_lead | Скільки заявок були справжніми | Зміна статусу в CRM |
Остання подія – найважливіша і найчастіше відсутня. Без неї ви оптимізуєте рекламу під кількість заявок, а не під гроші. Різниця між цими двома стратегіями зазвичай вимірюється десятками відсотків бюджету.
Три атрибути, без яких подія марна
Сам факт «була заявка» майже нічого не дає. Подія починає працювати, коли несе з собою три речі.
Джерело
UTM-мітки, реферер, назва кампанії – зафіксовані в момент першого візиту й збережені до конверсії. Якщо джерело зчитується в момент відправки форми, ви побачите «прямий трафік» там, де насправді була реклама: людина прийшла з оголошення, подумала три дні, повернулася за назвою бренду й залишила заявку. Формально це прямий захід. Фактично гроші заробила реклама.
Ідентифікатор
Наскрізний ID, який однаково розуміють сайт, аналітика й CRM. Це той місток, яким дані про закриту угоду повертаються назад до каналу, що її привів. Без нього аналітика й CRM живуть у паралельних всесвітах і не сходяться за жодним показником.
Цінність
Хоча б приблизна. Заявка на підтримку сайту й заявка на розробку з нуля – це не одна й та сама подія, і зводити їх в одну цифру означає свідомо псувати собі статистику. Якщо точну суму на момент заявки невідомо, підставляйте середній чек по категорії послуги – це вже на порядок краще, ніж одиниця для всього.
Приклад на цифрах
Три канали, однаковий місяць, однаковий бюджет по 30 000 грн. Ось як виглядає картина у двох різних системах координат.
| Канал | Заявок | Ціна заявки | Закритих угод | Виторг | Ціна угоди |
|---|---|---|---|---|---|
| Канал A | 60 | 500 грн | 3 | 90 000 грн | 10 000 грн |
| Канал B | 20 | 1 500 грн | 8 | 320 000 грн | 3 750 грн |
| Канал C | 35 | 857 грн | 2 | 48 000 грн | 15 000 грн |
Якщо дивитися на перші три колонки, найкращий канал – A, найгірший – B. Якщо дивитися на останні три, усе рівно навпаки. Перші три колонки бачить аналітика без офлайн-конверсій. Останні три – аналітика, доведена до кінця. Рішення, ухвалені за лівою половиною таблиці, тут коштували б бізнесу основного джерела виторгу.
Офлайн-конверсії: там, де ховаються справжні гроші
Онлайн-аналітика бачить сайт і зупиняється на заявці. Усе цікаве відбувається далі: дзвінок, кваліфікація, оцінка, торг, договір, оплата. Поки ці статуси не повертаються з CRM назад в аналітику, будь-який висновок про «найкращий канал» – здогадка.
Технічно це простіше, ніж здається: до заявки додається ідентифікатор, CRM віддає його разом зі статусом і сумою, дані вивантажуються в аналітику за розкладом. Після цього звіт нарешті відповідає не на питання «звідки трафік», а на питання «звідки гроші».
Атрибуція: чому «останній клік» майже завжди бреше
За замовчуванням більшість систем віддає всю заслугу останньому джерелу перед конверсією. У короткому циклі це прийнятно. У продажу послуг із циклом у два-три тижні й п’ятьма-сімома дотиками – це системна помилка, яка щоразу знецінює канали на верхніх етапах: контент, органіку, медійку.
Не обов’язково одразу будувати складні моделі. Достатньо дивитися на конверсії за першим дотиком паралельно з останнім. Якщо канал майже не з’являється в «останньому кліку», але регулярно є в «першому» – ви знайшли те, що вимикати не можна, хоч звіт і каже протилежне.
П’ять помилок, які трапляються найчастіше
- Подія на кожен клік. Двісті подій у контейнері – це не аналітика, а шум, у якому ніхто не розбирається на другий місяць.
- Немає єдиного словника назв.
Заявка,lead,form-2іForm Submitв одному проєкті – і зведення вже неможливе. - Дублі з GTM і коду. Одна подія, повішена двічі, тихо подвоює конверсії й ламає всі розрахунки вартості.
- Ігнорування згоди на куки. Без коректного режиму згоди частина даних просто не збереться, а частина зібраного стане юридичною проблемою.
- Ціль на сторінку «дякуємо». Її можна відкрити напряму, перезавантажити, зберегти в закладки. Це не конверсія, це URL.
Як перевірити, що у вас усе гаразд
Три питання, які варто поставити собі або підряднику:
- Чи можете ви назвати вартість закритої угоди по кожному каналу – не вартість заявки?
- Чи збігається кількість заявок в аналітиці з кількістю в CRM за той самий період? Розбіжність до 5% нормальна, 30% означає, що одна із систем бреше.
- Чи зрозуміє новий співробітник призначення кожної події за її назвою, без пояснень?
Якщо на всі три відповідь «так» – аналітика працює. Якщо хоча б на одне «ні», справа майже завжди не в інструменті, а в тому, що набір подій ніхто не проєктував від грошей.
З чого почати
Не з переналаштування всього. Візьміть один ланцюжок – від найприбутковішої послуги до оплати – і доведіть його до кінця: подія, джерело, ідентифікатор, статус із CRM. Один повний ланцюжок дає більше, ніж двадцять подій, кожна з яких обривається на середині.
Коли він запрацює, ви отримаєте не красивіший звіт, а іншу якість рішень: стане видно, який канал годувати, який лікувати, а який закрити – і це буде видно з цифр, а не з відчуттів.
