How to investigate tracking before and after a consent choice

A cookie banner can look correct while the underlying tracking behavior tells a different story. The useful question is not just “Did the visitor see a banner?” but “What did the browser do before and after the visitor made a choice?”

This article walks through a practical way to investigate that question using browser observations. The goal is to collect evidence for review, not to turn a network log into a legal verdict.

Start with three separate observations

Test the same page in three distinct states:

1. Before interaction: load the page without clicking the banner.
2. After rejection: start a fresh session, reject optional cookies and observe what happens.
3. After acceptance: start another fresh session, accept and observe what changes.

Separate sessions matter because cookies, local storage and consent decisions from an earlier visit can affect a later test. A comparison is only useful if you record which state produced each observation.

Also record situations where the intended state could not be reached. If the banner did not appear, the reject button could not be clicked, or the page timed out, mark that flow as unknown or failed. Do not treat it as a successful rejection test.

Inspect the browser, not just the banner

For each state, capture enough context to answer what happened:

• The page URL and time of the observation.
• Requests made to third-party domains.
• Cookies and relevant browser storage created or changed.
• The consent choice attempted and whether the interaction succeeded.
• The script or request initiator, when available.

Browser DevTools can help. Open the Network panel before loading the page, preserve the log across navigation if needed, and inspect requests after each action. Use the Application or Storage panel to compare cookies and local storage between sessions.

Be careful with sensitive values. For a first investigation, a cookie name, domain, purpose and timestamp may be more useful than copying its raw value into a report.

Compare what changed

Build a small comparison table for the requests and storage you observed:

This is an example, not a conclusion about any particular website. “Not observed” means the item did not appear during this test; it does not prove that it can never occur.

If an analytics request appears before a choice or after rejection, investigate its purpose and configuration. Some requests may be necessary for a service or may operate without cookies. A domain name alone does not establish whether a request is unlawful.

Useful follow-up questions include:

• Which script initiated the request?
• Did it send or set a cookie?
• Did the request occur before the consent-management platform loaded?
• Did the consent state update after the click?
• Can the behavior be reproduced in a fresh session?

Check the consent signal as well as the request

A consent-management platform may update a signal correctly while a tag ignores it. The reverse can happen too: a request may be blocked even though the consent state is unclear.

When relevant, inspect both sides:

• What consent state did the page or consent platform expose?
• Which tags or vendor requests were actually observed?
• Did either change after rejection or acceptance?

For Google Consent Mode, inspect the relevant consent defaults and updates alongside observed tag behavior. Avoid assuming that seeing a request by itself tells you the complete consent or legal context.

Watch for incomplete tests

Automated and manual checks have limits. A banner can vary by region, device, prior choice or page. A slow script may fire after the observation window. An interaction can fail because a button moved or was covered by another element.

Keep those limits with the result. A useful finding might say:

A request to an analytics domain was observed before any banner interaction during this test. Review the request purpose and consent configuration.

That gives the team a specific next action without claiming more than the evidence shows.

Automating the comparison

For recurring checks, the same process can be automated: open isolated browser sessions, attempt each consent flow, capture the resulting requests and storage, and retain the outcome of each interaction.

CookieRisk is one tool for investigating these flows. Its Quick Scan examines a site before banner interaction, and its Deep Scan compares observations across baseline, reject and accept flows. Results should still be reviewed in context; a scan does not replace legal advice.

Whether you use DevTools or a scanner, the important part is keeping the evidence and the consent state together. That makes a finding easier to reproduce, explain and investigate.