Ekara tool

Real User Monitoring tool

Real User Monitoring (RUM) is the key to understanding your website and application’s true performance by capturing and analyzing every single user interaction in real time.

Unlike simulated tests, RUM shows you exactly how your service behaves across your users’ diverse devices, browsers, locations, and network conditions. Armed with this real-world data, you can identify points of friction, resolve errors faster, and make informed decisions to improve user satisfaction, boost conversions, and drive business growth.

Real User Monitoring (RUM) is a passive, front-end monitoring technique that captures field data from real visitors as they browse your website or web application. Unlike lab tools that simulate a page load once, RUM aggregates millions of real sessions to quantify experience for each device, browser, country, ISP, and network condition. The result is an objective view of Core Web Vitals and user-perceived performance at the 75th percentile (p75).

Definition

Real User Monitoring (often shortened to RUM) collects timing signals and errors directly from the end user’s browser. Data is sampled and anonymized according to your privacy policy, then aggregated to highlight trends, regressions, and outliers across segments that actually matter for your audience.

Why it matters

  • Business impact: faster pages correlate with higher conversion, better retention, and fewer support tickets.
  • Truth from the field: captures real device diversity, flaky networks, and third-party effects that lab tests miss.
  • Actionable prioritization: focus on the worst combinations (e.g., Safari on iOS over 4G in FR) instead of guesswork.
  • Release safety: quantify the before/after impact of each deployment on p75 LCP/INP/CLS.

What RUM measures

Core Web Vitals

LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift) — tracked at p75 per segment.

Loading & network

FCP, TTFB, resource waterfalls, slow third-parties, and CDN/DNS anomalies.

JavaScript & rendering

Long tasks, script execution delays, errors with stack traces (improved by source maps), and render bottlenecks.

Context & segmentation

Device, OS, browser & version, country/region, ISP/carrier, network type (3G/4G/5G/Wi-Fi), page group, release.

Field data vs. Lab data

Field (RUM)

  • Real users and real devices.
  • Measures variability (ISP, congestion, ad blockers, CPU contention).
  • Best for long-term quality, segment insights, and release verification.

Lab (synthetic or local)

  • Controlled environment with fixed network/device profiles.
  • Great for debugging and repeatability.
  • Best for pre-production and guardrails during CI/CD.

Most teams use both: synthetic monitoring for proactive detection, and RUM to understand real-world impact.

How RUM works (high level)

A lightweight, asynchronous JavaScript tag (or a Browser Agent extension when you don’t control the code) observes navigation and interaction events, applies privacy rules, and batches signals to a secure endpoint. The platform aggregates and indexes data by segment, computes p75 for Core Web Vitals, and correlates results with errors, resources, and releases to surface the most impactful issues.

See implementation details in How Ekara RUM works — Architecture & Collection.

When to use RUM

  • You ship often: verify each release didn’t degrade LCP/INP/CLS on key pages.
  • Global audience: prioritize fixes by geo/ISP where users actually feel the pain.
  • SPA frameworks: track soft navigations and interaction latency after hydration.
  • Third-party heavy stacks: identify slow ads, analytics, or widgets harming UX.

Key questions RUM answers

  • Which user segments are most affected by slowness? (by device, browser, country, ISP, network)
  • Did our latest release introduce a regression? (before/after p75 trend per page group)
  • What errors correlate with poor UX? (error groups & long tasks tied to INP/LCP)
  • Where should we invest first? (opportunities ranked by affected users & conversion impact)

Mini-glossary

p75
75th percentile — a robust threshold recommended for Core Web Vitals.
INP
Interaction to Next Paint — captures overall responsiveness to clicks, taps, and key presses.
Field data
Measurements collected from real users’ browsers in production.
Long task
JavaScript work (>50ms) blocking the main thread and harming interactivity.

RUM Tools to Observe, Understand, and Optimize Every User Experience

