Server-side tagging and consent: what changes and what doesn't

Server-side tagging moves vendor tags from the visitor’s browser to a server you control: the page sends events to your endpoint, and your server forwards them to analytics and advertising platforms. That can improve performance and data control, but it does not remove consent requirements. Cookies and identifiers still live on the visitor’s device, and personal data still reaches vendors.

What is server-side tagging?

It is a setup where the page sends one stream of events to a tagging server, and that server, rather than the browser, calls each vendor. The server usually runs on a subdomain of your site, such as metrics.example.com.

Google Tag Manager’s server-side containers are a well-known example, but the same pattern works with an edge function or a small API you write yourself. In a classic client-side setup, every vendor’s script runs in the visitor’s browser and decides what to collect. In a server-side setup, the browser loads less vendor code, and vendors receive what your server chooses to send.

What changes when you move tags to the server?

Mainly performance and control. The typical benefits:

• Less code in the browser. Fewer vendor scripts means less JavaScript to download and run, which helps loading and responsiveness.
• A place to clean data. Your server can inspect every event before forwarding it: drop or truncate IP addresses, strip URL parameters that can carry email addresses, and remove fields a vendor does not need.
• Different cookie mechanics. Your server can set first-party cookies through HTTP Set-Cookie headers instead of JavaScript. Browsers treat script-set and server-set cookies differently in some cases, and those rules keep changing, so do not plan around a specific cookie lifetime.
• Fewer direct third-party connections. The visitor’s browser talks to your domain instead of to each vendor.

What doesn’t change?

The legal analysis. The ePrivacy Directive and GDPR care about what happens on the device and what happens to personal data, not about which server sits in the middle.

Question	Client-side tagging	Server-side tagging
Are identifiers stored on the visitor’s device?	Yes, set by vendor scripts	Usually yes, set by your domain
Does ePrivacy consent apply to non-essential storage and access?	Yes	Yes
Does personal data reach vendors?	Yes, from the browser	Yes, from your server
Does each purpose need a GDPR lawful basis?	Yes	Yes
Must recipients be disclosed to visitors?	Yes	Yes
Who decides what each vendor receives?	Largely the vendor’s script	You

Article 5(3) of the ePrivacy Directive is about storing or accessing information on the device. If your server sets an analytics identifier cookie and reads it back on each request, that is storage and access on the device, whichever domain or code path does it. The exemption depends on purpose, meaning strictly necessary for a service the user requested, not on whether the cookie is first-party; see types of cookies.

GDPR applies to the event data too. Identifiers, IP addresses and page URLs that relate to a person are personal data, so each flow to a vendor needs a lawful basis under Article 6, and where that basis is consent, it must meet the conditions in Article 7. If what you really want is measurement without identifiers, cookieless analytics is a different conversation.

How do I pass consent to the server?

Send the consent state with every event, enforce it on the server and treat anything missing as denied. The server has to decide per destination, because one incoming event can fan out to several vendors with different purposes.

On the client, send nothing without consent and include the state in the payload:

type ConsentState = { analytics: boolean; marketing: boolean };

export function track(event: string, props: Record<string, unknown>, consent: ConsentState) {
  if (!consent.analytics && !consent.marketing) return; // nothing may be sent
  navigator.sendBeacon(
    'https://metrics.example.com/collect',
    JSON.stringify({ event, props, consent, ts: Date.now() }),
  );
}

On the server, forward to each destination only what its category allows:

export async function handleCollect(req: Request): Promise<Response> {
  const body = await req.json().catch(() => null);
  const analytics = body?.consent?.analytics === true; // missing means denied
  const marketing = body?.consent?.marketing === true;
  if (!analytics && !marketing) return new Response(null, { status: 204 });

  const event = minimize(body); // drop IPs, strip query strings, remove unused fields
  const jobs: Promise<unknown>[] = [];
  if (analytics) jobs.push(sendToAnalytics(event));
  if (marketing) jobs.push(sendToAdPlatform(event));
  await Promise.allSettled(jobs);

  return new Response(null, { status: 204 });
}

If you use Google tags with consent mode, the consent state travels with the requests the tags send, and Google documents how its tags behave under each signal. Check that every tag in your server container, especially third-party templates, actually respects that state rather than assuming it does. Our Google Consent Mode v2 guide covers the four signals.

What should my server do with the data?

Treat the tagging server as a data processing system with its own rules, not a pipe:

1. Default to deny. Drop events with missing or malformed consent fields.
2. Route by purpose. Send analytics vendors only analytics-consented events, and advertising vendors only marketing-consented events.
3. Minimize before forwarding. Truncate or remove IP addresses, strip query strings and fragments, and send each vendor only the fields it needs.
4. Limit retention. Raw event logs on your server are personal data too. Set short retention and restrict access.
5. Document every flow. List each vendor, the data it receives and the purpose in your privacy notice and cookie policy, because visitors can no longer see these flows in their browser.
6. Audit both sides. Browser-based scanners cannot see server-to-server traffic, so pair a regular cookie audit with a review of your server container’s tags and destinations.

Bottom line

Server-side tagging changes where tags run and gives you more control over what vendors receive. It does not change when you need consent, what counts as personal data or what you must disclose. Make consent part of every event, enforce it on the server and minimize what leaves it. Tools like Cookiesh can provide the consent state your tags and server need, through Google Consent Mode v2 support, a Google Tag Manager template and a JavaScript API.

This article is general information, not legal advice. For decisions about your specific situation, consult a qualified privacy professional.