Ви запустили інтернет-магазин на Laravel + React — 10 000 відвідувачів на день, але конверсія 1%. Google Analytics показує лише сторінки та сесії, а вам потрібні відповіді: який елемент форми відвалює, коли користувач кидає кошик. Mixpanel — інструмент подієвої аналітики, який перетворює кожну дію користувача на структуровану подію з контекстом. Ми — команда з 5-річним досвідом у веб-аналітиці, впровадили Mixpanel на 30+ проєктах. Беремося за інтеграцію під ключ: від SDK до дашбордів з когортами та воронками. Замовте консультацію — оцінимо проєкт за 24 години.
Mixpanel (en.wikipedia.org/wiki/Mixpanel) — платформа, орієнтована на події, а не на сторінки.
Чому Mixpanel кращий за Google Analytics для подієвої аналітики?
Google Analytics зав'язаний на сесії та перегляди сторінок. Mixpanel — на події: «натиснув кнопку», «заповнив форму», «почав оформлення». Воронки будуються миттєво, retention показує, скільки користувачів повернулося. Для SaaS та e-commerce це дає глибину, недоступну GA. Крім того, Mixpanel сегментує користувачів за властивостями без SQL.
| Характеристика |
Google Analytics |
Mixpanel |
| Модель даних |
Сесії та перегляди сторінок |
Події та властивості |
| Воронки |
Обмежені, на основі цілей |
Довільні, на будь-яких подіях |
| Retention |
Сегменти, але негнучко |
Когорти, авто-оновлювані |
| Ідентифікація |
User-ID (складне налаштування) |
Identify/Alias (1 метод) |
| Вартість |
Безкоштовно (з обмеженнями) |
Від $25/міс, але точніше |
Як ми налаштовуємо Mixpanel: встановлення SDK
Використовуємо два підходи: NPM-пакет для SPA або CDN-скрипт для класичних сайтів. В обох випадках ініціалізація з токеном із змінних оточення.
// NPM: встановлення та ініціалізація
import mixpanel from 'mixpanel-browser';
mixpanel.init(import.meta.env.VITE_MIXPANEL_TOKEN, {
debug: import.meta.env.DEV,
track_pageview: false,
persistence: 'localStorage',
ignore_dnt: false,
batch_requests: true,
batch_flush_interval_ms: 5000,
});
Для класичних сайтів підключаємо CDN-скрипт з mixpanel.init('YOUR_TOKEN'). Режим batch_requests збільшує продуктивність — події надсилаються пачками раз на 5 секунд. У проєктах з високим навантаженням (понад 1000 подій/с) збільшуємо інтервал до 15 секунд, економлячи до 40% запитів.
Деталі налаштування batch-відправки
Щоб зменшити навантаження на браузер, ми вмикаємо batch_requests: true. Це надсилає події пачками кожні 5 секунд. Для високонавантажених проєктів збільшуємо інтервал до 10–15 секунд. Економить до 40% запитів.
Що входить в нашу роботу
- SDK та трекінг: встановлення, налаштування базових подій (Page Viewed, Button Clicked, Form Submitted)
- Ідентифікація: зв'язування анонімних сеансів з реальними користувачами (identify, alias)
- Суперпроперті: автоматична передача контексту (версія застосунку, A/B-варіант, UTM-мітки)
- Server-side: трекінг подій з бекенду (оплати, поштові сповіщення) через HTTP API
- Дашборди та воронки: побудова звітів, налаштування сповіщень
- Документація: опис усіх подій, властивостей та схеми даних
- Навчання: передаємо знання вашій команді, консультуємо з аналітики
- Підтримка: 2 тижні після впровадження — допомагаємо з доопрацюваннями та питаннями
Трекінг подій: від простого до складного
Базовий трекінг — метод track. Для інтернет-магазину відстежуємо Product Viewed, Add to Cart, Purchase Completed. Кожна подія містить контекст: URL, реферер, користувацькі властивості.
// Приклади подій
mixpanel.track('Page Viewed', {
page_title: document.title,
page_url: window.location.pathname,
referrer: document.referrer || 'direct',
});
mixpanel.track('Button Clicked', {
button_text: 'Залишити заявку',
button_location: 'hero_section',
});
Як ідентифікувати користувача без реєстрації?
Якщо користувач заповнив форму, але не зареєструвався, використовуємо mixpanel.alias(email). Це зв'язує анонімний ID з email. Після реєстрації викликаємо identify(user.id) і встановлюємо властивості профілю через people.set. Суперпроперті (register) додаються один раз і передаються в усі наступні події.
Server-side трекінг: події з бекенду
Для операцій, недоступних на клієнті (підтвердження оплати, активація по email), використовуємо HTTP API Mixpanel. Надсилаємо POST-запит з base64-закодованим JSON. Наш досвід показує, що це підвищує точність даних на 15–20%.
// Приклад на Laravel
$data = [
'event' => 'Payment Completed',
'properties' => [
'token' => $token,
'distinct_id' => $userId,
'time' => time(),
'$insert_id' => uniqid('srv_', true),
'amount' => 14500,
],
];
Http::asForm()->post($endpoint, [
'data' => base64_encode(json_encode([$data])),
]);
Відлагодження та перевірка
Вмикаємо debug-режим: mixpanel.set_config({ debug: true }). У консолі бачимо логи кожного track-виклику. Розширення Mixpanel для Chrome DevTools показує події в реальному часі. Гарантуємо, що дані відправляються коректно — перевіряємо на тестовому проєкті до запуску. Вартість інтеграції залежить від складності, але в середньому економія на внутрішніх ресурсах становить до 40% порівняно з самостійною розробкою.
Строки та вартість
Базова інтеграція (SDK + базові події) — 4–6 годин. Повний цикл з ідентифікацією, server-side та дашбордами — 1–2 дні. Вартість розраховується індивідуально, залежить від складності вашого проєкту. Замовте аудит вашого стеку аналітики — ми підберемо оптимальну схему та дамо оцінку за 24 години.
| Етап |
Час |
| Встановлення SDK |
2–4 години |
| Трекінг подій |
2–4 години |
| Ідентифікація |
4–6 годин |
| Server-side трекінг |
4–8 годин |
| Дашборди та воронки |
4–8 годин |
Як налаштувати веб-аналітику: 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 день.