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

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

Sentry — стандарт de facto для відстеження помилок. Але 90% розробників обмежуються встановленням SDK, забуваючи про source maps, release tracking та фільтрацію шуму. Результат: тони хибних спрацьовувань, втрата критичних помилок та години на їх пошук. Ми налаштовуємо Sentry під ключ — від інтеграції з Laravel (PHP 8.3) та React 18 до алертів у Telegram та автоматичного прив'язування комітів через CI/CD. Досвід роботи над 15+ проєктами з навантаженням до 10k RPS гарантує, що ви не потонете в шумі, а кожна помилка буде вчасно помічена.

Нещодавно на проєкті з Laravel та React ми зіткнулися з ситуацією: помилка в production проявлялася лише у 1% користувачів. Без Sentry її не могли відтворити декілька днів. Після налаштування знайшли причину за 10 хвилин — проблема зі станом гонки в Redux. Така діагностика недоступна при простому логуванні.

Чому Sentry краще простого логування?

Sentry не просто зберігає помилки — групує їх за стеком, показує частоту, контекст (змінні оточення, breadcrumbs) та історію змін. На відміну від логів, ви одразу бачите, яка помилка критична, хто її викликав та в якому релізі вона з'явилася. Це скорочує час пошуку причин на 70% — з годин до хвилин. Sentry працює в 10 разів швидше традиційних систем моніторингу при виявленні регресій.

Дані Sentry показують, що налаштування source maps прискорює налагодження на 70%. Типова економія від скорочення часу на налагодження становить $200–500 на місяць для середнього проєкту.

Порівняння варіантів розгортання

Як налаштувати Sentry за 4 кроки?

1. Встановлення SDK: на backend (Laravel) та frontend (React).
2. Налаштування source maps: для читабельних стеків у браузері.
3. Фільтрація шуму: виключення ботів, очікуваних помилок та розширень.
4. Алерти та release tracking: сповіщення в Telegram та прив'язка комітів.

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

Backend PHP/Laravel:

composer require sentry/sentry-laravel
php artisan sentry:publish --dsn=https://[email protected]/project-id

У .env додайте SENTRY_LARAVEL_DSN та SENTRY_TRACES_SAMPLE_RATE=0.1. SDK реєструється автоматично.

Frontend React/Next.js:

npm install @sentry/react

Ініціалізація:

import * as Sentry from '@sentry/react';
Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  environment: import.meta.env.MODE,
  release: import.meta.env.VITE_APP_VERSION,
  integrations: [Sentry.browserTracingIntegration(), Sentry.replayIntegration({ maskAllText: false, blockAllMedia: false })],
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.05,
  replaysOnErrorSampleRate: 1.0,
});

Як налаштувати source maps для налагодження?

Без source maps стек викликів — мініфікований код. Встановіть плагін @sentry/vite-plugin, потім налаштуйте:

import { sentryVitePlugin } from '@sentry/vite-plugin';
export default defineConfig({
  build: { sourcemap: true },
  plugins: [react(), sentryVitePlugin({ org: 'your-org', project: 'your-project', authToken: process.env.SENTRY_AUTH_TOKEN, sourcemaps: { assets: './dist/**', ignore: ['node_modules'], filesToDeleteAfterUpload: ['./dist/**/*.map'] } })],
});

Source maps завантажуються при збірці та видаляються з публічної директорії — користувачі їх не побачать. Детальніше про налаштування source maps читайте в документації Sentry.

Фільтрація шуму

За замовчуванням Sentry ловить все: ботів, 404, помилки розширень. Налаштовуємо фільтри:

// config/sentry.php
'before_send' => function (\Sentry\Event $event, ?\Sentry\EventHint $hint): ?\Sentry\Event {
    $exception = $hint?->exception;
    if ($exception instanceof \Illuminate\Auth\AuthenticationException) return null;
    if ($exception instanceof \Symfony\Component\HttpKernel\Exception\NotFoundHttpException) return null;
    $userAgent = request()->header('User-Agent', '');
    if (str_contains(strtolower($userAgent), 'bot')) return null;
    return $event;
},

Frontend (JavaScript):

Sentry.init({
  denyUrls: [/extensions\//i, /^chrome:\/\//i, /^chrome-extension:\/\//i],
  ignoreErrors: ['ResizeObserver loop limit exceeded', 'Non-Error promise rejection captured'],
});

Фільтри знижують кількість хибних помилок на 80–90%, залишаючи лише реальні проблеми.

Release tracking

При деплої створюйте реліз через sentry-cli: sentry-cli releases new "$VERSION", set-commits, finalize та deploys new -e production. Це дозволяє бачити, в якому релізі та коміті вперше з'явилася помилка.

Типи алертів

Налаштуйте alert rule: New issue — при першому входженні, Error frequency — >100 разів за годину, Regression — помилка повернулася після resolved. Інтеграції: Telegram (через webhook), Slack, PagerDuty. Замовте налаштування — ми підключимо будь-який канал за годину.

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

• Встановлення SDK на backend та frontend.
• Source maps для браузерних застосунків.
• Фільтрація шуму (боти, очікувані помилки, розширення).
• Release tracking у CI/CD.
• Alert-правила в Telegram/Slack.
• Документація та навчання команди.

Терміни та економія

Базове налаштування SDK, source maps, фільтрація та алерти — 2–4 години. Повний цикл з CI/CD — до 2 днів. Налаштування окупається в середньому за 2–3 місяці, економлячи до $300 на місяць на підтримці. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Замовте налаштування Sentry сьогодні — і забудьте про втрачені помилки.

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