NetHunt Кейс

NetHunt CRM — CRM-система для управління продажами та взаємодією з клієнтами. Вона об'єднує всі процеси продажу: від збору заявок і спілкування з лідами до ведення угод, автоматизації роботи команди та аналізу результатів. Компанії з понад 70 країн використовують NetHunt, щоб тримати клієнтів, угоди й комунікацію в одному місці.

Серед клієнтів NetHunt CRM — RozetkaPay, LOKO, uklon, mono, LIKI24, КВЦ «Парковий», Karpatia, Superhumans, Zakaz.ua, Helsi. У NetHunt є окремі локалізовані сайти для кількох ринків.

Клієнт NetHunt CRM — це не окрема людина, а компанія: вона створює спільний робочий простір (workspace) для команди і платить за кожного користувача в ньому. Тому вся аналітика далі рахується на рівні workspace.

Коли ми почали працювати з NetHunt, у компанії було багато налаштувань, зокрема серверний GTM, відстеження великої кількості подій в GA4 та передача продуктових подій з бекенду напряму в GA4 через Measurement Protocol. Дані зберігались в декількох різних системах і зводились руками. Додатково було налаштоване збереження UTM-міток з першого входу на сайт.

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

У результаті аудиту було виявлено, що аналітика на сайті збирала трафік із прогалинами. Значна кількість браузерних подій відстежувалася некоректно. Траплялися дублікати подій, які мали різні назви, а також загальна неконсистентність, яка не дозволяла легко орієнтуватися у великій кількості розрізнених подій. Найбільше уваги потребували події з бекенду. GA4 по-особливому атрибутує дані, що надходять через Measurement Protocol, і без коректних ідентифікаторів сесії всі серверні події потрапляли в канал трафіку Unassigned, тож їх не можна було використати для аналізу джерел.

Окрім того, для кожного користувача зберігалася UTM-розмітка першого входу на сайт. Проте втрачались реферальні та органічні канали, а аналіз був можливий лише за першим дотиком. Це суттєво обмежувало можливості аналізу маркетингових кампаній для B2B-бізнесу, оскільки користувачі такого типу бізнесу часто проходять довгий шлях і можуть взаємодіяти з компанією через кілька каналів, перш ніж стати його клієнтами.

І на завершення. Суттєвою бізнес-проблемою було те, що сторонні системи не могли адаптуватися до особливостей бізнесу й аналізувати дані на рівні workspace — головної одиниці для NetHunt, оскільки її клієнт створює робочий простір не тільки для себе, а й для своєї команди. У цьому випадку часто траплялося так, що у одного workspace могло бути декілька customer-профілів — основний рівень у Stripe. Наприклад, коли один такий customer йшов із workspace, то Stripe показував churn, хоча насправді це downgrade. У свою чергу, якщо у workspace додавався новий користувач, то для Stripe це був новий customer і новий MRR, хоча насправді для бізнесу це upgrade.

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

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

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

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

На основі цього підходу й зібраних даних ми згодом побудували звіт для аналізу відповідей під час онбордингу.

Наразі схема збору даних має такий вигляд:

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

Далі ми налаштували зв'язок між подіями з сайту та з бекенду. Під час реєстрації та логіну серверний GTM зберігає технічні ідентифікатори, за якими GA4 розпізнає користувача та його сесію. Завдяки цьому розробникам не довелося нічого додатково збирати в браузері чи перевіряти перед кожною відправкою події. Це важливо, адже якщо при серверному відстеженні передати ідентифікатор, якого GA4 не знає, в аналітиці з'являться два різні, ніяк не пов'язані між собою користувачі.

З боку бекенду розробники передають лише мінімально потрібний набір даних: user_id і параметри з бази, наприклад суму оплати чи план підписки. Подія надходить не одразу в GA4, а на серверний GTM. Він доповнює її потрібними ідентифікаторами сесії й уже тоді надсилає в GA4 через Measurement Protocol. Завдяки цьому GA4 може атрибутувати серверні події до сесії, а отже, і до джерела трафіку, тож їх нарешті стало можливо аналізувати в інтерфейсі.

Важливим виправленням у логіці передачі даних стала також зміна значення зарезервованого параметра user_id: у це поле ми передали workspace ID, щоб GA4 рахувала дані на рівні робочого простору — головної одиниці для NetHunt.

