Налаштування Session Replay (LogRocket/FullStory) для сайту

Налаштування Session Replay (LogRocket/FullStory) для сайту

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

Ми впровадили Session Replay на 50+ проєктах — від інтернет-магазинів до SaaS-платформ. Знаємо, де спотикаються навіть досвідчені команди: витік PII, просідання продуктивності, неочевидні налаштування маскування. Нижче — перевірені підходи, які економлять час і нерви.

Чому варто інтегрувати Session Replay з Sentry?

Зв'язка LogRocket + Sentry дає суперсилу: на кожну помилку ми отримуємо відео сесії користувача. Це скорочує час налагодження в 5–10 разів порівняно з традиційним логуванням. Для інтеграції використовуємо виклик LogRocket.getSessionURL, який повертає пряме посилання на запис, і зберігаємо його в контексті помилки: Sentry.configureScope(scope => scope.setExtra('sessionURL', sessionURL)). Тепер будь-який баг можна розслідувати з повним контекстом дій користувача.

Як організувати маскування даних?

Перед продакшном обов'язково приховати паролі, платіжні дані, персональні поля. У LogRocket для цього використовується параметр inputSanitizer: true — всі текстові поля маскуються. Гнучке налаштування через requestSanitizer дозволяє приховати заголовки авторизації. Якщо потрібно сховати конкретні елементи, додаємо CSS-клас lr-hide. У FullStory також є API-методи для маскування — за селекторами або атрибутами. На практиці маскування всіх PII-полів займає близько 30 хвилин.

LogRocket vs FullStory

Open-source альтернатива з self-hosting — OpenReplay. Він поступається у зручності, але дає повний контроль над даними.

OpenReplay vs LogRocket

LogRocket краще підходить для налагодження складних багів, а FullStory — для UX-аналітики. За нашими спостереженнями, команди, які використовують LogRocket, знаходять корінь проблеми в середньому на 60% швидше.

Встановлення LogRocket

import LogRocket from 'logrocket';
LogRocket.init('your-app/project-id');

// Ідентифікація користувача
LogRocket.identify(user.id, {
  name: user.name,
  email: user.email,
  plan: user.subscriptionPlan
});

Для React додається logrocket-react для відстеження компонентів:

import setupLogRocketReact from 'logrocket-react';
setupLogRocketReact(LogRocket);

Маскування конфіденційних даних

Обов'язково перед продакшном — паролі, платіжні дані, персональні поля:

LogRocket.init('app/id', {
  dom: {
    inputSanitizer: true, // приховує всі inputs
    textSanitizer: false
  },
  network: {
    requestSanitizer: request => {
      if (request.headers['Authorization']) {
        request.headers['Authorization'] = '[redacted]';
      }
      return request;
    }
  }
});

Або через CSS-клас lr-hide на конкретних елементах.

Прив'язка до помилок Sentry

LogRocket.getSessionURL(sessionURL => {
  Sentry.configureScope(scope => {
    scope.setExtra('sessionURL', sessionURL);
  });
});

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

Як ми налаштовуємо Session Replay

Процес налаштування під ключ

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

Що входить у нашу роботу

• Встановлення та налаштування LogRocket/FullStory
• Маскування PII (паролі, email, платежі)
• Інтеграція з Sentry/Datadog/Bugsnag
• Налаштування фільтрів сесій (за браузерами, подіями, користувачами)
• Створення дашбордів для UX-аналітики
• Документація з використання та доступами
• Навчання команди (1 година онлайн)

Терміни та вартість

Терміни залежать від складності інтеграції: від 1 до 5 днів. Вартість розраховується індивідуально — оцінимо ваш проєкт безкоштовно. Економія часу команди може досягати 40 годин на місяць при використанні інтеграції з Sentry. Зв'яжіться з нами для консультації.

Чому нам довіряють

Ми займаємося налаштуванням аналітичних інструментів понад 5 років. Реалізували 50+ проєктів з Session Replay для інтернет-магазинів, SaaS-платформ та корпоративних порталів. Гарантуємо коректну роботу та повне дотримання privacy-стандартів. Замовте налаштування Session Replay у нас.

Як налаштувати веб-аналітику: 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 після оновлення фронтенду

Що входить в роботу

Процес та терміни

1. Аудит поточних тегів та даних (2 дні)
2. Дизайн подієвої схеми (2 дні)
3. Розробка Data Layer та налаштування тегів (3–5 днів)
4. QA в Preview Mode та на staging (2 дні)
5. Деплой та налаштування дашбордів (1 день)

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