Analytics sampling rate is intentionally configured
Why it matters
Session recording tools (PostHog, Hotjar, Microsoft Clarity) with no explicit sampling rate default to recording every session. On a medium-to-large project this creates unexpected data volume, processing costs, and storage costs that compound as traffic grows. From an iso-25010:2011 Performance efficiency perspective, unsampled session recording on high-traffic pages can also introduce measurable page weight from the recording SDK. This is an informational signal — default settings are not a crisis, but an intentional sampling configuration is a sign the project has thought through its analytics operational costs.
Severity rationale
Info because unsampled session recording creates cost and data-volume risk at scale but does not cause immediate user-facing or security harm on most projects.
Remediation
Set an explicit sample_rate in your session recording tool's initialization. For PostHog:
// posthog.init call — typically in app/layout.tsx or lib/analytics.ts
posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY!, {
api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
session_recording: {
sample_rate: 0.1, // Record 10% of sessions; adjust for traffic volume
},
})
For Hotjar, set the recording sample rate in the Hotjar dashboard under Settings → Recording. Review your analytics tool's pricing tier before going to production on a high-traffic site — most platforms charge by recorded session volume.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Analytics & Tracking Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · performance-efficiency — Resource utilisation sub-characteristic
Taxons
History
- 2026-04-18·v1.0.0·Initial import from marketing-analytics·automated