Аналіз Error Sessions (сесії з помилками JavaScript)

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

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Аналіз Error Sessions (сесії з помилками JavaScript)
Середній
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Аналіз Error Sessions (сесії з помилками JavaScript)

Уявіть: користувач кладе товар у кошик, натискає «Оформити замовлення» — і нічого не відбувається. Консоль рясніє Cannot read property 'X' of undefined, checkout завис. Ви втрачаєте гроші, а користувач іде до конкурентів. Ми допомагаємо виявити такі помилки та усунути їх до того, як вони обнулять метрики.

Error Sessions — сесії, де сталася одна або кілька JavaScript-помилок. Наш досвід показує: без системного аналізу ви пропускаєте 60–80% критичних багів, які безпосередньо ріжуть конверсію. Ми фільтруємо, аналізуємо та пріоритезуємо ці сесії, використовуючи Sentry та GA4. Sentry з Replay прискорює налагодження в 5–10 разів порівняно з простим логуванням.

Налаштування перехоплення JavaScript-помилок

Перехоплюємо всі необроблені помилки, Promise rejection та збої fetch/XHR. Ключовий елемент — правильне налаштування source maps: Sentry автоматично деобфускує стек, показуючи вихідний код, а не мініфіковані рядки. Приклад інтеграції:

// Перехоплення необроблених помилок
window.addEventListener('error', function(event) {
  const errorInfo = {
    message: event.message,
    source: event.filename?.split('/').pop(),
    line: event.lineno,
    col: event.colno,
    stack: event.error?.stack?.slice(0, 500),
    page: window.location.pathname,
    user_agent: navigator.userAgent.slice(0, 100)
  }

  // Відправити в GA4
  gtag('event', 'js_error', errorInfo)

  // Відправити в Sentry/Bugsnag
  Sentry.captureException(event.error, {
    extra: errorInfo
  })
})

// Перехоплення unhandled Promise rejections
window.addEventListener('unhandledrejection', function(event) {
  gtag('event', 'promise_rejection', {
    message: event.reason?.message || String(event.reason),
    page: window.location.pathname
  })
})

// Перехоплення помилок у fetch/XHR
const originalFetch = window.fetch
window.fetch = async function(...args) {
  try {
    const response = await originalFetch(...args)
    if (!response.ok) {
      gtag('event', 'fetch_error', {
        url: args[0].toString().split('?')[0],
        status: response.status,
        page: window.location.pathname
      })
    }
    return response
  } catch (err) {
    gtag('event', 'fetch_exception', {
      url: args[0].toString().split('?')[0],
      message: err.message
    })
    throw err
  }
}

Більш детально про window.onerror читайте в документації MDN. Як зазначено в документації Sentry, інтеграція з source maps та Replay прискорює налагодження в 5–10 разів порівняно зі звичайним логуванням.

Інтеграція Sentry з Replay та Tracing

Для глибокого аналізу підключаємо Sentry з Replay та Tracing. Replay записує сесію до моменту помилки, що дозволяє побачити дії користувача. Приклад конфігурації:

// sentry.init.js
import * as Sentry from '@sentry/browser'
import { BrowserTracing } from '@sentry/tracing'

Sentry.init({
  dsn: 'https://[email protected]/yyy',
  integrations: [
    new BrowserTracing(),
    new Sentry.Replay({
      maskAllText: false,
      blockAllMedia: false
    })
  ],
  tracesSampleRate: 0.1,   // 10% для performance
  replaysSessionSampleRate: 0.05,  // 5% сесій записувати
  replaysOnErrorSampleRate: 1.0,   // 100% при помилці

  beforeSend(event) {
    // Додати контекст користувача
    event.user = {
      id: currentUser?.id,
      segment: currentUser?.plan
    }
    return event
  }
})

Як помилки впливають на конверсію?

Ми будуємо SQL-запити, що порівнюють CVR сесій з помилками та без. Типовий результат: сесії з помилками конвертують у 3+ рази гірше. Приклад коду:

def analyze_error_impact(analytics_db):
    # Порівняти конверсію сесій з помилками vs без
    result = analytics_db.query("""
        WITH session_errors AS (
            SELECT
                session_id,
                COUNT(*) as error_count,
                MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) as converted
            FROM events
            WHERE date >= CURRENT_DATE - INTERVAL '7 days'
            AND event_name IN ('js_error', 'purchase')
            GROUP BY session_id
        ),
        all_sessions AS (
            SELECT session_id,
                   MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) as converted
            FROM events
            WHERE date >= CURRENT_DATE - INTERVAL '7 days'
            GROUP BY session_id
        )
        SELECT
            'with_errors' AS segment,
            COUNT(*) AS sessions,
            SUM(converted) AS conversions,
            ROUND(AVG(converted::float) * 100, 2) AS cvr
        FROM session_errors WHERE error_count > 0

        UNION ALL

        SELECT
            'without_errors',
            COUNT(*),
            SUM(a.converted),
            ROUND(AVG(a.converted::float) * 100, 2)
        FROM all_sessions a
        LEFT JOIN session_errors se ON a.session_id = se.session_id
        WHERE se.session_id IS NULL
    """)
    return result

