Page-view sampling

Page views are usually the bulk of a website’s monitored events, and often the least interesting. Page-view sampling lets a website property send page views from only a share of visitor sessions. Every other event, including purchases, leads, custom events and consent, is still sent 100% of the time.

Monita knows the rate each page ran with, so volumes, baselines and alerts show estimated totals. Turning sampling on, or changing the rate, never reads as a traffic drop.

Availability

Page-view sampling is enabled per organization by your Monita team, who will help you choose a rate. Contact support@getmonita.io or your account manager. Once it is enabled, org admins set the rate on each property.

How it works

• Decided per session. When a visit starts, it is either in the sample or out of it for the whole visit. Sessions in the sample send every page view, so paths through the site stay intact. Sessions out of the sample send no page views, but still send everything else.

• No new cookies or storage. The decision comes from the session identifier the Monita script already keeps for the visit. Nothing new is written to the visitor’s browser.

• Only real page views. Sampling applies only to these page-view events, sent to the vendors’ standard collection endpoints:

  Vendor	Page-view event
  Google Analytics 4	page_view
  Meta Pixel	PageView
  TikTok Pixel	Pageview
  Microsoft Advertising UET	pageLoad
  Snap Pixel	PAGE_VIEW

  Monita maintains this list. It can’t be extended to other events through property configuration or event templates. A request only counts as a page view when the vendor’s own request says so.

• Versioned like every other setting. The rate is saved with your signals: Save to dev, test, then Promote to prod. Rolling back to an earlier version restores the rate that version ran with. See Dev and prod script environments.

Choose a rate

Rate	Sessions sending page views	When to use it
No sampling (100%)	All	The default. Low-traffic sites, or when page-level detail matters most.
75%	3 in 4	A light trim with no practical loss of detail.
50%	1 in 2	High-traffic sites that want a meaningful volume reduction.
20%	1 in 5	Very high traffic, where page views dominate volume.
15%	About 1 in 7	Very low. Only for the busiest sites, agreed with your Monita team.

The property page shows, for each rate, how long it would take to confirm an outage on your page-view tags, based on your own recent page-view volume. On a busy site every rate keeps outage alerts as fast as unsampled monitoring. On a quieter site the lower rates slow them down.

What the lowest rates cost

At 15% and 20%, page-level views need far more traffic to be reliable. Quiet pages can show no page views for hours in Coverage and per-URL breakdowns. Outages on low-traffic page-view tags take longer to confirm, and partial drops on quiet pages may not be flagged. Journey rules that involve page views are judged on sampled sessions only, so they need proportionally more traffic for the same confidence. Conversions and other events are unaffected.

Set it up

1. Open the property at app.monita.ai/domains. On the Signals tab, find Page-view sampling.

2. Pick a rate. Check the outage-alert estimate under each option and, for 15%, read the risks panel.

3. Save to dev and install the dev script on a staging site if you want to check the behaviour first.

4. Promote to prod. The promote diff lists the sampling change alongside your signal changes. The property header shows page views sampled N% while production samples.

To switch sampling off, choose No sampling, save and promote. Any org admin can switch it off at any time, even if the feature is later withdrawn for the organization.

What you see in Monita

• Volumes, baselines and alerts use estimated totals: each page view received from a sampled session counts for the sessions it represents. Volume marks sampled signals ~est, and the anomaly chart tooltip shows both the estimate and what was received.
• Automatic alerts account for sampling. A sampled series is naturally noisier, so its normal range is wider, and a quiet stretch is only treated as an outage once enough sampled sessions should have arrived.
• Change verdicts compare estimated volumes, so a release that turns sampling on is judged as passed, not regressed. The Changes timeline notes the rate change.
• Custom volume alerts (thresholds and percentage changes) compare estimated totals.
• Data drift and consent coverage are measured over estimated traffic, so a rate change doesn’t read as parameters appearing or disappearing.
• Usage and billing count only the events Monita actually receives. Page views that weren’t sent are never billed.
• Realtime shows exactly what arrives, so out-of-sample sessions show no page views there.
• Session counts can read slightly lower. A visit whose only events were page views, and that fell outside the sample, sends nothing.

Check a page

In the browser console on any page running the Monita script:

Monita.sampling()
// → { rate: 20, pageViewsSent: false }

rate is the sampling rate this page’s script runs with (100 means off). pageViewsSent says whether this visit’s page views are being sent.