As work organizations evolve and the number of digital tools grows to support both centralized and decentralized models, it becomes increasingly critical to manage usage and understand the resources consumed.

Real User Monitoring (RUM) captures the experience of all users of your digital services, every time they interact with your web application or visit your website.

Who is Real User Monitoring for?

Product Managers & UX Designers

Track every user journey in real time to find friction points before they hurt KPIs. Validate design decisions with data, not guesswork.

Front-end developers

Pinpoint JavaScript errors, slow resources, and rendering bottlenecks in the wild. Get the telemetry you need to debug fast and ship performant front-ends.

IT & Operations Leaders

Gain a live view of service health and SLA compliance from the user’s perspective. Reduce MTTR and protect uptime with actionable performance intelligence.

Digital & Marketing Teams

See how every release impacts engagement, retention, and revenue. Align marketing, product, and engineering around the same real-world performance metrics.

Ekara Web RUM

Benefits of Ekara Web RUM (JavaScript-based)

Best for sites and applications where you have access to the code. By adding a simple JavaScript tag to your pages, Ekara Web RUM monitors all user activity on your public websites, intranets, or extranets. It provides a complete, user-centric view of performance.

Truly user-centered data

Measure the real experience of your site visitors across their actual devices, browsers, and networks.

Immediate impact detection

See in real time how new releases, code changes, or CDN issues affect real users.

Actionable error tracking

Capture JavaScript errors along with their context to speed up debugging and resolution.

Continuous improvement

Leverage real user metrics in design, development, and operations for iterative optimization.

Ekara Browser Agent RUM

Benefits of Ekara Browser Agent RUM

Designed to monitor the web tools you don’t control (e.g., Microsoft 365, Salesforce). When you can’t access the code, our solution uses a browser extension (Chrome/Edge). Deployed easily to your employees’ workstations, it captures critical performance metrics to ensure the productivity and quality of your digital workplace.

Real application coverage

Real application coverage

User behavior and adoption

Analyze tool usage, actual adoption, and real behavior by profile and role.

Usage aligned with IT decisions

Align investments and training with real usage, and adjust your strategies accordingly.

Digital friction & productivity impact

Identify slow pages, problematic interactions, and hidden incidents that affect comfort and workplace efficiency.

Ready to Try Ekara’s
Real User Monitoring Tools?

Experience how Ekara Web RUM and Ekara Browser Agent RUM can give you a complete spectrum of monitoring for your mission-critical websites and web applications.

How to use RUM data to improve Core Web Vitals (LCP, INP, CLS)

This playbook shows how to turn field data into wins for LCP, INP, and CLS. Start from the 75th percentile (p75) in Ekara RUM, slice by device, browser and country, then apply the fixes that move the needle for real users.

LCP — Largest Contentful Paint

Goal (p75): ≤ 2.5s. Typical blockers: heavy hero images, slow HTML/TTFB, render-blocking CSS/JS.

Find it in RUM

  • Open Core Web Vitals dashboard, set window to 28 days.
  • Filter by device: Mobile, then break down by country × ISP.
  • Drill into page group: Home / PDP / Checkout to locate slow templates.
  • Correlate with TTFB (backend/CDN) and resource waterfalls (hero, CSS, fonts).
Sample filter query
window:28d device:mobile dimension:country×isp page:Home,PDP,Checkout metric:lcp

Fix it (checklist)

  • Serve hero images in next-gen formats (AVIF/WebP) with correct width/height and fetchpriority="high".
  • Inline critical CSS; defer the rest. Avoid unused CSS (design system pruning).
  • Reduce TTFB: enable CDN caching, SSR/edge, and database query tuning.
  • Preload the LCP element’s resource (image/font) with accurate as/type.
  • Minimize render-blocking JS; load non-critical scripts with defer/async.

Release guardrails

  • Alert when LCP p75 degrades by > 10% on any key page group.
  • Track before/after per release; pin best LCP and compare regressions.
  • Watch out for template changes that shift image sizes or CSS order.
