Server-Side Tagging und Einwilligung: Was sich ändert und was nicht

Server-Side Tagging verlagert Anbieter-Tags aus dem Browser des Besuchers auf einen Server, den Sie kontrollieren: Die Seite sendet Ereignisse an Ihren Endpunkt, und Ihr Server leitet sie an Analyse- und Werbeplattformen weiter. Das kann Performance und Datenkontrolle verbessern, hebt aber die Einwilligungspflicht nicht auf. Cookies und Kennungen liegen weiterhin auf dem Endgerät des Besuchers, und personenbezogene Daten gelangen weiterhin zu Anbietern.

Was ist Server-Side Tagging?

Es handelt sich um ein Setup, bei dem die Seite einen einzigen Ereignisstrom an einen Tagging-Server sendet und dieser Server, nicht der Browser, die einzelnen Anbieter aufruft. Der Server läuft in der Regel auf einer Subdomain Ihrer Website, etwa metrics.example.com.

Die serverseitigen Container von Google Tag Manager sind ein bekanntes Beispiel, doch dasselbe Muster funktioniert auch mit einer Edge Function oder einer kleinen, selbst geschriebenen API. Bei einem klassischen clientseitigen Setup läuft das Skript jedes Anbieters im Browser des Besuchers und entscheidet selbst, was es erhebt. Bei einem serverseitigen Setup lädt der Browser weniger Anbieter-Code, und die Anbieter erhalten das, was Ihr Server ihnen zu senden beschließt.

Was ändert sich, wenn Sie Tags auf den Server verlagern?

Vor allem Performance und Kontrolle. Die typischen Vorteile:

• Weniger Code im Browser. Weniger Anbieter-Skripte bedeuten weniger JavaScript, das heruntergeladen und ausgeführt werden muss, was Ladezeit und Reaktionsfähigkeit zugutekommt.
• Ein Ort zum Bereinigen von Daten. Ihr Server kann jedes Ereignis prüfen, bevor er es weiterleitet: IP-Adressen verwerfen oder kürzen, URL-Parameter entfernen, die E-Mail-Adressen enthalten können, und Felder löschen, die ein Anbieter nicht braucht.
• Andere Cookie-Mechanik. Ihr Server kann First-Party-Cookies über HTTP-Header Set-Cookie statt per JavaScript setzen. Browser behandeln per Skript und per Server gesetzte Cookies in manchen Fällen unterschiedlich, und diese Regeln ändern sich laufend. Planen Sie also nicht mit einer bestimmten Cookie-Lebensdauer.
• Weniger direkte Verbindungen zu Dritten. Der Browser des Besuchers kommuniziert mit Ihrer Domain statt mit jedem einzelnen Anbieter.

Was ändert sich nicht?

Die rechtliche Bewertung. Die ePrivacy-Richtlinie und die DSGVO interessieren sich dafür, was auf dem Endgerät passiert und was mit personenbezogenen Daten geschieht, nicht dafür, welcher Server dazwischengeschaltet ist.

Frage	Clientseitiges Tagging	Serverseitiges Tagging
Werden Kennungen auf dem Endgerät des Besuchers gespeichert?	Ja, gesetzt durch Anbieter-Skripte	Meist ja, gesetzt durch Ihre Domain
Gilt die ePrivacy-Einwilligung für nicht notwendiges Speichern und Auslesen?	Ja	Ja
Gelangen personenbezogene Daten zu Anbietern?	Ja, aus dem Browser	Ja, von Ihrem Server
Braucht jeder Zweck eine Rechtsgrundlage nach der DSGVO?	Ja	Ja
Müssen Empfänger gegenüber Besuchern offengelegt werden?	Ja	Ja
Wer entscheidet, was jeder Anbieter erhält?	Weitgehend das Skript des Anbieters	Sie

Artikel 5 Absatz 3 der ePrivacy-Richtlinie betrifft das Speichern von und den Zugriff auf Informationen auf dem Endgerät. Wenn Ihr Server ein Cookie mit einer Analyse-Kennung setzt und es bei jedem Request wieder ausliest, ist das Speichern und Zugriff auf dem Endgerät, egal welche Domain oder welcher Codepfad dafür verantwortlich ist. Die Ausnahme hängt vom Zweck ab, also davon, ob das Cookie für einen vom Nutzer gewünschten Dienst unbedingt erforderlich ist, nicht davon, ob es ein First-Party-Cookie ist; siehe Arten von Cookies.