Цей пункт також належить до збору даних, проте відбувається незалежно від третіх систем на кшталт GA4. Ми розробили власне рішення, яке допомагає визначити джерело трафіку, зокрема з першого дотику та останнього непрямого входу. Це рішення визначає джерело так, як це робить GA4. Зокрема, опрацьовує не тільки UTM-розмітку, а й органічні та реферальні джерела трафіку.

Внаслідок реалізації в CRM-системі клієнта з’явилися повноцінні дані про те, звідки користувач знайомиться із сайтом, а яке джерело стає вирішальною ланкою перед прийняттям рішення про реєстрацію в продукті.

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

Паралельно з виправленням збору даних ми почали процес завантаження даних з усіх потрібних систем та їх автоматичного оновлення у BigQuery (хмарне сховище в Google Cloud).

Ми налаштували рідний експорт із GA4, Data Transfer із кастомними запитами із Google Ads, а також через функції в Cloud Run вивантажили дані з Facebook Ads, дані платіжного сервісу Stripe, а також курси валют, оскільки в різних системах дані зберігалися в різних валютах. На додачу варто пам’ятати, що NetHunt — це міжнародна компанія, і вона сама приймає платежі в різних валютах. Для того, щоб аналізувати дані, ми зводили всі платежі до спільної валюти за курсом на конкретний день.

Під час обробки і моделювання даних для майбутніх звітів ми вирішили одну з основних бізнесових проблем — об’єднання всієї логіки розрахунків та атрибуції навколо сутності workspace. І в результаті ми підготували все для того, щоб бізнес побачив свою ефективність на правильному рівні, та побудували 3 звіти:

• Revenue Report — MRR і рух клієнтів за типами, плюс очікувані надходження;
• End-to-End Funnel — воронка від візиту до підписки з розрізом за відповідями опитування з онбордингу;
• Marketing Attribution — внесок каналів і кампаній у реєстрації й оплати за трьома моделями атрибуції.

Як ми вже згадували, платежі та підписки NetHunt керуються через Stripe, але Stripe рахує метрики на рівні customer-профілю. Робочого простору (workspace) як окремої одиниці в Stripe немає, тому навіть схожий розподіл за типами клієнтів в його інтерфейсі не підходив для аналізу на рівні workspace.

Основний розрахунок в звіті – це MRR (monthly recurring revenue). Тобто сума коштів, яку клієнт сплачує за місяць користування продуктом. Для місячної підписки MRR дорівнює сумі оплаченого інвойса за місяць користування. Для річної – розрахунок відбувається так: сума оплати інвойса ділиться на 12, і в кожному з подальших місяців відображається сума за місячний період користування. Таким чином, якщо підписка на рік коштує 1200, із моменту оплати у звіті відображається 100 навпроти кожного з подальших 12 місяців. На основі суми MRR ми визначаємо тип workspace.

Правила розподілу на типи наступні:

• Customers або MRR – загальна кількість робочих просторів або MRR у відповідний місяць;
• New – кількість просторів, які зробили свою першу в житті оплату, і, відповідно, їхній MRR;
• Existing – існуючі робочі простори, чий MRR поточного місяця був таким самим, як MRR попереднього місяця;
• Upgrade – workspace-и, які підвищили тариф та/або додали нових користувачів, і таким чином поточний MRR став більшим за минулий місяць. Upgrade ∆ — відповідно, сума, на яку виріс MRR поточного місяця;
• Downgrade – те саме, що й Upgrade, але у зворотному напрямку. Це ті робочі простори, які зменшили кількість користувачів та/або перейшли на дешевший план;
• Churn – клієнти NetHunt, які перестали користуватися продуктом, і, відповідно, їхній минуломісячний MRR, який втратила компанія через втрату клієнта;
• Reactivation – клієнти компанії, які повернулися після того, як перестали користуватися продуктом, та їхній MRR в місяці повернення;
• Growth – розраховується за формулою New + Reactivation + Upgrade ∆ - Downgrade ∆ - Churn. Відображає кількість робочих просторів або суму MRR, на яку бізнес виріс або яку втратив.

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

Над основною таблицею наявні всі фільтри, які дозволяють сегментувати аудиторію за різними параметрами. Водночас зліва, у блоці Dimensions, користувач звіту може швидко обрати потрібні розбивки в потрібній послідовності, клікаючи по черзі на виміри. І в результаті заглибитись не тільки до рівня плану або регіону, а й до конкретного робочого простору. Це особливо цінно для команди Customer Success, яка може швидко зв’язатися з клієнтом, у якого є зміни в підписці.

Графік під основною таблицею за декілька секунд дозволяє зрозуміти, куди рухається компанія. Лінія MRR Growth над 0 – хороший сигнал: компанія отримує більше, ніж втрачає.

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

