Accept vs Reject: Why Your Banner Might Set the Same Cookies (Banner Parity)

What Is Banner Parity?

Banner parity means that "Accept" and "Reject" produce different outcomes. When a user accepts, non-essential cookies and tracking should be allowed. When a user rejects, non-essential cookies and tracking should be blocked. If both actions result in the same cookies and the same network requests, there is no real choice - and no valid consent.

Common parity failures we see:

• Same cookies for both: Accept and Reject both set the same non-essential cookies (e.g. analytics, advertising).
• Accept doesn't enable tracking: User clicks Accept but Consent Mode is never updated to "granted," so Google tags stay in denied/default state and conversions don't fire.
• Reject doesn't block: User clicks Reject but tracking scripts and cookies are already set or continue to fire.
• Banner only hides: Both buttons just dismiss the banner; neither triggers different cookie or script behavior.

In all these cases, the banner is cosmetic. The user's choice doesn't change what the site does - which violates the principle of consent and breaks measurement when "Accept" never actually enables conversion tracking.

Why Banner Parity Breaks Compliance and Conversions

From a legal and technical standpoint, parity failures cause two big problems.

Compliance: GDPR, CCPA, and similar laws require that users can refuse non-essential tracking and that their choice has effect. If Reject doesn't block tracking, or if Accept and Reject do the same thing, the consent mechanism is invalid. Regulators and auditors look for this.

Conversions: If Accept doesn't update Consent Mode (e.g. ad_storage / analytics_storage to "granted") or doesn't allow tracking scripts to run, conversion events never reach Google Ads. So even when users consent, you get no attributed conversions - and the report may show "no conversion observed after accept," which our scan flags. Fixing parity (and ensuring Accept actually enables tracking) is required for conversion tracking to work. For more on consent state updates, see consent state not updating.

How to Fix Banner Parity

Parity is fixed in your CMP and tag setup, not in copy or design alone.

• Accept: When the user clicks Accept, your CMP must call Consent Mode update with ad_storage and analytics_storage (and other consent types) set to "granted". Non-essential cookies may be set at this point, and tracking scripts may load or resume.
• Reject: When the user clicks Reject, do not set the same non-essential cookies. Keep Consent Mode as "denied" (or update explicitly to "denied"). Ensure tracking scripts do not fire (or remain blocked) for non-essential purposes.
• Different cookie sets: Your CMP or backend should define separate behavior: e.g. "essential only" on Reject, "essential + analytics + ads" on Accept. Same cookie list for both = parity failure.
• Order of execution: Default consent should be denied before any tags run; then Accept updates consent and allows tags. See gtag consent default denied for implementation.

After changes, test in an incognito window: click Reject and check that no (or minimal) tracking cookies/requests appear; then reload, click Accept, and confirm that new cookies and tracking requests appear. Our scan does this automatically and reports "Banner parity" pass or fail.

How We Detect Banner Parity in the Scan

The scan runs three flows: first visit (before interaction), reject, and accept. It compares cookies and (where possible) tracking-related requests after Reject vs after Accept. If the set of cookies (or key identifiers) is the same in both cases, or if after Accept we don't see consent-related updates and tracking, we report a banner parity issue. We also check that Consent Mode is updated when the user accepts; if it isn't, that's part of the same problem - Accept isn't doing what it should.

For full methodology, see how the consent scan works.

Related resources:

• Cookie Banner Not Blocking Tracking →
• Consent State Not Updating →
• gtag Consent Default Denied →

FAQ

What is banner parity?

Banner parity means Accept and Reject produce different outcomes: Accept enables non-essential cookies and tracking; Reject blocks them. If both actions set the same cookies or fire the same tracking, there is no real choice and no valid consent.

Why does banner parity matter for Google Ads?

If Accept does not update Consent Mode or load tracking scripts, conversion data may never flow to Google. Reject and Accept would behave the same from Google's perspective, breaking measurement.

How do I check if my banner has a parity problem?

Run a browser-based scan that simulates Accept and Reject and checks whether cookies and network requests differ. Our free scan does this and reports if Accept and Reject set the same cookies or tracking.

Is banner parity a legal requirement?

Regulators expect a real choice: Accept must enable what Reject blocks. If both do the same thing, consent is meaningless and you may be non-compliant with GDPR or ePrivacy.