Rules and ethics
Part of Server-side tracking attribution UK: implementation steps
Server-side tracking attribution UK: implementation steps
Server-side tracking attribution in the UK: how PECR, UK GDPR and consent mode v2 shape implementation, with steps for mapping events and testing consent.
What to take away
- Server-side tracking moves tag execution from the browser to a container you control, so more of the measurement path stays inside your own infrastructure.
- UK GDPR and PECR still apply to that path: a server endpoint does not create a new lawful basis, and identifiers on your own domain are still personal data.
- Consent mode v2 signals decide what may be written, and a server-side container must respect the same choices as the browser.
- The practical work is documentationwhat is collected, why, where it is stored, how long it is kept, and who can access it.
How server-side tagging changes the data path
A browser tag sends requests from the visitor's device straight to the vendor's endpoint, where ad blockers and browser limits can stop them. A server-side container — usually a Google Tag Manager server container — sits on a subdomain you control, receives one stream of events, then forwards selected data to each destination: GA4, Google Ads, Meta Conversions API, TikTok Events API or LinkedIn Conversions API among them.
Browser vs server-side data path
- Visitor device: browser tag to vendor endpoint
- Ad blockers and browser limits can stop it
- Server container on subdomain you control
- One event stream, forwards selected data
- Container is your processing environment
Google documents that browser-to-server split in its Tag Manager server-side guide. The container runs on Google Cloud Run, App Engine or Cloud Functions, or on a managed host such as Stape, and each destination — GA4, Google Ads, Meta Conversions API, TikTok Events API, LinkedIn — is a tag inside it.
The gain is control, not exemption. The container is your processing environment, so the records that describe it sit with you, and an audit trail you own is one you must maintain.
Ad blockers operate in the browser, so work moved to a first-party endpoint tends to survive them. That is a reporting benefit, not a legal one.
Where UK PECR and UK GDPR bite
Storing or reading information on a user's device needs consent unless an exception applies, and that rule sits in Regulation 6 of the Privacy and Electronic Communications (EC Directive) Regulations 2003. ICO guidance on direct marketing and privacy and electronic communications explains how it works in practice.
Consent and lawful basis checks
Storing or reading device information?
consent needed unless exception applies
PECR rule not triggered
Lawful basis is a separate question. Collecting a hashed email address or a pseudonymous identifier in a server container still needs a basis under Article 6 of UK GDPR, and the ICO's lawful basis guidance sets out the options and their limits. The processing itself belongs in your Article 30 record of processing activities.
Data minimisation, Article 5(1)(c) of UK GDPR, applies at the point of forwarding. Sending the full event payload to every destination is harder to defend than sending only the fields each tool uses.
Consent mode v2 on the server side
Consent mode v2 passes consent state to your tags and models the gaps where consent is granted. A consent management platform — Cookiebot, OneTrust or Usercentrics, for example — supplies those signals, and on the server side the same state must gate what the container writes and forwards.
If a visitor denies marketing consent, the container should not forward advertising identifiers, and if analytics consent is denied, cookie-based measurement should not be set.
Cookieless attribution in the UK covers how measurement is rebuilt around withheld signals.
Implementation steps
- Map every event and field before writing code. Note which fields are personal data and which destination — GA4, Google Ads, Meta Conversions API, TikTok Events API or LinkedIn Conversions API — needs each.
- Choose a server domain you control, usually a subdomain of your main site, and decide where the container runs: Google Cloud Run, App Engine or a managed host such as Stape. Record who administers it.
- Configure the container's tags to read consent mode v2 state from your consent management platform and stop forwarding when consent is denied.
- Test with consent granted, denied, and withdrawn mid-session, and confirm each destination received the event it should.
- Set a retention period for each destination, then schedule deletion jobs to match.
- Review the tag list quarterly. Unused tags are processing you cannot justify.
Documentation that holds up
An ICO enquiry or a client audit asks four questions: what you collect, why, how long you keep it, and who can reach it. Keep the answers beside the container configuration.
Browser-side default
- Consent state
- Read by each tag before it fires
- Identifier storage
- Vendor cookie set on your domain
- Retention
- Configured in each vendor console
- Access
- Governed by vendor account roles
Server-side position
- Consent state
- Read by the container before anything is written or forwarded
- Identifier storage
- First-party cookie set on the subdomain you control
- Retention
- Configured in your container and each destination
- Access
- Governed by your cloud account and container users
Validating what you have built
After cutover, compare attribution reports against a pre-change baseline. Session counts often fall because server-side requests are less likely to be blocked, not because traffic changed. A GA4 data-driven attribution setup guide for UK sites shows where those model settings sit.
Lead counts shift too. If forms now post through your endpoint, spam filtering and duplicate checks move with them, so a rising conversion rate may be hygiene rather than demand.
How server-side conversions are attributed
Attribution depends on identifiers arriving intact. The click ID that Google Ads (gclid), Meta (fbclid), TikTok (ttclid) or LinkedIn (li_fat_id) adds to the landing URL has to be captured, stored and sent with the server-side event, so the destination can match the conversion to the click behind it.
GA4 treats server-side hits as the same events as browser hits, so data-driven attribution weighs them alongside every earlier touchpoint. Reconcile the two views: compare the conversions the container forwarded against what GA4, Google Ads and Meta report, destination by destination, and investigate any gap before you trust the model.
Consent state travels with the event. If a visitor accepts marketing but not analytics, the container can forward the ad click ID to Google Ads while withholding the analytics hit, and the model attributes from fewer observations than the browser-side report shows.
Common questions
Does server-side tagging remove the need for consent?
No. PECR applies to storing or reading information on a device wherever the code runs, and UK GDPR applies to the personal data the container processes. A server container changes the location, not the legal test.
Is a server-side container a first-party data source?
It is first-party in that you control the endpoint and the domain. That control does not make the data anonymous, and pseudonymous identifiers remain personal data under UK GDPR.
What should we check first?
Start with the event and field map. If you cannot say which destination receives each field, and why, consent configuration cannot be verified and retention cannot be set.
