Analytics consent: Implementation and evidence

Defines a versioned analytics-consent signal, enforcement before collection, withdrawal propagation, regional applicability, and evidence records without treating interface state as universal legal approval.

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

Resolve an applicable consent policy by region and purpose. Before optional analytics collection, require a current affirmative grant for that purpose; make refusal and withdrawal as operationally effective as acceptance and propagate changes to clients and downstream tools.

Scope

• Policy/version, purposes, notice, choice, storage, collection gating, withdrawal, proof, synchronization, downstream propagation, and regional configuration.
• Optional analytics processing where consent is the selected legal basis.
• Evidence of product behavior, not a legal certification.

Outside this block

• Determining whether consent is the correct basis in every jurisdiction or for every event.
• Claiming that consent retroactively erases lawfully retained aggregate or required security data.

Contract

• Consent is granular by named purpose and tied to notice/policy version, actor or pseudonymous device, decision, time, region policy, and collection context.
• Optional collectors remain disabled until a valid grant resolves; absence, parse failure, or unknown policy does not become consent.
• Reject and withdraw are available without deceptive extra steps and update the authoritative state immediately.
• Withdrawal stops future optional collection and emits a revocation event for downstream suppression/deletion workflows defined by policy.
• Servers enforce collection policy independently of client flags.
• Proof records contain the decision and presented policy identity while minimizing IP, user-agent, and unrelated behavioral data.

Implementation guidance

• Use a consent API and signed/versioned state that clients can cache briefly but refresh on policy change.
• Load optional analytics code only after the applicable decision where feasible.
• Map every analytics event to a purpose in an event registry and deny unknown purposes.
• Test with network inspection, not only UI toggles.

Failure handling and safeguards

• If region cannot be resolved under the configured policy, apply the conservative profile.
• If downstream revocation delivery fails, retry from an outbox and report propagation lag.
• If a new purpose or materially changed notice appears, collect a new decision rather than broadening an old grant.

Verification and operations

• Measure collection-before-grant violations, unknown-purpose events, decision rates, withdrawal propagation, policy-version coverage, and downstream suppression lag.
• Maintain browser and server integration tests for accept, reject, withdraw, expired state, and unavailable policy.
• Review applicability with qualified counsel before production use.

The executable-looking examples in this package are fixtures and acceptance contracts. Run python tools/validate.py from the collection root to check package structure and metadata; then implement and execute the scenarios in the target repository.

Adoption assumptions

• Names and numeric values in example.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• gdpr
• edpb-consent