A consent banner appearing on a page gives me one piece of evidence: the banner is visible. I still need to check what the tracking code did before it appeared, after a choice was made and on the next page.
I test the loading order, consent state and expected events together. The checks need to cover a fresh visitor, a saved choice and a change of choice, because one successful visit after accepting everything can hide problems in the other routes.
Write down the expected sequence
I start with a simple list: the default consent state, the visitor’s choice, the update sent to the tracking system and the events expected at each stage. The site’s agreed consent approach determines that behaviour.
For Google tags, the consent-mode guidance explains setting defaults before commands that send measurement data and updating the state when the visitor makes a choice. Those updates also need to happen on the page where the choice occurs, before navigation interrupts the sequence.
I give each integration a clear owner. If a plugin, a theme snippet and a tag manager can all introduce tracking, I check which one creates each page-view event. Adding another container during a fix can otherwise exchange a missing event for a duplicate.
Test a fresh visit and a remembered choice
My test set includes a fresh browser with no saved choice, accepting the relevant category, refusing it and returning with a choice already stored. I also check changing the choice later and navigating immediately afterwards.
I look at the consent state and the event sequence for each case. Google’s Tag Assistant checks are useful for examining defaults, updates and consent-aware tags. I then check the receiving analytics tool separately; a browser request alone does not prove the report I need has been populated correctly.
Keeping the cases separate matters. One successful visit after I have already accepted everything says very little about the next person’s first visit.
Check the dependency, not an arbitrary delay
I avoid treating a delay as a universal fix. The question is which state or event the code actually needs before it runs.
DOMContentLoaded describes the document and deferred-script lifecycle; it does not wait for every asynchronous script. A script loaded later may also arrive after that event has already fired. The right initialisation path depends on how the code is included and what it relies on.
When a performance or consent change goes live, I want both a usable page and a checked measurement sequence. That makes the next reporting conversation much less dependent on guesswork.