Before 3.6s
After 2.6s

INP — Interaction to Next Paint

Goal (p75): ≤ 200ms. Typical blockers: long tasks (>50ms), heavy hydration, synchronous listeners.

Find it in RUM

  • Switch to INP view; set segmentation by browser version and page group.
  • Open Long tasks tab and cross-filter by actions (click/tap) with high latency.
  • Check error groups that coincide with high INP (runtime exceptions = blocked main thread).
Sample filter query
window:28d metric:inp dimension:browser_version×page long_tasks:>50ms action:click,tap

Fix it (checklist)

  • Break up long tasks: code-split, lazy-load non-critical modules, defer work to idle.
  • Optimize hydration: islands/partial hydration; avoid heavy work on first interaction.
  • Make handlers fast: minimal sync work on click; schedule heavy logic via microtasks or Web Workers.
  • Reduce bundle size: treeshake, purge unused deps, ship modern builds (ESM).
  • Avoid layout thrash in handlers (measure → mutate patterns with batching).

Release guardrails

  • Alert when INP p75 increases by > 20% for any action.
  • Track interaction hotspots (search, add-to-cart, filters) across browsers.
  • Pin long-task outliers and link to the release that introduced them.
Before 300ms
After 190ms

CLS — Cumulative Layout Shift

Goal (p75): ≤ 0.10. Typical blockers: images without dimensions, font swaps, late ads/widgets.

Find it in RUM

  • Open CLS view; segment by page group and device.
  • Sort by worst pages; inspect late-loading components (ads, carousels, consent banners).
  • Check resource timings for images/fonts injected after first paint.
Sample filter query
window:28d metric:cls dimension:page×device cause:late_media,font_swap,widget_injection

Fix it (checklist)

  • Reserve space: set explicit width/height or CSS aspect-ratio for images/video/slots.
  • Stabilize fonts: use font-display: optional|swap and metrics-compatible fallbacks.
  • Delay non-critical DOM injections until after the first interaction (or reserve containers).
  • Avoid shifting sticky headers or banners on scroll; animate transforms, not layout.
  • Load ads in reserved boxes with known sizes; prevent reflow on refresh.

Release guardrails

  • Alert when CLS p75 crosses 0.10 on any template.
  • Watch for image template changes and font config regressions.
  • Keep a “no-shift” checklist for new components.
Before 0.16
After 0.09

RUM vs. Synthetic Monitoring (STM): The Winning Combination

While they sound similar, Real User Monitoring (RUM) and Synthetic Transaction Monitoring (STM) answer different but equally important questions.

RUM is reactive and broad:

It monitors real user traffic, giving you unparalleled insight into the diversity of user contexts. It tells you what is happening.


STM is proactive and deep

It uses robots to simulate critical user journeys 24/7, even when you have no traffic. It's perfect for detecting outages before your users do and validating SLAs. It tells you what could happen.

Using RUM in tandem with STM, as part of a [unified monitoring platform], provides a complete picture of your digital performance: the proactive baseline of STM enriched by the real-world context of RUM.

Customer Stories

Real User Monitoring in Action

A European luxury fashion group operating in China wanted to enhance its services by optimizing its public-facing website. Their goal was to guide decisions and focus efforts based on real user behavior, including user origins and access methods.

How RUM boosts customer loyalty and revenue

  • The Challenge: A European luxury fashion group in China wanted to optimize its public-facing website based on actual user behavior.

  • The Solution: Ekara RUM was implemented on all pages, creating a precise map of usage and page load times by geolocation, device type, ISP, and browser.

  • The Results: The large volume of data made it possible to focus development on key areas, which significantly improved the user experience and increased site loyalty, resulting in higher revenue.

