Уявіть: сайт приносить 1000 відвідувачів на день, але виручка не зростає. Менеджери скаржаться на трафік, маркетологи — на конверсію, а розробники розводять руками. Без налаштованої воронки продажів ви летите навмання. Стандартні звіти GA4 та Яндекс.Метрики показують загальну конверсію, але не локалізують точки відмови. Ми знаємо, як це виправити: налаштовуємо воронки під ключ, використовуючи інструменти сегментації, когортного аналізу та наскрізної аналітики. Виявляємо, на якому етапі — перегляд товару, додавання в кошик, оформлення — втрачаються клієнти, і збільшуємо конверсію на кожному кроці. Оцінимо проєкт за 1 день — пишіть!
Проблеми, які вирішуємо
Розмитий шлях користувача. Стандартні звіти не показують, де відвалюються клієнти. Воронка з сегментацією за джерелами трафіку та когортний аналіз дають чітку картину. Наприклад, крок «додавання в кошик» конвертує 5% — проблема в UX або ціні. Оптимізація конверсії на основі звітів воронки скорочує втрати.
Втрати від блокувальників реклами. GA4 втрачає до 30% подій на мобільних. Рішення — дублювати відправлення на власний бекенд. Це дає контрольну вибірку та підвищує точність звітів по воронці. Один клієнт після впровадження такої схеми збільшив точність даних на 22%.
Нормальні показники конверсії для e-commerce
| Етап |
Частка від попереднього |
| Перегляд товару → додавання в кошик |
40-60% |
| Додавання в кошик → початок оформлення |
5-15% |
| Початок оформлення → оплата |
30-50% |
| Оплата → покупка |
85-95% |
Розбіжності в даних GA4 та Яндекс.Метрики
Причина — різна архітектура збору. GA4 використовує події із затримкою обробки до доби, Метрика — потокову передачу. Якщо паралельно запустити обидва лічильники, без уніфікації логіки подій отримаєте розбіжності. Ми налаштовуємо ідентичні події та метрики в обох системах, а для критичних проєктів — пишемо власну воронку в PostgreSQL. Це забезпечує наскрізну аналітику та єдине джерело правди. GA4 обробляє події до 24 годин, тоді як Метрика — до години, що робить її в 24 рази швидшою для оперативних звітів.
Як ми це робимо
Стек: PostgreSQL для зберігання подій, Laravel 11 для бекенду збору, Redis для кешування. Приклад конфігурації воронки в GA4:
Funnel Exploration → Steps:
1. view_item (URL содержит /product)
2. add_to_cart
3. begin_checkout
4. add_payment_info
5. purchase
У Яндекс.Метриці за URL та цілями:
Шаг 1: URL содержит /catalog
Шаг 2: URL содержит /product
Шаг 3: Цель "add_to_cart"
Шаг 4: Цель "order_placed"
Для high-load використовуємо ClickHouse — відгук SQL-запитів до 100 мс на мільярдах рядків.
Як сегментація покращує аналіз воронки?
Сегментація за джерелом трафіку, пристроєм або гео дозволяє виявити приховані проблеми. Наприклад, органика може конвертувати 3%, а реклама — 0.5%. Без сегментації ви усереднюєте дані та втрачаєте точки зростання. Ми налаштовуємо сегментовані воронки та когортний аналіз для кожного каналу.
Що таке когортний аналіз у воронці?
Когортний аналіз групує користувачів за часом першого візиту або дії. Це допомагає відстежити, як змінюється поведінка різних груп. Наприклад, когорта, що прийшла з рекламної кампанії, може мати вищу конверсію на етапі оформлення, але нижчу — на додаванні в кошик. Такий аналіз виявляє ефективність каналів та сезонні тренди.
Процес роботи
- Аналітика — аудит цілей та подій, інтерв'ю з маркетологами.
- Проектування — узгодження схеми воронки, вибір інструментів.
- Реалізація — налаштування подій, exploration, SQL-запити.
- Тестування — перевірка на тестових сесіях.
- Деплой — викатка в продакшен, дашборди, документація.
Що входить у роботу
- Документація з кроками воронки та сегментами.
- Готові exploration у GA4 та звіти в Метриці.
- Навчання команди (1 година онлайн).
- Підтримка 2 тижні після запуску.
Чому варто довірити налаштування нам?
Досвід 5+ років у веб-аналітиці, понад 50 проєктів для e-commerce та B2B. Гарантуємо прозорість: надаємо SQL-скрипти та документацію. Замовте налаштування — отримайте воронку, яка реально допомагає заробляти. Економія на неефективній рекламі може скласти до 30% після налаштування воронки.
Строки орієнтовно
Базове налаштування (GA4 + Метрика) — від 2 до 4 днів. Розширене (з власною БД та сегментацією) — від 5 до 8 днів. Вартість розраховується індивідуально, залежить від складності.
Типові помилки при налаштуванні воронок
- Неправильна послідовність кроків (наприклад, purchase раніше begin_checkout) — нульова конверсія.
- Ігнорування сегментації — одна воронка для всіх джерел приховує проблеми.
- Відсутність захисту від блокувальників — втрата до третини даних.
Таблиця порівняння: GA4 vs Яндекс.Метрика
| Критерій |
GA4 |
Яндекс.Метрика |
| Затримка даних |
до 24 годин |
до 1 години |
| Типи воронок |
закрита / відкрита |
тільки послідовна |
| Сегментація |
за будь-якими параметрами |
за статтю, віком, ціллю |
| Експорт даних |
через BigQuery |
через API / CSV |
| Безкоштовний ліміт |
~10 млн подій/міс |
безліміт |
Джерело: офіційна документація воронка продажів
Ми супроводжуємо повний цикл встановлення аналітики інтернет-магазину: від налаштування цілей до наскрізної аналітики. Отримайте консультацію — ми допоможемо визначитися з інструментом та налаштуємо все під ключ.
Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude
Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.
Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.
Чому події GA4 дублюються і як це виправити?
Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.
Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.
Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.
Як налаштувати data layer, щоб не втратити дані?
GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.
window.dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'view_item',
ecommerce: {
items: [{
item_id: 'SKU-12345',
item_name: 'Назва товару',
price: null,
currency: null
}]
}
});
Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.
Як Яндекс.Метрика доповнює веб-аналітику?
Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.
Що дає product analytics в Amplitude?
Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.
Моніторинг якості даних
Аналітика без моніторингу — чорна скринька. Налаштовуємо:
- GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
- Alerting в GA4 — аномалія в кількості подій
purchase (різке падіння = щось зламалося)
- GTM Preview в staging-оточенні перед продакшеном
- Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається
Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.
Що перевіряємо після кожного деплою
- Чи всі рекомендовані події присутні в DebugView
- Чи немає задвоєнь (рахуємо кількість
purchase на 100 сесій)
- Чи не змінилася структура dataLayer після оновлення фронтенду
Що входить в роботу
| Компонент |
Опис |
| Аудит поточних тегів |
Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок |
| Дизайн подієвої схеми |
Документація: список подій, параметри, тригери |
| Налаштування GA4 + GTM |
Створення конфігурації, тегів, Custom definitions |
| Яндекс.Метрика |
Встановлення лічильника, створення цілей, налаштування Вебвізора |
| Amplitude (опціонально) |
Налаштування клієнтського та серверного SDK, когорти |
| QA та моніторинг |
Тестування в Preview Mode, Alerting |
| Навчання та передача |
Доступи, інструкція з додавання нових подій, консоль |
Процес та терміни
- Аудит поточних тегів та даних (2 дні)
- Дизайн подієвої схеми (2 дні)
- Розробка Data Layer та налаштування тегів (3–5 днів)
- QA в Preview Mode та на staging (2 дні)
- Деплой та налаштування дашбордів (1 день)
| Сценарій |
Термін |
| Базове налаштування GA4 + GTM |
1 тиждень |
| Повний e-commerce tracking + Метрика |
2–3 тижні |
| Server-side GTM + Amplitude |
3–5 тижнів |
Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.