Real User Monitoring

Что измеряет RUM

Real User Monitoring (RUM) собирает данные о фактических взаимодействиях пользователей с сайтом или приложением: загрузку страниц, ошибки, действия, задержки и сессии на разных устройствах и сетях.

В отличие от синтетического uptime, RUM показывает реальное разнообразие браузеров, географии и поведения. Синтетика даёт контролируемую проверку, RUM — фактический пользовательский опыт; один не заменяет другой.

Web Vitals

Для пользовательского опыта загрузки и взаимодействия используют Core Web Vitals:

• LCP — Largest Contentful Paint — скорость появления основного содержимого;
• INP — Interaction to Next Paint — отзывчивость страницы на взаимодействия;
• CLS — Cumulative Layout Shift — визуальная стабильность макета.

Метрики анализируют распределением по страницам и сегментам, а не только общим средним. Полезны разбивки по URL, типу устройства, браузеру, региону и release. RUM дополняет лабораторные Lighthouse-замеры реальными условиями.

События и funnels

Автоматический или явный сбор событий описывает клики, отправку форм, переходы и пользовательские действия. Funnel показывает, на каком шаге ключевого сценария пользователи прекращают путь:

Открытие формы → начало ввода → отправка → успешный результат

RUM не должен подменять продуктовую аналитику без согласованной модели событий. Для надёжного анализа определяют названия, обязательные свойства, дедупликацию и связь frontend-события с серверным результатом.

Session replay

Session replay восстанавливает взаимодействие с интерфейсом и помогает увидеть, где пользователь столкнулся с ошибкой, непонятным состоянием или повторными кликами. Это не обычная видеозапись экрана: обычно сохраняются изменения DOM и события, которые затем воспроизводятся.

Replay наиболее полезен в связке с frontend error, backend trace и release. Но он требует самых строгих правил приватности.

Приватность

До включения сбора необходимо определить:

• правовое основание и информирование пользователей;
• запрет захвата паролей, платёжных данных, содержимого форм и секретов;
• маскирование элементов по умолчанию, а не только выборочно;
• срок хранения и регион обработки;
• доступ к replay и событиям;
• поведение при отказе пользователя от сбора.

Не следует полагаться на то, что CSS-маскирование скроет данные, если исходное значение уже отправлено в payload.

Связь frontend и backend

Общий trace/request ID позволяет перейти от медленной страницы или frontend error к серверному вызову. Это помогает отличить проблему сети и браузера от задержки backend, очереди или базы данных.

Минимальный сценарий внедрения: выбрать ключевую страницу, включить Web Vitals и frontend errors, проверить отсутствие чувствительных данных, затем добавить события и backend correlation. Session replay включают после отдельной проверки приватности.

Связанные инструменты

• Better Stack — Web Vitals, события, replay и корреляция сигналов.
• Sentry — frontend errors и данные производительности.
• Grafana — визуализация пользовательской и системной телеметрии.

Связанные материалы

• Error tracking — frontend и backend исключения.
• Uptime monitoring — контролируемые синтетические сценарии.
• SLI, SLO и SLA — пользовательские индикаторы качества.
• Оптимизация производительности сайта — устранение найденных узких мест.

Материалы и источники

• web.dev: Web Vitals — LCP, INP, CLS и измерение реального опыта.
• Better Stack: Real user monitoring — пример replay, событий и frontend/backend корреляции.
• OpenTelemetry: Browser instrumentation — телеметрия браузерных приложений.