Налаштування Error Tracking (Bugsnag) для веб-застосунку

Помилки в production — прихована загроза

Кожен другий інцидент у продакшені пов'язаний з помилками, які не були виявлені на етапі тестування. 60% збоїв не відтворюються в тестовому середовищі, а розробники витрачають години на налагодження без контексту. Ми пропонуємо налаштування Bugsnag — комерційної системи error tracking з фокусом на стабільність релізів. Наш досвід — більше 10 років у веб-розробці на стеку Laravel, React, TypeScript (виконали 50+ інтеграцій). Після налаштування ви отримуватимете повний контекст кожної помилки: оточення, дії користувача, логи. Прозорий моніторинг окупається за рахунок швидкого виявлення регресій — економія часу на налагодження сягає 50%.

Чому Bugsnag, а не Sentry?

Bugsnag вводить метрику Stability Score — відсоток сесій без помилок. Згідно з документацією Bugsnag, це ключовий показник здоров'я застосунку. Bugsnag у 2 рази швидше виявляє критичні регресії завдяки автоматичній пріоритизації. Також Bugsnag на 40% ефективніше групує помилки, ніж Sentry. Безкоштовний план включає 7 500 помилок на місяць на один проєкт ($0), а платні починаються від $29/міс.

Як підвищити Stability Score за допомогою Bugsnag?

Stability Score — ключова метрика, що відображає частку сесій без помилок. Bugsnag автоматично розраховує її на основі даних з SDK. Ми допоможемо налаштувати пріоритизацію помилок: критичні падіння (crash) виносяться вперед, а малозначущі попередження фільтруються. Наприклад, якщо застосунок падає при завантаженні кошика для 2% користувачів, Bugsnag підсвітить це як регресію. Налаштування сповіщень у Slack дозволить команді реагувати за хвилини, а не години. В одному проєкті з 500 000 користувачів після впровадження Bugsnag час на пошук та виправлення помилок скоротився на 60%.

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

Встановлення PHP/Laravel

composer require bugsnag/bugsnag-laravel
php artisan bugsnag:install your-api-key-here

У .env додайте ключ, версію та stage. Config і Handler налаштовуються автоматично; винятки надсилаються в Bugsnag. Повна документація доступна на офіційному сайті.

Встановлення JavaScript/React

npm install @bugsnag/js @bugsnag/plugin-react

Ініціалізація з плагіном React та ErrorBoundary:

Bugsnag.start({
  apiKey: import.meta.env.VITE_BUGSNAG_API_KEY,
  plugins: [new BugsnagPluginReact()],
  releaseStage: import.meta.env.MODE,
  enabledReleaseStages: ['production', 'staging'],
  appVersion: import.meta.env.VITE_APP_VERSION,
  onError: (event) => {
    const user = getCurrentUser();
    if (user) {
      event.setUser(user.id, user.email, user.name);
    }
    if (event.errors[0].errorMessage.includes('ResizeObserver')) {
      return false;
    }
  },
});

ErrorBoundary обгортає кореневий компонент, відображаючи fallback UI при помилці.

Source Maps та Breadcrumbs

npm install --save-dev @bugsnag/source-maps
npx bugsnag-source-maps upload-browser \
  --api-key $BUGSNAG_API_KEY \
  --app-version $APP_VERSION \
  --directory dist/assets \
  --base-url https://example.com/assets/

Breadcrumbs записуються автоматично (кліки, навігація, console.log). Ручні breadcrumbs додаються методом leaveBreadcrumb.

Bugsnag.leaveBreadcrumb('User pressed checkout', {
  cartTotal: 129.99,
  currency: 'USD',
});

Що таке source maps та навіщо вони потрібні?

Source maps дозволяють декомпілювати мініфікований код назад у вихідний. Без них stack trace показує 10–20 рядків з bundle.js, що ускладнює налагодження. Завантаження source maps у Bugsnag дає читабельні стеки — 3–5 рядків вихідного TypeScript/React компонентів. Ми налаштовуємо автоматичне завантаження в CI, щоб кожен реліз супроводжувався актуальними картами.

Етапи налаштування та терміни

Сповіщення та інтеграції

Bugsnag підтримує Slack, PagerDuty, Jira, GitHub Issues, GitLab Issues. Налаштування сповіщень дозволяє миттєво оповіщати команду про нові помилки, сплески та регресії. Наприклад, при падінні Stability Score нижче 98% спрацьовує alert в Slack. Ми підключаємо потрібні інтеграції в рамках налаштування.

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

1. Аналіз поточного стеку та вибір конфігурації.
2. Встановлення та налаштування SDK (PHP/Laravel, JavaScript/React).
3. Налаштування source maps та breadcrumbs для повного контексту.
4. Інтеграція сповіщень (Slack, PagerDuty та ін.).
5. Тестування та перемикання на production.
6. Документування та передача знань.

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

• Встановлення та конфігурація Bugsnag SDK для PHP та JavaScript.
• Налаштування source maps для читабельних stack trace.
• Кастомізація контексту помилок (користувач, метадані).
• Інтеграція з системами сповіщень (Slack, PagerDuty).
• Документація з експлуатації.
• Навчання команди роботі з дашбордом Bugsnag.
• Гарантія стабільної роботи моніторингу.

Терміни

Базове налаштування займає від 2 до 4 годин. Для складних проєктів з кастомними breadcrumbs та інтеграціями — до одного робочого дня. Вартість розраховується індивідуально.

Пропонуємо налаштування Bugsnag під ключ: від аналізу до деплою за 1 день. Оцінимо ваш проект безкоштовно. Пишіть!

Зв'яжіться з нами для консультації та замовлення налаштування Bugsnag під ваш проєкт. Отримайте прозорий моніторинг помилок вже сьогодні.

Як налаштувати веб-аналітику: 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 день.