How RUM Improves Point-of-Sale Efficiency

  • The Challenge: The finance division of a major car manufacturer needed to objectively assess dealer complaints about the slowness of their business-critical applications.

  • The Solution: Ekara RUM was deployed to collect performance data, revealing that the root cause was inadequate and unstable internet access at certain dealerships.

  • The Results: The dealerships concerned were advised to upgrade their infrastructure, which improved their access to commercial data, enhanced the customer experience, and eliminated order registration failures.

Metrics & Standards — Core Web Vitals (field data)

Ekara RUM measures Core Web Vitals using field data, aggregated at the 75th percentile (p75) by device, browser, country, and network conditions. The goal is to link UX and performance to guide product priorities.

LCP (Largest Contentful Paint)

p75 Target: ≤ 2.5s (Good) • 2.5–4s (Needs Improvement) • > 4s (Poor)

2.6s Needs Improvement
Segmentation
country, ISP, device, browser, page group
Collection
async JS tag, SPAs supported, configurable sampling

INP (Interaction to Next Paint)

p75 Target: ≤ 200ms (Good) • 200–500ms (Needs Improvement) • > 500ms (Poor)

240ms Needs Improvement
Sources
Event Timing, Long Tasks, layout/paint delays
Debug
correlates JS errors ↔ interaction latencies

CLS (Cumulative Layout Shift)

p75 Target: ≤ 0.10 (Good) • 0.10–0.25 (Needs Improvement) • > 0.25 (Poor)

0.12 Needs Improvement
Causes
images without dimensions, ads, webfonts, late injections
Remedies
space reservation, lazy-loading, font-fallback, priorities

How Ekara RUM works — Architecture & Collection

Ekara RUM collects field data via an asynchronous JavaScript tag or a Browser Agent (extension) for tools without code access. Events are aggregated by country, device, browser and displayed in dashboards correlating Core Web Vitals, JavaScript errors, slow resources, and deployed release versions.

Ekara Web RUM — Architecture Collection via JS tag, secure transport, aggregation pipeline, and display in dashboards and alerting. Browser (visitor) Async JS tag • SPAs Event/Resource/Long Tasks Sampling & consent Secure Ingestion TLS • compression • batching PII filtering & redaction CSP friendly Pipeline Parsing Aggregation Indexing Enrich. Metrics Storage & Analytics Time-series + index Segment: country/device/browser p75 • CWV • JS errors Dashboards & Alerting SLO • perf budgets LCP/INP/CLS alerts Release impact Collection & normalization CWV (LCP, INP, CLS), FCP, TTFB, long tasks Slow resources, JS errors, soft navigations (SPA) Consent, anonymization, sampling
Web RUM flow: browser → ingestion → pipeline → storage → dashboards/alerts.

Integration — asynchronous JavaScript tag

<!-- Ekara Web RUM (async, consent-aware) -->
<script
  src="https://cdn.ekara.example/rum.min.js"
  data-ekara-site-id="YOUR_SITE_ID"
  data-sampling="0.20"
  data-enable-cwv="true"
  data-spa="auto"
  data-consent="auto"
  defer></script>
data-ekara-site-id
Property identifier (environment: prod/stage).
data-sampling
Sampling rate (e.g., 0.2 = 20%).
data-enable-cwv
Collects LCP/INP/CLS & derivatives.
data-spa
Detects soft navigations (React/Next/Vue/Angular).
data-consent
Auto mode to respect user consent.

CSP : add the script domain & ingestion endpoints to the script-src and connect-src directives.

Overhead : deferred loading, negligible impact on CWV (minified size + idle execution).

Time-to-Value — 5 steps

  1. Deploy the tag (prod & preprod), verify ingestion.
  2. Define page groups & segments (country/device/browser).
  3. Enable sourcemaps & releases to correlate errors/perf.
  4. Create dashboards: CWV Overview, Post-release, Slow Paths.
  5. Set SLOs & alerts (LCP/INP/CLS p75, errors/min).

Privacy, Security & GDPR

Ekara RUM is designed with privacy by default and data minimization in mind. Collection is consent-aware, PII can be redacted at the source, and data residency can be confined to the EU.

