What is the single most important field in a consent record?

The notice version is the one most often missing and most often decisive. Without it, you can show a choice was recorded but not what wording, purposes, or vendors the choice referred to, which weakens the record badly in a dispute.

How long should consent records be retained?

Tie the period to the relationship length plus the applicable limitation period for claims in your markets, write it into a retention schedule, and apply deletion across every copy, including warehouse exports and backups, when the period ends.

Does a consent banner log prove tags behaved?

No. The log proves the choice as recorded. Proving behaviour needs a production check that tags fired or stayed silent according to that state. Keep evidence of both, and repeat the behaviour check after tag manager changes.

Should rejected consent be stored with the same care as accepted?

Yes. A recorded refusal, with timestamp and version, is what stops a team from re prompting aggressively or accidentally enabling a purpose later. It also demonstrates that refusal was honoured, which regulators treat as part of valid consent design.

Server-Side Tracking Still Needs Consent Signals

October 31, 2026

Moving tags server side improves data quality and page speed, and it does not move the consent obligation. How consent state has to travel with the event, every time.

Server side tracking gets sold on performance and accuracy: fewer scripts in the browser, less data lost to blockers, cleaner events flowing to analytics and ad platforms. All of that can be true. None of it changes the underlying question, which is whether the shopper agreed to the tracking in the first place. A server does not launder consent by standing between the browser and the platform.

The failure mode is specific and common. The client side setup respected consent carefully, the migration to server side happens for good technical reasons, and somewhere in the new pipeline the consent state stops travelling with the event. The platforms receive everything, the dashboards look healthier, and the store has quietly rebuilt the problem it once fixed.

Consent state is part of the event

Every event leaving your server for a third party should carry, or be gated by, the consent state that applies to it: which purposes were granted, when, and under which notice version. If the pipeline cannot answer, for a given event, what consent it was sent under, then the pipeline is sending on assumption, and assumption is not a consent mode.

Build the gate into the server side setup, not around it. Events for a purpose that was refused should not be sent in identifiable form to that purpose platform at all, rather than sent with a flag asking the platform to be careful with them. Platforms differ in how they honour signals, and a store that outsources the decision to each platforms settings page has as many policies as it has platforms.

Test the refusal path on the server, not the banner

Most consent testing stops at the browser: refuse, check cookies, check tags. Server side setups need the same test extended. Refuse on a test visit, complete a purchase journey, and then inspect what actually arrived at each platform for that session. That end to end check is the only version that counts, because it tests the system shoppers actually interact with.

Include the awkward cases. Consent granted then withdrawn mid session. A returning shopper whose stored choice predates a new purpose added last month. A checkout completed on a subdomain or a payment page with a different setup. Each of those is a place where consent state gets lost in real implementations, usually at a handoff between systems owned by different teams.

Document who owns the signal

When client and server setups are owned by different people, consent falls into the gap. Name one owner for the consent signal end to end, with the authority to block a tracking change that would break it. Migrations, new platforms, and new events should all pass that owner, in the same way schema changes pass a data owner in a well run team.

Keep a simple map: purposes, platforms, what each receives, and the consent each requires. It fits on one page and it is the document everyone reaches for when a new tool is proposed. Stores without that map discover their own tracking from a regulators questions, which is the most expensive way to draw one.

Frequently asked questions

Does server side tracking avoid consent requirements?

No. Moving data collection server side changes the plumbing, not the obligation. Events still need to be gated by the shoppers consent for the relevant purpose before they are shared with third parties.

What should travel with a server side event?

The consent state for that event: which purposes were granted, when consent was given, and the notice version. If the pipeline cannot show under what consent an event was sent, it is sending on assumption.

How should we test a server side consent setup?

Refuse consent on a test visit, complete a full journey including checkout, then inspect what each platform actually received for that session. Test withdrawal mid session and returning visitors with older stored choices too.

Who should own consent in a server side setup?

One named owner for the consent signal end to end, with authority over tracking changes. Keep a one page map of purposes, platforms, what each receives, and the consent each requires.