Настройка Real User Monitoring (RUM) для сайта

Настройка Real User Monitoring (RUM) для сайта

В одном из e-commerce проектов RUM выявил, что LCP на мобильных в Африке превышает 10 секунд из-за неоптимизированного шрифта — синтетические тесты этого не показали. После внедрения RUM клиент сократил расходы на инфраструктуру на 20% за счёт точной настройки CDN. Real User Monitoring фиксирует производительность страниц глазами реальных пользователей — с их конкретными устройствами, сетями и браузерами. Синтетический мониторинг показывает идеальную картину; RUM показывает реальную. Мы внедряем RUM, чтобы вы видели объективные метрики, а не лабораторные цифры. Наш опыт: RUM выявляет до 70% проблем, которые синтетические тесты пропускают. За время работы над десятками проектов мы настроили RUM для разных ниш — от SaaS до e-commerce.

Почему RUM важнее синтетических тестов?

Синтетика (Lighthouse, WebPageTest) запускается с контролируемых машин — она не учитывает ни медленный 3G, ни старые браузеры, ни географию CDN. RUM, напротив, собирает данные с продакшена: вы видите реальный LCP на мобильных в Индии или CLS на iPad в Европе. Это даёт на 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 дней. Закажите настройку RUM у нас — получите объективную картину производительности уже на следующей неделе. Свяжитесь для консультации — мы оценим ваш проект и предложим оптимальное решение.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 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: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-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 день)

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.