GDPR-ready Consent-aware PII Redaction EU Data Residency

Ekara RUM does not require PII to operate. By default, we collect technical performance and UX events only. PII redaction rules (e.g., masking emails, order IDs) can be applied at capture time, and IP addresses can be truncated or dropped entirely.

Content-Security-Policy (CSP)

script-src 'self' https://cdn.ekara.example;
connect-src 'self' https://ingest.eu.ekara.example https://ingest.global.ekara.example;

Adjust endpoints to match your residency choice and environment.

RUM vs Synthetic Monitoring (STM) — Better Together

Real User Monitoring captures field data from actual users. Synthetic simulates critical journeys 24/7. Combine both to detect outages proactively and understand real-world impact across devices, browsers, geos and networks.

RUM

Real User Monitoring

Field data from real traffic (p75 by segment). Reactive — tells you what’s happening to users right now.

  • Primary purpose: Experience quality & performance in the wild (LCP/INP/CLS, FCP, TTFB, long tasks, JS errors).
  • Coverage: All users, all pages (subject to sampling/consent).
  • Strengths: Segmentation by device/browser/geo/network, release impact, correlation with errors/resources.
  • Limitations: Needs traffic; cannot run when a path has no visits.
See Core Web Vitals
STM

Synthetic Transaction Monitoring

Scripted checks from robots. Proactive — tells you what could happen across regions and schedules.

  • Primary purpose: Availability & speed of key journeys, SLA/SLO validation, early outage detection.
  • Coverage: Critical paths you choose (runs with zero user traffic).
  • Strengths: Deterministic, reproducible, runs nights/weekends, can hit staging/preprod.
  • Limitations: Limited context diversity vs. real users; risk of “green” while users struggle elsewhere.
See architecture
Dimension RUM STM
Detection style Reactive (actual users) Proactive (robots, schedules)
Traffic dependency Needs traffic (sampling optional) None (runs regardless of traffic)
Depth Real contexts (device, browser, geo, ISP, network) Scripted flows, controlled environment
Best for UX quality, release impact, segmentation, long-tail issues Outage detection, SLA, canary checks, staging/preprod
KPIs LCP / INP / CLS, FCP, TTFB, long tasks, JS errors Availability, step timings, response codes, SLA %
Weak spots No traffic → no signal Cannot reflect every real-world combination
Pricing driver Events / MAU / pages sampled Monitors × frequency × locations

Segmentation & Analyses

Slice real-user data by device, browser, country, ISP, network, and page group. Compare segments at the 75th percentile (p75) and correlate Core Web Vitals, errors, and TTFB to focus on impact.

LCP p75

s

INP p75

ms

CLS p75

JS errors

/k events

Top offenders by segment

Segment Value Weight Trend

Insight

Adjust filters or ask a question to get a narrative insight here.

Tip: Analyze p75 by country × ISP to detect provider-specific slowness, or by browser version to confirm a regression after a release. Segment Checkout vs PDP to tie performance to revenue.

Error & Release Monitoring

Track JavaScript errors, identify regressions per release, and correlate with LCP / INP / CLS. Source maps improve grouping and stack traces for faster debugging.

vs

LCP p75

Current s
Previous s

INP p75

Current ms
Previous ms

CLS p75

Current
Previous

JS error rate

Current /k events
Previous /k events

Details

Release — Page —
Select an error group from the table…

Stack trace

Source maps: —


            

Upload source maps to improve grouping and readable stack traces.

ekara-cli sourcemaps upload \
  --release 1.4.0 \
  --url-prefix "~/dist" \
  --include "./dist" \
  --strip-prefix "/usr/app"

Impact & correlation

LCP p75
INP p75
CLS p75
Affected users

Tip: Track releases automatically (CI/CD) and compare before/after p75 to catch regressions. Use error fingerprints plus source maps to keep groups stable across builds.

