Analytics consent is often implemented as a banner over an unchanged page. The message asks for permission, but the application has already downloaded a tracker, created identifiers, or started collection. A real consent boundary must control execution, not only presentation.
Start with a denied default
The page must behave as if the visitor rejected optional analytics until the visitor explicitly accepts it. This makes the undecided state safe by construction. The public content, navigation, and core functionality must remain available in that state.
On this site, one client component owns the decision. It reads a versioned consent record from browser storage after mount. Before that read completes, no analytics runtime is rendered. A rejected record keeps the runtime absent. An accepted record permits the application to request it.
Defer the code as well as the component
A conditional render does not always defer a package. A static import can place an optional analytics SDK in the initial client graph even when React returns null. The stronger boundary uses a dynamic import that is requested only after acceptance.
That distinction matters for privacy and performance. An undecided visitor should not pay the network, parse, or evaluation cost for optional tooling. A rejected visitor should never need that code.
Centralize provider behavior
Multiple analytics providers create drift when each one reads consent independently. One provider may start early. Another may fail to stop after withdrawal. Public privacy copy may describe behavior that the implementation does not support.
The site therefore has one analytics boundary and one normalized consent record. That boundary activates Microsoft Clarity, Google Analytics, Vercel Analytics, and Speed Insights. Provider-specific code remains inside the runtime layer.
Withdrawal is equally important. Services that support a denied consent signal receive it. Components without that signal are removed from the page. The application then reloads in the rejected state so optional collection does not resume.
Version the decision
A stored boolean cannot explain which terms a visitor accepted. The record should include at least the decision, a consent version, and a timestamp. When the terms change, the application can treat an older version as undecided and request a new choice.
The timestamp is not a server audit log. It is a local record that helps the site apply the visitor's choice consistently. The privacy notice should say where it is stored and what it does.
Keep deployment context explicit
Local development and preview deployments do not need production analytics. Disabling collection in those environments prevents test traffic, avoids accidental tracking, and keeps preview URLs outside analytics reports.
This site enables the analytics configuration only on the Vercel production deployment. Preview pages also send noindex controls. Consent remains necessary in production.
Test the boundary, not only the banner
The useful checks are observable:
- No optional analytics request occurs before a decision.
- Rejecting consent leaves the site fully usable.
- Accepting consent loads each approved provider.
- Withdrawing consent removes optional runtimes and preserves the rejected record.
- An older consent version causes a new prompt.
- Public privacy copy matches actual provider behavior.
The banner is the visible part. The execution boundary is the privacy feature.