Serverseitiges Tagging

Serverseitiges Tagging verlagert die Ausführung Ihrer Tags aus dem Browser des Nutzers auf einen von Ihnen kontrollierten Server. Statt dass die Seite Pixel direkt an Google und Meta sendet, übermittelt sie eine einzige Anfrage an Ihren eigenen Tagging-Endpunkt.

Dieser Server entscheidet anschließend, was an wen und in welcher Form weitergeleitet wird. Der Browser kommuniziert ausschließlich mit Ihrer First-Party-Domain.

Im klassischen Modell läuft jedes Anbieter-Pixel im Browser und sendet jeweils eine eigene Third-Party-Anfrage. Beim serverseitigen Tagging sendet der Browser ein Event an einen Tagging-Server, der es an mehrere Ziele weiterleitet.

Damit erhalten Sie Kontrolle über die Daten, reduzieren blockierte Anfragen und verringern den Umfang des clientseitigen Codes, der Seiten verlangsamt.

Googles Server-Side Google Tag Manager (sGTM) ist die gängigste Implementierung. Dabei handelt es sich um einen Container, der auf Cloud Run, App Engine oder einem beliebigen Host läuft, Anfragen empfängt und sie über Clients und Tags verarbeitet.

Ein 'Client' analysiert eingehende Anfragen und wandelt sie in Events um; 'Tags' senden diese Events anschließend an die jeweiligen Ziele weiter. Es ist GTM, das auf dem Server statt auf der Seite ausgeführt wird.

Der entscheidende Zuverlässigkeitsgewinn entsteht, wenn Sie den Tagging-Server über einen DNS-A- oder CNAME-Eintrag einer Subdomain Ihrer eigenen Website zuordnen, etwa sgtm.example.com.

Da die Anfragen nun an Ihre Domain gehen, sind die in der Antwort gesetzten Cookies First-Party-Cookies und HttpOnly. Sie entgehen den strengsten ITP-Begrenzungen und werden von Werbeblockern deutlich seltener blockiert.

Auf der Seite findet ein Kauf statt. Der Web-Container (oder gtag) sendet ein Event an sgtm.example.com. Der GA4-Client dort rekonstruiert den Hit, reichert ihn an, und ein GA4-Tag leitet ihn an Googles Collection-Endpunkt weiter.

Dasselbe Event kann gleichzeitig ein Meta Conversions API-Tag, eine serverseitige Google-Ads-Conversion und weitere Aktionen auslösen – alles ausgehend von einer einzigen eingehenden Anfrage.

Metas Conversions API, Googles Enhanced Conversions und TikToks Events API sind allesamt Server-zu-Server-Endpunkte. Sie akzeptieren Events direkt von Ihrem Server und umgehen das Browser-Pixel vollständig.

Damit können Sie Conversions zurückgewinnen, die durch Werbeblocker und ITP verloren gehen, und gehashte First-Party-Identifikatoren (E-Mail-Adresse, Telefonnummer) für ein besseres Matching senden, sofern Sie eine Einwilligung haben.

Da der Server das Roh-Event sieht, können Sie es anreichern: Fügen Sie den tatsächlichen Bestellwert aus Ihrer Datenbank hinzu, entfernen Sie PII, die Sie nicht weitergeben möchten, ergänzen Sie serverseitige Zeitstempel oder führen Sie eine Deduplizierung mit Client-Events durch.

Sie werden zum Redakteur Ihrer eigenen Daten und senden jeder Plattform nur die minimal erforderlichen Felder. Das ist Datenminimierung in der Praxis und nicht nur eine Richtlinie.

Wenn Sie sowohl ein Browser-Pixel als auch ein Server-Event für dieselbe Conversion ausführen, dürfen Plattformen diese nicht doppelt zählen. Bei der Deduplizierung wird ein gemeinsamer Identifikator verwendet.

Senden Sie dieselbe event_id (und event_name) sowohl vom Client-Pixel als auch vom Server-CAPI-Aufruf. Meta und andere Anbieter gleichen die Werte ab und behalten nur ein Event. So erhalten Sie Redundanz ohne Aufblähung der Zahlen.

Der Tagging-Server ist echte Infrastruktur. Auf Google Cloud Run skaliert er automatisch mit dem Traffic; Sie zahlen für Rechenleistung und ausgehenden Datenverkehr. Eine kleine Website benötigt möglicherweise nur ein paar Instanzen, eine große hingegen viele.

Planen Sie Monitoring, einen Vorschau-Server zum Debuggen und ausreichende Verfügbarkeit ein, denn wenn Ihr Tagging-Server ausfällt, fällt auch die Messung aus. Er ist jetzt ein Produktionsdienst und kein Snippet mehr.

Serverseitiges Tagging ist kein Weg, die Einwilligung zu umgehen. Sie benötigen weiterhin eine Rechtsgrundlage, und das Senden von Daten ohne Einwilligung ist unabhängig vom Ausführungsort illegal.

Es stellt auch nicht auf magische Weise deterministisches websiteübergreifendes Tracking wieder her. Es verbessert die Zuverlässigkeit und das Matching bei First-Party-Daten, für deren Nutzung eine Einwilligung vorliegt. Es ist eine Resilienzschicht und kein Schlupfloch.

Eine echte Einführung folgt einer festgelegten Reihenfolge: Setzen Sie den Server auf, ordnen Sie die Subdomain zu, binden Sie den Web-Container daran an, konfigurieren Sie Clients und Tags und verbinden Sie anschließend die CAPI-Ziele.

Validieren Sie die Konfiguration in der Vorschau- bzw. Debug-Ansicht, bestätigen Sie, dass die Deduplizierung funktioniert, prüfen Sie die Einwilligungssteuerung und stellen Sie erst dann den Traffic um. Behandeln Sie den Vorgang wie die Bereitstellung jedes anderen Backend-Dienstes.

Testen Sie Ihr Verständnis von serverseitigem Tagging.

Serverseitiges Tagging leitet Browser-Events an einen Tagging-Server auf Ihrer eigenen Subdomain weiter. Dieser setzt First-Party-Cookies und übermittelt Daten, für deren Nutzung eine Einwilligung vorliegt, über Server-zu-Server-APIs wie Meta CAPI an Plattformen.

Die Vorteile sind weniger blockierte Anfragen, ITP-freundlichere Cookies, Datenanreicherung und Datenminimierung sowie die Deduplizierung von Events. Es handelt sich um eine Zuverlässigkeits- und Kontrollebene und um echte zu betreibende Infrastruktur, niemals jedoch um einen Ersatz für die Einwilligung.