How to test what fires before consent

A consent banner is meant to hold tracking back until the visitor chooses. Whether it does on a given site depends on the banner's settings, on how each tag was added to the page, and on what else the page loads. The only way to know is to look at what the browser actually sends. This guide describes the method we use in our own measurements, in a form you can repeat by hand on a site you control with nothing more than a browser.

The four scenarios

Test each scenario in a fresh browser profile, so no earlier consent choice or cookie is carried over.

1. First load, no interaction. Open the page and do nothing. Everything the page sends while the banner is still open happened before any choice.
2. Reject all, then a second page. Click the banner's reject option, then open a second page of the same site. Activity on the second page is what happens after a refusal.
3. Accept all, then a second page. The same, with the accept option. This is your positive control: it shows which tags are on the page at all and that they work once allowed.
4. Return visit after a reject. In the profile where you rejected, close the tab and open the site again. The banner should stay closed and the stored choice should still read as a refusal.

Scenarios 2 and 3 start with the same first page load as scenario 1. What you see before the click in those scenarios is the same observation as scenario 1, not a separate result.

Before you start

• Use a desktop browser with developer tools (the steps below use Chrome; Firefox and Edge are similar).
• Turn off ad and tracker blocking extensions for the test, or use a profile without extensions. A blocker hides exactly the requests you want to see.
• Write down the date, the browser version, the country you are testing from and the page address. Consent banners often behave differently by country.
• Know which tags the site is supposed to load (analytics, ads, pixels, embedded video) and how each one was added: hardcoded in the theme, through a tag manager, or by a plugin. In our own lab, how a tag reached the page decided whether the banner could hold it back.

Walkthrough in Chrome DevTools

Scenario 1: first load

1. Open a new incognito window (a fresh profile with no stored cookies).
2. Open DevTools (F12, or Ctrl+Shift+I / Cmd+Option+I) and go to the Network tab. Tick Preserve log and Disable cache.
3. Type the page address and load it. Do not touch the banner.
4. Wait until the page has settled (10 to 15 seconds is usually enough; some tags fire late).
5. In the Network filter box, look for the third-party services you expect, for example google-analytics.com, googletagmanager.com, doubleclick.net, facebook.com/tr or connect.facebook.net. Click a request to see its full address and payload.
6. Go to Application > Storage > Cookies and Local storage. Note the names that appeared, for example _ga, _gcl_au or _fbp. Write down names only; you do not need the values.
7. Save the evidence: right-click in the request list and choose Save all as HAR, and take a screenshot with the banner visible.

Scenario 2: reject all, then a second page

1. Start again in a new incognito window with DevTools open, as above.
2. Load the page, then click the reject option. Note the time.
3. Check that the click took effect: the banner closed, and the consent tool's own cookie or local-storage entry changed to a refusal. A click that did not register is a failed test, not a result.
4. Open a second page of the site and let it settle. Look for the same services as in scenario 1.

Scenario 3: accept all, then a second page

Repeat scenario 2 with the accept option. Expect the site's tags to load now; if nothing loads even after accepting, check the tag setup before reading anything into scenarios 1 and 2.

Scenario 4: return visit after a reject

Use the incognito window from scenario 2, close the site's tab and open the site again in the same window. The banner should stay closed, and the stored choice should still read as a refusal.

How to read what you see

• Count requests to known tracker endpoints, not every third-party request. We match requests against a pinned version of the EasyPrivacy list plus a short list of documented endpoints for the tags we test. Fonts, maps or a content delivery network are not trackers in this sense.
• A script download is not the same as a tracking hit. The browser fetching a tag library (for example gtag/js) is not a measurement hit, although like any request it shows the host the visitor's IP address, browser and usually the page address. The beacons that follow (a collect request, a pixel, a tr request) do. We record plain script downloads separately; a script request that carries an identifier or a body goes through the normal list matching.
• Separate Consent Mode pings. With Google Consent Mode, a Google request can be sent while signalling that storage is denied. We count those separately and never as a tracker request. See Consent Mode pings vs trackers.
• Leave the consent tool's own logging out. Many consent tools record the visitor's choice on their own servers. That request is consent logging, not tracking.
• Ignore the moment of the click. Requests within a fraction of a second of the click cannot be placed reliably before or after it. Our harness treats anything within 300 ms of the click as ambiguous and counts it on neither side.

Repeat it before you rely on it

One page load is an anecdote. Our rule for a counted result is: seen in at least 2 of 3 runs, on at least 2 different days, with the network capture, a screenshot and the list versions kept for every supporting run. A single observation below that rule is noted, never reported as a finding. For a site you manage, three runs of each scenario on two days is a good habit, and the HAR files let someone else check your reading.

"Nothing observed" is not proof that a tag is blocked: the tag may not have fired in that window, or may only fire on other pages or after scrolling. Say what you saw, when, and under which conditions.

What this method does not tell you

• Whether the site is lawful. A request shows that data left the browser; whether consent was needed for it, and whether the banner's design is acceptable, are legal questions this test does not answer.
• What a request is used for. Domains and names alone do not establish purpose.
• How other visitors see the site. Results can change with country, browser, device, the visitor's earlier choices and the site's own updates.