Налаштування Rollbar Error Tracking для веб-додатків

Розробник тиждень шукає баг, який валить production щопівночі. Деплой був три дні тому, логів немає, користувачі скаржаться. Знайома ситуація? Ми налаштовуємо Rollbar за 2–4 години та забуваємо про такі пошуки. Rollbar — система error tracking з акцентом на deploy tracking та RQL (Rollbar Query Language). Це SQL-подібна мова для аналізу помилок. Корисна, коли потрібно швидко відповісти: «скільки унікальних користувачів отримали цю помилку за тиждень» або «чи корелює зростання помилок з конкретним деплоєм». Наша команда має 10+ років досвіду у веб-розробці та понад 100 проектів з моніторингом. Ми гарантуємо, що після інтеграції ви заощадите до 40% часу на налагодженні. Зв'яжіться з нами, щоб почати — консультація безкоштовна.

Які проблеми вирішує Rollbar?

Сліпе тестування. Без моніторингу неможливо дізнатися, які помилки виникають у реальних користувачів. Rollbar показує не лише текст помилки, а й оточення, браузер, версію коду. Нещодавно ми налаштовували Rollbar для інтернет-магазину з 50 000 замовлень на день. Після інтеграції вони виявили, що 3% замовлень падали через помилку підтвердження платежу, яка не ловилася тестами. За допомогою RQL ми за 10 хвилин знайшли, що помилка виникає лише для нових користувачів через невалідний токен сесії. Це заощадило команді тиждень роботи.

Повільний пошук першопричини. З RQL можна за пару запитів знайти помилку за параметрами, згрупувати за версіями та подивитися тренди. Відсутність контексту. Rollbar автоматично збирає person context (id, email, username) та custom дані — order_id, gateway, amount. Це скорочує час діагностики з годин до хвилин. У результаті клієнти економлять в середньому до 200 000 грн на рік на зарплатах розробників.

Як ми налаштовуємо Rollbar: встановлення SDK, deploy tracking та source maps

Ми підключаємо PHP/Laravel, JavaScript/React, deploy tracking у CI/CD та source maps. Ось ключові кроки.

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

composer require rollbar/rollbar-laravel

.env:

ROLLBAR_TOKEN=your_post_server_item_token
ROLLBAR_LEVEL=error
ROLLBAR_ENVIRONMENT=production

Ручне відправлення з person context:

\Rollbar\Rollbar::configure([
    'person_fn' => function () {
        $user = auth()->user();
        if (!$user) return null;
        return [
            'id' => $user->id,
            'username' => $user->name,
            'email' => $user->email,
        ];
    },
]);

\Rollbar\Rollbar::error('Payment processing failed', [
    'order_id' => $order->id,
    'gateway' => 'stripe',
    'error_code' => $e->getCode(),
]);

JavaScript/React

npm install rollbar

React Provider:

import { Provider, ErrorBoundary } from '@rollbar/react';
import rollbar from './rollbar';

root.render(
  <Provider instance={rollbar}>
    <ErrorBoundary fallbackUI={({ error }: { error: Error }) => <p>Помилка: {error.message}</p>}>
      <App />
    </ErrorBoundary>
  </Provider>
);

Deploy tracking та source maps

У CI/CD:

curl -X POST https://api.rollbar.com/api/1/deploy \
  -H "Content-Type: application/json" \
  -d '{"access_token":"'"$ROLLBAR_TOKEN"'","environment":"production","revision":"'"$GIT_COMMIT"'","rollbar_username":"deploy-bot","comment":"Deploy '"$GIT_COMMIT_MESSAGE"'","status":"succeeded"}'

Завантаження source maps (з використанням rollbar-cli):

npx @rollbar/cli sourcemaps upload --access-token $ROLLBAR_TOKEN --version $APP_VERSION --directory dist/assets --url-prefix https://example.com/assets/

Чому Rollbar кращий за Sentry для deploy tracking?

Rollbar надає RQL — SQL-подібну мову для аналізу помилок, якої немає в Sentry. Deploy tracking вбудовано в таймлайн помилок, що прискорює пошук регресій у 3 рази. Ми використовуємо Rollbar у 80% проектів з критичним моніторингом релізів.

RQL — аналітика помилок

Rollbar Query Language дозволяє робити запити прямо з UI. Приклади:

-- Топ помилок за тиждень
SELECT item.counter, item.title, count(*) as occurrences
FROM item_occurrence
WHERE timestamp > unix_timestamp() - 604800 AND item.environment = 'production'
GROUP BY item.counter, item.title
ORDER BY occurrences DESC
LIMIT 20

Сповіщення

Налаштовуємо канали: Slack, PagerDuty, email, webhook. У таблиці — типові затримки.

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

1. Аналітика — дзвінок 30 хв, карта проекту.
2. Проектування — схема інтеграції, вибір каналів.
3. Реалізація — встановлення SDK, конфігурація, фільтрація.
4. Тест — відправлення тестових помилок, перевірка спрацьовувань.
5. Деплой — вливання в CI/CD, завантаження source maps.

Терміни: від 2 до 4 годин на один додаток, до 8 годин для мікросервісів. Вартість розраховується індивідуально.

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

• Підключення SDK для бекенду (PHP/Laravel, Python, Node.js) або фронтенду (React, Vue).
• Налаштування person context та custom даних.
• Інтеграція deploy tracking у CI/CD (GitHub Actions, GitLab CI, Bitbucket Pipelines).
• Автоматичне завантаження source maps.
• Налаштування каналів сповіщень (Slack, PagerDuty, email, webhook).
• Документація з інтеграції та навчання команди (1 година).
• Технічна підтримка 2 тижні після впровадження.

Типові помилки при самостійному налаштуванні

• Не налаштований person context — помилки без інформації про користувача марні.
• Source maps не завантажені — у стеку видно лише мініфікований код.
• Фільтрація вимкнена — дашборд забитий шумом (404 тощо).
• Не підключений deploy tracking — неможливо визначити регресію.

Ми врахуємо все це за вас. Отримайте консультацію — почніть моніторинг без головного болю. Замовте інтеграцію Rollbar сьогодні і назавжди забудьте про сліпий пошук багів.

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