Check our ressources

  • All Posts
  • Blog
  • Uncategorized

Frequently Asked Questions — Real User Monitoring

Clear answers about RUM, Core Web Vitals, privacy/GDPR, SPAs, sampling, retention, alerts and more.

What is Real User Monitoring and how is it different from Synthetic?

RUM captures field data from real visitors to quantify experience by device, browser, country, ISP and network. It answers “what’s happening now”. Synthetic runs scripted journeys from robots on a schedule — “what could happen”. Use both: Synthetic for proactive detection & SLAs; RUM for real-world impact and prioritization. See RUM vs Synthetic.

Back to top

Will the Ekara RUM tag slow down my site?

The tag loads asynchronously, is deferred and non-blocking. Events are batched/compressed; sampling limits volume. RUM uses browser APIs (PerformanceObserver, etc.) with negligible impact and is designed not to harm Core Web Vitals.

Back to top

What data do you collect? Do you capture PII?

Ekara focuses on performance/UX signals: LCP/INP/CLS (p75), FCP, TTFB, long tasks, resource timings, JS errors (with source maps), plus context (device, OS, browser/version, country, ISP, network, page group, release). PII is not required. On-capture redaction, IP truncation and scoped collection are supported.

Back to top

Is Ekara RUM GDPR compliant? What about consent and EU residency?

Yes: consent-aware collection (CMP), data minimization, and PII redaction at the source. Choose EU-only or global processing/storage. Standard data-processing terms available. See Privacy, Security & GDPR.

Back to top

Does Ekara support SPAs and “soft navigations”?

Yes. Ekara detects client-side route changes (React, Vue, Angular, Next, etc.) and records soft navigations to measure LCP/INP/CLS after hydration, not only first load.

Back to top

How is INP measured in RUM?

INP replaced FID. Ekara uses event-timing to capture the worst interaction latency within a session and aggregates by segment at the 75th percentile. Long tasks and heavy handlers are surfaced for remediation.

Back to top

How do I deploy Ekara RUM? Any CSP requirements?

Add a lightweight JS tag (defer/async). For tools you don’t control, use the Browser Agent extension. With strict CSP, allow Ekara script-src and connect-src endpoints. See Architecture & Collection and CSP tips.

Back to top

Can I monitor native mobile apps?

Ekara RUM targets the web (desktop & mobile web). For native iOS/Android, leverage Synthetic Mobile to script and validate journeys on devices.

Back to top

How does sampling work?

Set a sample rate (e.g., 20%) to control volume while keeping statistical confidence. Adaptive strategies (boost during incidents or on key pages) maintain signal quality efficiently.

Back to top

Do you require cookies?

Ekara can run cookieless (session heuristics) or with a short-lived first-party cookie for better session accuracy — subject to consent where required.

Back to top

What are the data retention and residency options?

Configurable by plan/use case. Choose EU-only or global storage/processing. Shorter retention is available to meet internal policies. See residency controls in Privacy.

Back to top

Do you support alerts, SLOs and release comparisons?

Yes. Define threshold alerts on LCP/INP/CLS (p75) by page group/segment, track pre/post release impact, and set SLOs with dashboards & notifications. See Error & Release Monitoring.

Back to top

How do source maps improve error monitoring?

Source maps unlock readable stack traces and stable grouping across builds, speeding debugging and linking error spikes to releases and degraded Web Vitals.

Back to top

How is pricing structured?

Web RUM typically scales with event volume/MAU and features; the Browser Agent scales with seats/scope. Contact us to size sampling, retention and residency.

Back to top

Give your users the experience they deserve

Because just one bad digital experience is enough to drive a customer away, Ekara helps you ensure journeys that are smooth, high-performing, and always accessible.

ip-label, 90 Bd Nationale, 92250, La Garenne-Colombes

© 2025 Ekara by ip-label – All rights reserved

Legal Notice | Privacy Policy | Cookie Policy