Skip to content
DocsGo to Dashboard
Monitor real users with RUM

Field collection is switched on from `Lab vs real-user`; there is no SDK install screen, and collection stays dormant until consent

There is no install screen, no script tag to paste, and no package to add to your site. Real-user collection is a per-domain switch on the Lab vs real-user screen. The collector itself is injected into eligible proxied HTML responses at the edge, and it does nothing at all until a visitor consents.

Lab versus real-user performance panel showing the field collection notice and the enable or disable control
Collection is a switch, not an install step — and the collector stays dormant until a visitor consents.

1. Open the comparison#

Choose Analytics in the sidebar, then Lab vs real-user in the Analytics sections control. The panel is titled Lab versus real-user performance, its eyebrow reports the field window in days, and with no domain selected it reads Select a domain to compare laboratory measurements with consented real-user field data. Pick a hostname in the top bar's Filter by domain select and the panel fills in.

2. Read the collection notice#

The first block in the panel is the collection state. While collection is off it reads Field collection is disabled and names the three consent signals Weboptiva accepts: your consent manager setting window.weboptivaRumConsent, setting the consent cookie weboptiva_rum_consent=granted, or dispatching the weboptiva:rum-consent event. That is the whole integration contract — nothing else has to be deployed on your site.

3. Enable collection#

Press Enable consented field collection in the panel header. While the change saves the button reads Saving…; then it flips to Disable field collection and the notice becomes Field collection is enabled, reporting the SDK version, the sample rate as a percentage, the retention window in days, and the daily cap on accepted events. Those are the domain's own settings, so the screen reports them rather than editing them here.

The notice states that the collector remains dormant until explicit visitor consent, and the injected script enforces that twice over. It refuses to start when Global Privacy Control is on, when Do Not Track is set, when it detects automation or a bot user agent, and when the URL carries a query string or a sensitive path such as an account or checkout route. It also re-checks consent before every send, so revoking consent stops collection immediately. To confirm injection end to end, load a proxied page and look for the x-weboptiva-rum: applied;consent=explicit response header; a skipped injection explains itself in that same header with a reason. The collector script itself is served from /.well-known/weboptiva/rum/v1.1.js and posts to /.well-known/weboptiva/rum.

Expected result#

Collection is on for that domain, the notice reports its sampling and retention settings, and field samples begin to appear once real consented visitors load your pages. Without consent the report stays empty however long you wait — that is the intended behaviour, not a fault.

Two limits are worth knowing. Sampling and the daily event budget mean the report describes a fraction of visitors rather than all of them, so treat small differences as noise. And the daily cap is hard: once it is reached, further samples are refused for that day rather than queued.

Back to Monitor real users with RUM