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).
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/heightandfetchpriority="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.
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).
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.
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.
window:28d metric:cls dimension:page×device cause:late_media,font_swap,widget_injection
Fix it (checklist)
- ✓ Reserve space: set explicit
width/heightor CSS aspect-ratio for images/video/slots. - ✓ Stabilize fonts: use
font-display: optional|swapand 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.
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)
- 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)
- 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)
- 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.
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
- ✓ Deploy the tag (prod & preprod), verify ingestion.
- ✓ Define page groups & segments (country/device/browser).
- ✓ Enable sourcemaps & releases to correlate errors/perf.
- ✓ Create dashboards: CWV Overview, Post-release, Slow Paths.
- ✓ Set SLOs & alerts (LCP/INP/CLS p75, errors/min).
Deployment — Browser Agent (Chrome/Edge)
- Distribution via GPO/Intune (scoped by BU/role).
- Collection: response time, errors, availability, adoption.
- Privacy: PII redaction, opt-in/opt-out, measured scopes.
- Analytics: latency by task, low-adoption profiles, hidden incidents.
IT readiness : whitelist endpoints, silent update policy, rollback channel.
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.
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.
Ekara can run in consent-aware mode: the tag listens to your CMP and activates collection only when the required purposes are granted. You may also run in a cookieless configuration to minimize identifiers.
<script
src="https://cdn.ekara.example/rum.min.js"
data-consent="auto" ></script>
Retention is configurable by plan and use case (e.g., 90–400 days for aggregates; shorter for raw events). Shorter retention can be applied to satisfy internal policies or regulatory constraints.
Choose EU-only processing or a Global footprint. Data is ingested via regional endpoints and stored in the selected region. For cross-border transfers, Standard Contractual Clauses (SCCs) are available as part of the DPA.
Ingest:
ingest.eu.ekara.exampleIngest:
ingest.global.ekara.exampleYes. Ekara supports search and deletion by pseudonymous identifiers you provide (e.g., hashed user IDs). We also support PII redaction at the edge to avoid storing personal data in the first place.
Yes. The extension measures application performance and adoption, not employee content. Measurement scopes are configurable by site/app; PII redaction and role-based access prevent over-collection.
Ekara can operate without cookies (session heuristics) or with a first-party, short-lived cookie to improve session accuracy—subject to consent where required.
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.
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.
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.
| 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 |
Low-traffic checkout
Critical checkout gets few visits at night.
- ✓ STM: run every 5 min from 3 regions.
- ✓ RUM: verify impact by device/ISP when users return.
Weekend release guard
You ship Friday night.
- ✓ STM: pre/post-release flows on staging & prod.
- ✓ RUM: segment real impact (p75) by browser version.
CDN or DNS incident
Intermittent spikes across regions/ISPs.
- ✓ STM: multi-location availability baselines.
- ✓ RUM: pinpoint affected geos and ISPs.
UX regression after deploy
CLS increase on a new template.
- ✓ RUM: p75 CLS trend by page group.
- ✓ STM: guardrail scripts to catch layout shifts early.
What do you need right now?
Do you have user traffic on the target flow?
Your immediate goal?
Environment to test?
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
—INP p75
—CLS p75
—JS errors
—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.
LCP p75
—INP p75
—CLS p75
—JS error rate
—Details
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
—
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
Modern digital monitoring requires far more than simple technical supervision: it demands a structured approach that integrates governance, automation, and...
In today’s fast-evolving digital world, companies face growing pressure to deliver software, applications, and websites faster, while ensuring their reliability...
Dans un contexte de transformation digitale accélérée, les entreprises font face à une complexité croissante de leurs systèmes d’information. Entre...
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 topWill 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 topWhat 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 topIs 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 topDoes 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 topHow 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 topHow 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.
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 topHow 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 topDo 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 topWhat 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 topDo 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 topHow 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 topHow 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 topGive 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.
Plateform
Services & Solutions
© 2025 Ekara by ip-label – All rights reserved
Legal Notice | Privacy Policy | Cookie Policy