КЕЙС: Наскрізна аналітика агенції — від візиту на сайт до угоди в CRM

Клієнт — агенція, яка продає складну B2B-послугу з довгим циклом: від першого дотику до підписаного контракту минають тижні, а частіше місяці. Заявки приходять із десятка джерел: галузеві каталоги, органічний пошук, соцмережі, майданчики з портфоліо, статті — і дедалі частіше AI-асистенти. Команда бачила трафік у Google Analytics і угоди в CRM — лишалось з’єднати ці два світи в одну картину, щоб на головне питання бізнесу — який канал приводить не відвідувачів, а клієнтів — відповідали дані, а не здогадки.

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

Кейс публікуємо у вайтлейбл-форматі, за домовленістю з клієнтом: без назви компанії та без її показників. На знімках приховано айдентику, числа розмито, назви стадій CRM узагальнено — на будову інструменту це не впливає, а саме вона тут і цікава.

Технології проєкту

• Збір даних: Google Analytics 4 — події, Data API для історії, Admin API; Google Tag Manager — теги, тригери, куки першої сторони, API публікації; Google Search Console — масове вивантаження (bulk export)
• Сховище й обробка: Google BigQuery у хмарі клієнта, локація EU; Два шари даних: core (нормалізовані події й сесії) → marts (вітрини); Standard SQL, зшивка історії з живим потоком по контрольній даті
• CRM: Pipedrive API — службові поля угоди, стадії, історія переходів
• Дашборд: Самодостатній HTML / CSS / JavaScript — без конструкторів і ліцензій; SVG-графіки, перерахунок періодів і порівняння прямо в браузері; Айдентика клієнта: її шрифт і кольори
• Сайт клієнта: Сучасний JS-фреймворк — інтеграція через dataLayer і куки першої сторони
• Інфраструктура: Python — завантаження даних, збірка дашборда й документів; Git — версії коду й документів; Щоденна автоматизація: перезбірка, контрольні суми, свіжість даних, цілісність стику

1. Вступна частина

1.1. Про клієнта і задачу

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

Набір інструментів у клієнта вже був: GA4 і Google Tag Manager на сайті, Search Console, CRM із власною воронкою продажів. Кожен добре відповідав на своє питання — лишалось навчити їх відповідати на спільне: з’єднати трафік з угодами, а угоди — з джерелами.

Задачу сформулювали двома питаннями:

• Який канал приводить клієнтів, а не просто сесії?
• На якому кроці форми люди зупиняються — і що з цим можна зробити?

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

1.2. Особливості проєкту

П’ять систем, які треба звести в одну картину. GA4, GTM, Search Console, CRM і сам сайт. Дані треба було не «підключити», а привести до спільного знаменника: одна людина — один ідентифікатор наскрізь.

Історія глибша, ніж показує інтерфейс GA4. Для порівняння року з роком і чесної оцінки сезонності потрібні роки, а не місяці. Тому історію забирали окремо через API і зшивали з живим потоком.

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

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

Сайт багатосторінковий, форма двокрокова, і форм кілька. Кнопка в хедері, модальне вікно, вбудована форма на сторінці контактів. Форми малюються на льоту і мають два кроки, тому події треба відправляти з коду сайту, а не вгадувати за кліками. Отже розробник клієнта — повноправний учасник проєкту.

2. Робота над проєктом

2.1. Фундамент: усі дані в одному місці

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

Далі — сховище. Розгорнули проєкт BigQuery в хмарі клієнта, увімкнули щоденне вивантаження GA4 і масове вивантаження Search Console. Поверх сирих даних побудували два шари: core — нормалізовані події й сесії, і marts — вітрини, тобто готові до показу зрізи даних. Кожна цифра на дашборді має свій запит, і його можна перевірити.

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

2.2. Історія, глибша за вивантаження

Вивантаження в BigQuery починається з дня, коли його увімкнули. Все, що було раніше, в експорт не потрапляє. А клієнту потрібна історія з дня запуску сайту.

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

2.3. Форма: події й воронка

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

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

Окрема робота — лишити в даних тільки справжніх відвідувачів: без тестових середовищ, без наших власних перевірок, без службових переходів команди. Так воронка показує реальну картину, а не приємнішу за неї.