Revenue Report показує дані за робочими просторами, які уже платять, і відображає, як змінюється їхній MRR з часом. Це звіт про поточних клієнтів продукту, і він за своєю побудовою не може відповісти на питання: скільки людей могли стати клієнтами, але чомусь на якомусь кроці до підписки вони зупинилися і залишили сайт?

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

Воронка має п'ять кроків:

1. перегляд сторінки;
2. клік з наміром — реєстрація, заявка на демо або інші кнопки заклику до дії;
3. початок реєстрації;
4. створення workspace;
5. перша підписка.

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

Під час онбордингу потенційний клієнт NetHunt відповідає на такі запитання:

• чим планує керувати в CRM — відповіді відображаються в блоці What Manage;
• які інтеграції йому потрібні — обрані варіанти йдуть в Integrations;
• звідки він дізнався про продукт — аналізувати відповіді можна в розділі How Found;
• які вимоги до CRM для нього головні — інформація про відповіді на це питання, відповідно, відображається в CRM Requirements.

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

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

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

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

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

Звіт Marketing Attribution відповідає на низку питань та реалізує індивідуальну логіку обробки. Зокрема, звіт відображає декілька конверсій з різних етапів: ліди від тих, хто заповнив форму для демо, трайли від тих, хто почав користуватись продуктом, а також ті, хто вперше оплатив, і їхній MRR. Останні два показники збігаються із New customers та MRR із Revenue Report.

Перший екран звіту надає велику таблицю для дослідження даних і може відображати розрахунки в трьох моделях атрибуції:

• First — уся заслуга першому дотику;
• Last non-direct — вся заслуга останньому дотику, який не є прямим заходом;
• Linear — заслуга порівну між усіма дотиками на шляху.

Якщо канал сильний за першим дотиком і слабкий за останнім, він відкриває шляхи, які закривають інші. Якщо навпаки – він збирає попит, створений раніше.

Також прямо у звіті у два кліки можна змінити вікно атрибуції, тобто за який період до конверсії брати джерела і розподіляти між ними цінність – 30, 60 чи 90.

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

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

В кінці сторінки зображені повні ланцюжки до конверсії, яку користувач звіту обирав на попередньому віжуалі. І тут можна додатково дослідити те, як канали працюють у парі. Наприклад, на скріншоті нижче видно, що paid search часто йде в парі з органікою та із самим собою. Тобто з реклами люди роблять декілька дотиків і частіше, ніж з інших каналів трафіку.

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

Пройшовши з нами цей шлях, у NetHunt тепер є можливість:

• аналізувати метрики на рівні своєї власної одиниці — робочого простору — й не залежати від особливостей розрахунків сторонніх систем. Їхня аналітика кастомізована під власні потреби;
• бачити реальний MRR та правильне розподілення за типами. Якщо користувач залишає свій workspace, це більше не виглядає як churn, а правильно відображається як downgrade;
• планувати наперед, бо очікувані надходження й поновлення видно завчасно;
• сегментувати користувачів за потребами з опитування з онбордингу та аналізувати потреби своїх потенційних клієнтів;
• бачити, які кампанії відкривають шлях до конверсії, навіть якщо реєстрацію потім закриває брендовий пошук. Три моделі атрибуції, перемикання вікна атрибуції, шляхи до конверсії й вартість залучення платного workspace зібрані в одному звіті.

Співпраця з NetHunt триває з 2025 року. Зараз ми разом із клієнтом працюємо над уніфікованою моделлю цін для розрахунку MRR. Поки MRR рахується з фактично сплачених сум, переведених в одну валюту, коливання курсу може дати «зниження тарифу» в доларах там, де тариф не змінювався. Уніфікована модель прив'яже MRR до тарифу, а не до курсу.

• Аудит GA4 – пошук прогалин у зборі даних.
• Збереження джерел трафіку – власне рішення Proanalytics.Team.
• Налаштування GTM за технічним завданням – виправлення збору даних.
• Налаштування серверного GTM – виправлення помилок налаштування серверного контейнера.
• Передача подій через Measurement Protocol – продуктові події з бекенду NetHunt через серверний GTM у GA4.
• Експорт GA4 у BigQuery і вивантаження даних зі Stripe у BigQuery – єдине сховище.
• Наскрізна аналітика (звіт) – воронка від візиту до підписки.
• Звіт по моделях атрибуції – Marketing Attribution.
• Кастомний звіт – Revenue Report.