How to Test Consent Rejection, Withdrawal and Persistence

Why the distinction matters

Reject means choosing not to grant consent in a fresh session. Withdrawal means reversing a previously granted choice. Change preferences may also mean switching individual purposes while leaving others enabled. These are different user journeys and should be tested separately.

Under the GDPR consent framework, withdrawal must be as easy as giving consent. The EDPB explains this principle in its guidance, while actual legal application depends on the processing and the rules in scope. A clickable settings link is one part of the experience, not the entire test.

1. Test the first visit without making a choice

Use a fresh browser profile or a clean isolated context. Record the tested page, time, region, banner and preference categories. Observe the initial CMP state, Google consent defaults where configured, cookies and storage, and relevant network requests. Capture the order of initialization: a later correct state cannot undo an earlier transmission.

2. Choose Reject and inspect the result

Make a clear refusal choice, where available. Verify that the interface changes, the CMP records the intended preference, and relevant signals update. Then repeat page navigation and activities that would ordinarily trigger analytics or advertising. Compare request types and payloads rather than labeling every network call a violation. Essential functions or deliberately consent-aware pings may remain, depending on configuration.

3. Grant consent in a separate clean session

Do not reuse the rejected context for this comparison unless you intentionally test a preference change. Begin clean, accept the appropriate categories and document what changed. This establishes a controlled baseline for the next withdrawal test. With Google Consent Mode, check the expected parameters such as analytics_storage, ad_storage, ad_user_data and ad_personalization where those parameters are relevant.

4. Reopen settings and withdraw the choice

Use the site’s actual reopen control, often in a footer or floating privacy button. Confirm that it opens the intended settings interface, that the saved choice can be changed, and that the change is committed. Repeat the trigger actions from the accepted state and observe subsequent CMP state, Consent Mode updates and requests. Google’s documentation specifically describes updating consent from granted to denied; recording only the initial default is not enough.

5. Reload and check persistence

Reload the same page, follow an internal link and, where useful, open a new tab in the same browser context. Confirm the preference remains consistent and that the relevant initialization state is applied early enough. Repeated prompting or unexpected resetting can be a separate product issue. Also test a genuine new session if the project scope calls for it, distinguishing session-only choices from longer-lived storage.

6. Interpret unresolved evidence carefully

In advanced Google Consent Mode, some requests may be sent while consent signals are denied. That is different from assuming a full analytics event was collected under a granted state. A request’s mere presence, a tag library download or an unknown cookie name does not tell the full story. Where request bodies are opaque, traffic is truncated, geolocation cannot be verified or a CMP is inaccessible, mark the check as requiring investigation rather than passed or failed.

A concise QA handoff

For each finding, include the URL, browser/device, claimed and verified region, chosen categories, screenshot or event timeline, affected endpoint or tag, expected behavior, actual behavior and confidence level. Specify whether the concern was reproduced after Reject, after withdrawal, or only after reload. That is much more actionable for a developer than saying “the consent banner is broken.”