Privacy

Cookie Consent and Revenue Analytics Coverage

A plain-language explanation of what analytics can and cannot connect before and after a visitor grants cookie consent.

Last updated: August 18, 2026

How does cookie consent affect analytics?

When a site requires consent before persistent analytics storage, tracking can either wait completely or operate with reduced, temporary identity. RevenueUI supports a consent-required mode that avoids first-party cookies until consent is granted and uses a tab-scoped session before that point.

This is a product behavior, not legal advice. The website operator decides whether consent is required, how consent is collected, and which disclosures apply.

Before and after consent

CapabilityBefore consent in consent-required modeAfter consent is granted
Persistent first-party visitor cookieNoAvailable
Tab-scoped sessionYesSession identifiers can persist as configured
Same-tab page journeyAvailableAvailable
Returning-visitor analysisNot availableAvailable while identifiers are retained
Cross-visit attributionLimitedAvailable when the same visitor ID is present

The important distinction is not simply “tracking on” or “tracking off.” Identity persistence determines which events can be connected across pages, tabs, and later visits.

Consent changes measurement coverage

If a large share of visitors does not grant consent, persistent-identity reports represent a subset of traffic. Aggregate page activity may still be available under the selected setup, but returning-visitor counts and cross-visit journeys will be incomplete.

Do not estimate missing attributed revenue by assuming non-consenting visitors behave exactly like consenting visitors. Consent rates can differ by geography, device, acquisition source, and audience familiarity.

Integrate the consent signal explicitly

A robust integration has clear states:

  1. Load RevenueUI in consent-required mode.
  2. Record no persistent analytics cookie before a grant.
  3. Notify the tracker when the consent manager reports a grant.
  4. Include the consent source and observation time with granted events.
  5. Handle withdrawal by returning to the non-persistent behavior your policy requires.
  6. Re-test after changing the consent manager or tag-loading order.

Avoid labeling the entire product “cookieless” when it can use cookies after consent. Describe the actual state: consent-required, temporary before consent, and persistent only after a grant.

What to monitor

  • Event volume before and after the consent prompt changes.
  • The proportion of first-party and non-persistent identity modes.
  • Attribution coverage by device and acquisition source.
  • Missing checkout identifiers after releases.
  • Whether consent metadata appears only for granted events.

These checks reveal measurement changes without treating consent itself as a conversion optimization target.

Related guides

Privacy-aware measurement is most credible when the interface explains the unavailable capabilities instead of pretending the dataset is complete.