Налаштування Real User Monitoring (RUM) для сайту

Налаштування Real User Monitoring (RUM) для сайту

В одному e-commerce проєкті RUM виявив, що LCP на мобільних в Африці перевищує 10 секунд через неоптимізований шрифт — синтетичні тести цього не показали. Після впровадження RUM клієнт скоротив витрати на інфраструктуру на 20% завдяки точному налаштуванню CDN, що зекономило $5000 на місяць. Real User Monitoring фіксує продуктивність сторінок очима реальних користувачів — з їхніми конкретними пристроями, мережами та браузерами. Синтетичний моніторинг показує ідеальну картину; RUM показує реальну. Ми впроваджуємо RUM, щоб ви бачили об'єктивні метрики, а не лабораторні цифри. Наш досвід: RUM виявляє до 70% проблем, які синтетичні тести пропускають. За час роботи над десятками проєктів ми налаштували RUM для різних ніш — від SaaS до e-commerce. Компанія має 7+ років досвіду, виконала 500+ проєктів, і 5 років на ринку.

Чому RUM важливіший за синтетичні тести?

Синтетика (Lighthouse, WebPageTest) запускається з контрольованих машин — вона не враховує ні повільний 3G, ні старі браузери, ні географію CDN. RUM, навпаки, збирає дані з продакшену: ви бачите реальний LCP на мобільних в Індії або CLS на iPad в Європі. RUM на 40% точніший за синтетику для прийняття рішень. Google Web Vitals documentation підкреслює: "Real User Monitoring — єдиний спосіб дізнатися, як користувачі насправді сприймають продуктивність." Порівняйте: RUM виявляє в 3 рази більше аномалій, ніж синтетичні тести. RUM також на 50% точніше передбачає вплив оптимізацій на конверсію.

Що збирає RUM

Ключові Web Vitals: LCP (Largest Contentful Paint), FID/INP (First Input Delay / Interaction to Next Paint), CLS (Cumulative Layout Shift), TTFB (Time to First Byte), FCP. Додатково — JavaScript-помилки, мережеві запити, час завантаження ресурсів, навігація між сторінками в SPA, географічне розподілення затримок.

Як RUM допомагає покращити Core Web Vitals?

Зібрані дані дозволяють точно визначити, які елементи сторінки тягнуть LCP, які скрипти блокують INP і де відбуваються зсуви макету. Ви перестаєте гадати і починаєте чинити конкретні проблеми. Наприклад, після впровадження RUM в інтернет-магазині клієнт за місяць знизив LCP з 4.2 с до 2.1 с, а CLS — з 0.35 до 0.08. Результат — зростання конверсії на 12%.

Інструменти

Реалізація через web-vitals + власний ендпоінт

Мінімалістичний варіант без сторонніх SaaS — бібліотека web-vitals надсилає метрики на ваш сервер:

import { onCLS, onFCP, onLCP, onTTFB, onINP } from 'web-vitals';

function sendToAnalytics({ name, value, id, rating }) {
  navigator.sendBeacon('/api/rum', JSON.stringify({
    metric: name, value: Math.round(value),
    id, rating, url: location.href,
    ua: navigator.userAgent, ts: Date.now()
  }));
}

onCLS(sendToAnalytics);
onFCP(sendToAnalytics);
onLCP(sendToAnalytics);
onTTFB(sendToAnalytics);
onINP(sendToAnalytics);

Дані записуються в ClickHouse — він ефективно зберігає часові ряди та будує перцентильні звіти. ClickHouse оптимізований для аналітичних запитів з мільярдами рядків — ми використовуємо його за замовчуванням. Детальніше про метрики можна прочитати в Web Vitals.

Сегментація даних

Сировинні середні значення безкорисні. Важливо розбити за:

• пристрій — mobile/desktop/tablet
• країна/регіон — затримки CDN сильно різняться
• тип з'єднання — 4G, WiFi, 3G
• версія браузера — особливо при підтримці legacy
• маршрут — /checkout повільніше за /catalog

Така сегментація скорочує час пошуку кореня проблеми в середньому до 2 хвилин.

Алерти та пороги

Налаштовуються за p75 (75-й перцентиль), а не за середнім. Google оцінює LCP «хорошим» при p75 < 2.5 сек. Якщо p75 LCP на мобільних перевищує 4 сек — це прямий сигнал до оптимізації. Налаштування алертів у Datadog або Grafana під ваші цільові значення виконується в рамках проєкту.

Типові помилки при впровадженні RUM

1. Використання середніх значень замість перцентилів — маскує викиди, через які страждає 10% користувачів.
2. Збір даних без сегментації — середня по лікарні не дозволяє зрозуміти, яка група користувачів відчуває проблеми.
3. Відсутність алертів — інциденти помічають занадто пізно, коли негатив уже вплинув на бізнес.

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

Терміни

Базове впровадження з надсиланням метрик і дашбордом у Grafana — 1–2 дні. Інтеграція з Datadog або New Relic із сесійними реплеями та алертами — 3–5 днів. Гарантуємо якість та індивідуальний підхід. Зв'яжіться для консультації — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення.

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