Was Server-Side Tracking ist – und was nicht

Wie funktioniert klassisches Tracking im Browser?

Beim Client-Side Tracking lädt der Browser des Besuchers Skripte von Google, Meta und anderen Anbietern. Jedes dieser Skripte sammelt Daten und schickt sie direkt an seinen Anbieter. Der Shopbetreiber hat keinen Zwischenschritt, an dem er sehen oder steuern könnte, was das Skript übermittelt. Gleichzeitig ist jedes dieser Skripte ein Ziel für Werbeblocker und Browserschutz, und jedes kostet Ladezeit.

Was ändert sich beim Server-Side Tracking?

Beim Server-Side Tracking schickt der Browser seine Messdaten zunächst an einen eigenen Server, der unter Ihrer Domain läuft, etwa unter einer Subdomain wie data.ihrshop.de. Dort läuft ein Servercontainer des Google Tag Managers. Er nimmt die Daten entgegen, prüft und bereinigt sie und leitet sie kontrolliert an GA4, Google Ads, Meta, Microsoft und andere Plattformen weiter.

Drei Dinge ändern sich dadurch grundlegend:

• Kontrolle: Sie entscheiden, welche Daten an welche Plattform gehen. IP-Adressen können gekürzt, Parameter entfernt, sensible Felder gefiltert werden, bevor etwas Ihren Server verlässt.

• Stabilität: Die Anfragen gehen an Ihre eigene Domain statt an bekannte Tracking-Domains. Cookies können vom Server gesetzt werden statt per JavaScript, was in Safari je nach Aufbau zu deutlich längeren Laufzeiten führt.

• Anschluss an die Plattform-APIs: Der Server spricht direkt mit den Conversion-Schnittstellen der Werbeplattformen, etwa der Meta Conversions API oder den Enhanced Conversions von Google.

Ersetzt der Server das Tracking im Browser komplett?

In fast allen Shop-Einrichtungen nicht. Der übliche Aufbau ist ein Hybrid: Ein schlanker Webcontainer im Browser erfasst die Ereignisse und schickt sie an den Server. Einige Pixel laufen bewusst weiter im Browser, weil sie dort Klick-IDs und Cookies für Remarketing-Zielgruppen auslesen. Die Conversions selbst gehen über den Server, und doppelte Meldungen werden über eine gemeinsame Event-ID aussortiert. Wer behauptet, nach der Umstellung laufe „kein einziges Skript mehr im Browser“, beschreibt einen Sonderfall.

Was ist das Google Tag Gateway?

Das Google Tag Gateway for Advertisers, früher „First-Party Mode“, lädt Google-Skripte wie gtm.js von Ihrer eigenen Domain statt von Googles Servern. Cloudflare bietet es als Ein-Klick-Integration an. Das ist nützlich, aber kein Server-Side Tracking: Es ändert den Weg, auf dem Skripte geladen und Daten gesendet werden, nicht aber, wer die Daten an die Plattformen schickt. Werbeblocker mit guten Filterlisten erkennen Google Tag Manager auch unter eigener Domain, und Cookies werden weiterhin per JavaScript gesetzt. Seine volle Wirkung entfaltet das Gateway erst in Kombination mit einem Servercontainer.

Was leisten die Server-Schnittstellen der Shop-Apps?

Shopify-Apps wie Google & YouTube oder Facebook & Instagram und verschiedene Shopware-Erweiterungen übermitteln Käufe inzwischen selbst serverseitig an die Plattformen. Für einen kleinen Shop mit einem Werbekanal kann das reichen. Die Grenzen zeigen sich, sobald mehrere Kanäle, mehrere Domains oder eigene Regeln ins Spiel kommen: Jede App arbeitet für sich, die Daten laufen nicht über eine gemeinsame Kontrollinstanz, und doppelte Messungen durch App plus eigenes Tag sind ein häufiger Fehler.

Welche Lösung passt zu welchem Shop?

• Ein Werbekanal, kleines Budget: Native App-Schnittstelle sauber einrichten, Consent prüfen. Server-Side Tracking bringt hier oft weniger als eine gute Grundkonfiguration.

• Google Ads als Hauptkanal, Cloudflare vorhanden: Tag Gateway als schneller erster Schritt, mit realistischen Erwartungen.

• Mehrere Werbekanäle, vierstelliges Monatsbudget oder mehr: Servercontainer mit TAGGRS oder vergleichbarem Hosting. Hier spielt Server-Side Tracking seine Stärken aus, weil alle Kanäle aus einer sauberen Datenquelle versorgt werden.