Auch für die Ereignisdaten gilt die DSGVO. Kennungen, IP-Adressen und Seiten-URLs, die sich auf eine Person beziehen, sind personenbezogene Daten. Jeder Datenfluss zu einem Anbieter braucht daher eine Rechtsgrundlage nach Artikel 6, und wo diese Grundlage die Einwilligung ist, muss sie die Bedingungen des Artikels 7 erfüllen. Wenn Sie eigentlich eine Messung ohne Kennungen wollen, ist Cookieless Analytics ein anderes Thema.

Wie übermittle ich die Einwilligung an den Server?

Senden Sie den Consent-Status mit jedem Ereignis, setzen Sie ihn auf dem Server durch und behandeln Sie alles Fehlende als abgelehnt. Der Server muss je Ziel entscheiden, denn ein einziges eingehendes Ereignis kann an mehrere Anbieter mit unterschiedlichen Zwecken verteilt werden.

Auf dem Client senden Sie ohne Einwilligung nichts und nehmen den Status in die Payload auf:

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

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

Auf dem Server leiten Sie an jedes Ziel nur weiter, was seine Kategorie erlaubt:

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

  const event = minimize(body); // IPs verwerfen, Query-Strings entfernen, ungenutzte Felder löschen
  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 });
}

Wenn Sie Google-Tags mit Consent Mode nutzen, wird der Consent-Status mit den Requests übertragen, die die Tags senden, und Google dokumentiert, wie sich seine Tags bei jedem Signal verhalten. Prüfen Sie, ob jedes Tag in Ihrem Server-Container, insbesondere Vorlagen von Drittanbietern, diesen Status tatsächlich beachtet, statt davon auszugehen. Unser Leitfaden zu Google Consent Mode v2 behandelt die vier Signale.

Was sollte mein Server mit den Daten tun?

Behandeln Sie den Tagging-Server als Datenverarbeitungssystem mit eigenen Regeln, nicht als bloße Leitung:

1. Standardmäßig ablehnen. Verwerfen Sie Ereignisse mit fehlenden oder fehlerhaften Consent-Feldern.
2. Nach Zweck weiterleiten. Senden Sie an Analyse-Anbieter nur Ereignisse mit Analyse-Einwilligung und an Werbe-Anbieter nur Ereignisse mit Marketing-Einwilligung.
3. Vor dem Weiterleiten minimieren. Kürzen oder entfernen Sie IP-Adressen, entfernen Sie Query-Strings und Fragmente und senden Sie jedem Anbieter nur die Felder, die er braucht.
4. Speicherdauer begrenzen. Rohe Ereignisprotokolle auf Ihrem Server sind ebenfalls personenbezogene Daten. Legen Sie kurze Speicherfristen fest und beschränken Sie den Zugriff.
5. Jeden Datenfluss dokumentieren. Führen Sie jeden Anbieter, die Daten, die er erhält, und den Zweck in Ihrer Datenschutzerklärung und Cookie-Richtlinie auf, denn Besucher können diese Datenflüsse in ihrem Browser nicht mehr sehen.
6. Beide Seiten prüfen. Browserbasierte Scanner sehen keinen Server-zu-Server-Traffic. Kombinieren Sie daher ein regelmäßiges Cookie-Audit mit einer Überprüfung der Tags und Ziele in Ihrem Server-Container.

Fazit

Server-Side Tagging ändert, wo Tags laufen, und gibt Ihnen mehr Kontrolle darüber, was Anbieter erhalten. Es ändert nicht, wann Sie eine Einwilligung brauchen, was als personenbezogene Daten gilt oder was Sie offenlegen müssen. Machen Sie die Einwilligung zum Bestandteil jedes Ereignisses, setzen Sie sie auf dem Server durch und minimieren Sie, was ihn verlässt. Tools wie Cookiesh können den Consent-Status bereitstellen, den Ihre Tags und Ihr Server benötigen, über die Unterstützung für Google Consent Mode v2, eine Vorlage für Google Tag Manager und eine JavaScript-API.

Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für Entscheidungen zu Ihrer konkreten Situation wenden Sie sich an qualifizierte Datenschutzfachleute.