# Типовий результат:
# with_errors:    1.2% CVR
# without_errors: 3.8% CVR
# Помилки знижують конверсію в 3+ рази
Сегмент Сесії Конверсії CVR
З помилками 12450 149 1.2%
Без помилок 112050 4258 3.8%

Різниця — у 3.2 рази. Якщо ваш середній чек 3000 ₴, втрати за тиждень становлять понад 1.2 млн ₴.

Порівняння інструментів моніторингу

Інструмент Source maps Replay Інтеграція з GA4 Ціна
Sentry Так Так Через API Безкоштовно до 5k подій/міс
Bugsnag Так Ні Через API Від $29/міс
LogRocket Так Так Ні Від $39/міс
GA4 Ні Ні Вбудовано Безкоштовно

Sentry — оптимальний вибір для глибокого аналізу: він поєднує source maps, Replay та гнучку інтеграцію з GA4. Порівняно з GA4, Sentry краще підходить для налагодження, оскільки надає повний стек та Replay, що скорочує час пошуку причини в 5–10 разів.

Як пріоритезувати виправлення помилок?

Ми використовуємо метрику affected_users × conversion_impact. Помилки в модулях checkout/payment отримують вагу 3, решта — 1. Приклад:

def prioritize_errors(sentry_api, project_slug):
    """Пріоритет = affected_users × conversion_impact"""
    issues = sentry_api.get_issues(project_slug, limit=50)

    for issue in issues:
        affected_users = issue['userCount']
        # Помилки в checkout/payment — високий пріоритет
        is_critical = any(p in issue['culprit'] for p in
                         ['checkout', 'payment', 'cart', 'form'])
        issue['priority_score'] = affected_users * (3 if is_critical else 1)

    return sorted(issues, key=lambda x: x['priority_score'], reverse=True)

Типові критичні помилки

  • Cannot read property 'X' of undefined — race condition при асинхронному завантаженні
  • Network Error у fetch — API недоступний, немає retry логіки
  • PaymentRequestUpdateEvent — помилки Payment Request API на iOS Safari
  • ChunkLoadError — застарілий кеш після деплою (вирішується: window.location.reload())
Кейс з практики: як підняли CVR на 25%

На одному проекті (інтернет-магазин електроніки) після деплою нової версії checkout-модуля конверсія впала з 3.5% до 1.1%. З'ясувалося, що в 40% сесій виникала помилка Cannot read property 'price' of undefined через зміну формату відповіді API. Sentry показав, що помилка зачіпає 15k користувачів на день. Після фіксу та повторного деплою CVR повернулася до 3.5% через 2 дні. Втрати за 3 дні склали ~900 замовлень.

Що входить у послугу

  • Налаштування перехоплення всіх JS-помилок (включаючи source maps)
  • Інтеграція Sentry з Replay та Tracing
  • Створення подій у GA4 для конверсійного аналізу
  • Дашборди впливу помилок на CVR та виручку
  • Пріоритезований список багів з рекомендаціями
  • Документація по інтеграції та доступ до дашбордів
  • Підтримка протягом місяця після впровадження

Процес роботи

  1. Аудит поточного моніторингу: перевіряємо, які помилки вже перехоплюються.
  2. Налаштування інструментів: встановлюємо Sentry, доопрацьовуємо GA4 events.
  3. Збір даних: 7 днів накопичення статистики по Error Sessions.
  4. Аналіз та пріоритезація: будуємо SQL-звіти, обчислюємо вплив на конверсію.
  5. Звіт та виправлення: передаємо вам список багів із зазначенням критичності, допомагаємо з правками.
  6. Контроль: після виправлень повторюємо аналіз, щоб переконатися в рості CVR.

Строки та результати

Перші результати — вже через 2 робочі дні: ви бачите дашборд з Error Sessions та їх впливом. Повний цикл аналізу та пріоритезації — від 5 до 7 днів. Конкретна вартість залежить від обсягу проекту (кількість сторінок, інтеграцій), тому ми розраховуємо її індивідуально. Зв'яжіться — оцінимо ваш проект безкоштовно.

Чому обирають нас

Наш досвід — понад 10 років у frontend-розробці та моніторингу. Ми працювали з проектами, де CVR зросла на 25% лише за рахунок усунення JS-помилок. Використовуємо лише перевірені інструменти: Sentry, GA4, Grafana. Даємо гарантію на коректну роботу інтеграцій. Замовте аудит — отримайте консультацію з детальним розбором ваших Error Sessions. Зв'яжіться з нами — ми підготуємо індивідуальну пропозицію.

Як налаштувати веб-аналітику: 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
Навчання та передача Доступи, інструкція з додавання нових подій, консоль

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

  1. Аудит поточних тегів та даних (2 дні)
  2. Дизайн подієвої схеми (2 дні)
  3. Розробка Data Layer та налаштування тегів (3–5 днів)
  4. QA в Preview Mode та на staging (2 дні)
  5. Деплой та налаштування дашбордів (1 день)
Сценарій Термін
Базове налаштування GA4 + GTM 1 тиждень
Повний e-commerce tracking + Метрика 2–3 тижні
Server-side GTM + Amplitude 3–5 тижнів

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