Engineering note · January 2026 · 8 min

Server-side tagging without the grey area

Moving hits off the browser can be good engineering. It is not a privacy strategy on its own.

Close view of code on a computer monitor

Daniel Khoo’s first question in Tag Governance Intensive is always the same: “Does the server know the consent state, or only the event name?” If the answer is the event name, you have built a quieter leak.

What the server is for

A first-party endpoint can reduce the number of third-party scripts in the page, control payloads, and keep some identifiers off the wire to every vendor. Those are real benefits for consent-based tracking analytics. They only hold if the same grant, refuse, and waiting states gate the forwarder.

We still see stacks where the browser CMP blocks Meta in GTM web, while a Cloud Run function happily posts the same purchase with email hash because “it is first party now.” First-party delivery does not create a new lawful basis. The person refused advertising. The hash is still personal data about that person, sent for that purpose.

Pass the state, fail closed

The sketch we use in Consent Measurement Studio is deliberately small. The page sends a consent object with the event. The server validates it. Missing or stale state does not default to grant. Vendors are listed, not inferred from a single “marketing = true” flag that nobody can audit.

If your CMP cannot emit a reliable callback, fix that before you invest in a server container. A beautiful sGTM setup on top of a broken banner is expensive theatre.

Logs are still data

Server logs that retain full payloads for “debugging” after reject are another quiet failure. Decide retention for debug captures the same way you decide tag retention. A week of unrestricted logs can undo a careful taxonomy.

None of this requires a particular cloud. It requires the same discipline you owed the browser, applied one hop later.

← Journal · Consent-based tracking