All services

Engineering notes

Testing browser and server tracking with consent

An engineering note by Faraz Ahmad on consent-gated measurement, browser and server events, shared action IDs and isolated tracking tests.

Start with the action, not the tag

A booking, PDF download or meaningful page visit needs a clear definition before a tag is added. In my tracking work, I map each action to its destination systems and define which consent state permits it. A first-party tracking endpoint changes the transport path; it does not replace a consent decision.

Use one identifier consistently

I generate an action identifier once and carry it through the relevant browser and server payloads. That makes it possible to compare the two paths and investigate duplicates. Each destination still needs its own supported deduplication settings. A shared identifier is not a universal promise that every analytics platform will automatically discard repeated events.

Verify the consent boundary

For an implementation that keeps tracking off before agreement, the denied test checks network requests as well as visible banner state. The granted test checks the intended events and destination previews. Consent Mode defaults and updates must occur in the correct order. Basic and advanced Consent Mode behave differently; the chosen implementation should be documented.

Keep tests away from production reports

My Playwright setup isolates tracking so automated checks send nothing to live platforms. I combine those checks with Tag Assistant and server-side previews for controlled verification. I inspect repeated actions, reloads and failures separately, then compare the expected payload with the destination’s diagnostics. This checks delivery, not just whether a tag was configured.

Reference: Google Consent Mode documentation