Clarity free-tier sampling bias when 100k session cap is reached mid-month

The short answer

Microsoft has not published a specification for how Clarity's free-tier sampling behaves after the 100,000-session monthly cap is reached. Based on available documentation and observed behavior, sampling appears to be applied as a probabilistic filter rather than a hard cutoff, but whether it is uniform across traffic sources or weighted toward recent sessions is undocumented. Treat any trend analysis drawn from a capped period as provisional until you can validate it against an independent traffic source.

Separating confirmed facts from assumptions

Reasonably established

• The free tier caps session recordings at 100,000 per project per month; there is no paid tier to raise it.
• Once the cap is approached, a sampling percentage appears in the dashboard, and session replay coverage becomes incomplete.
• Heatmaps continue to aggregate across recorded sessions, and heatmap data is retained far longer (around 12 months) than the roughly 30-day replay retention.
• There is no SLA or export guarantee, so behavior can change without notice.

Unverified and flagged for review

• Whether sampling is uniform across all sessions or recency-biased. Nothing official confirms either model. A plausible implementation is a per-session coin flip at a fixed rate, which would be approximately uniform, but this is inference, not documentation.
• Whether the dashboard percentage is computed against total incoming sessions or against the sampled subset. If it is derived from the subset, it cannot be used to back-calculate true traffic volume.

Practical steps for this case

1. Anchor trends to an independent source. Compare Clarity session counts against your server logs, CDN analytics, or another analytics tool for the same period. If Clarity's daily curve diverges only after the cap date, that divergence is a sampling artifact, not a traffic change.
2. Record the cap date. Note the day the sampling indicator first appears each month. Treat all replay-based analysis before that date as full-coverage and everything after as sampled.
3. Prefer heatmaps over replays in capped periods. Since heatmap aggregation continues across recorded sessions, aggregate behavioral signals (clicks, scroll depth) are more reliable than replay counts once sampling starts.
4. Segment projects if traffic is concentrated. Splitting high-traffic properties into separate Clarity projects gives each its own 100k budget, which delays or avoids capping. Verify this is acceptable for your setup before relying on it.
5. Ask Microsoft directly. A support request asking for the sampling algorithm description is the only authoritative path; the behavior is otherwise undocumented.

One diagnostic detail that changes the recommendation

Does your dashboard percentage move smoothly through the month or jump abruptly at the cap? A smooth ramp suggests rate-based probabilistic sampling (likely closer to uniform); an abrupt jump suggests a threshold switch, which would make pre-cap data complete and post-cap data a fixed-rate sample. If you can share that observation, the trend-correction approach above can be narrowed down. Until Microsoft documents the algorithm, the safest posture is: full-coverage analysis before the cap date, corroborated analysis only after it.