2.4. Стик із CRM: одна людина — один ідентифікатор

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

Як це влаштовано:

• Тег у GTM при першому візиті записує ідентифікатор GA4 і мітки кампанії в куки першої сторони — саме першого дотику, а не останнього: нам важливо, що людину привело, а не через що вона повернулась.
• Форма на сайті читає ці куки й передає разом із заявкою.
• Бекенд клієнта створює угоду в CRM і заповнює сім службових полів: ідентифікатор візиту, джерело, тип трафіку, кампанію, сторінку заявки, ідентифікатор рекламного кліку та форми. Поля ми спроєктували і створили через API, розробнику передали технічне завдання з прикладами.
• BigQuery з’єднує угоду з візитами по ідентифікатору. З цього моменту в кожної угоди є канал, джерело і перша сторінка входу.

Перевіряли не на словах. Спершу надіслали контрольні заявки через обидва кроки форми і звірили: ідентифікатор у картці угоди збігається з тим, що бачить GA4, до символу; мітки кампанії доїжджають повністю. Потім дочекались справжніх заявок — і вони приїхали в CRM уже з джерелом: від органічного пошуку й соцмереж до галузевих каталогів і AI-асистентів. Жодне поле не заповнювалось руками.

2.5. Дашборд, який належить клієнту

Ми свідомо не пішли в Looker Studio чи інший конструктор. Дашборд — це один самодостатній HTML-файл: відкривається з будь-якого пристрою і не потребує ліцензій чи акаунтів. Усі дані за всю історію вже всередині, а вибір періоду та порівняння з попереднім перераховуються прямо в браузері.

Дев’ять розділів: огляд, трафік, воронка заявок, SEO, воронка продажів, канали лідів — і три, що вже чекають на дані: менеджери, послуги та виручка, реклама. У кожному написано, що тут буде, які дані для цього потрібні і хто їх дає. Щойно CRM наповниться сумами і статусами угод, ці розділи почнуть рахувати самі, без доробок.

Дашборд зібраний в айдентиці клієнта — його шрифт і його кольори. Розділи пронумеровані, щоб у листуванні можна було написати «дивіться 6.1» і людина знайшла місце.

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

2.6. Документи для команди

Аналітика працює лише тоді, коли з нею працюють люди. Тому разом із дашбордом команда отримала:

• Стандарт UTM-міток, побудований не на загальних правилах, а на власних даних клієнта: які написання джерел уже розсипались на кілька рядків, які типи трафіку випадають із каналів і чому. Головне правило там одне: utm_medium — не опис вашого трафіку, а значення зі списку, який розуміє GA4.
• Рекомендації «що зробити з вашого боку», відсортовані за цінністю: спершу те, що відкриває головне питання, потім те, що спотворює наявні цифри, потім питання на одну відповідь.
• Записку до дашборда з межами даних і методологією — щоб цифрам довіряли не на слово.

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

3. Результати

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

На які питання він відповідає:

• Скільки сесій і відправок форми дає кожен канал і кожне окреме джерело — не «Referral», а конкретний каталог чи сайт.
• На якому кроці форми люди зупиняються: між початком і першим кроком, чи між першим кроком і відправкою.
• Які сторінки мають покази в пошуку, але не отримують кліків — і що з них стоїть на другій сторінці видачі, тобто найближче до результату.
• Чи з’явився канал, якого торік не було: AI-асистенти ми побачили в даних саме так — окремим джерелом, а не здогадкою.
• Чи збігається найбільший канал за обсягом із найкращим за заявками. За нашим досвідом частіше не збігається — і саме це міняє рішення про бюджет.
• З яких джерел приходять угоди в CRM — із датою, формою й стадією кожної.
• Чи цілі самі дані: щоденні перевірки стежать, щоб стик був на місці, цифри свіжі, а заявки сходились з угодами — і попереджають команду першими.

Найважливіше — змінилась розмова. Раніше питання «звідки цей клієнт» вимагало здогадок. Тепер відповідь лежить у картці угоди, і її не вписувала людина.

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

Перше враження — виглядає дуже круто. Почав занурюватись, цікаві інсайти!

— власник агенції, через день після відкриття дашборда