Server-Side Tracking einrichten - Anleitung in 8 Schritten

Server-Side Tracking richtest du ein, indem du in Google Tag Manager einen Server-Container anlegst, ihn über einen Hoster wie Stape oder TAGGRS bereitstellst, eine eigene Subdomain per CNAME verbindest und deinen Web-Container an diese Subdomain schickst. Danach konfigurierst du GA4- und Google-Ads-Tags im Server-Container und validierst das Setup.

Was du vorher brauchst

Bevor du den ersten Container anlegst, sollten fünf Dinge stehen. Wenn eines davon fehlt, baust du auf Sand.

• Ein funktionierender Web-Container in Google Tag Manager, über den GA4 und Google Ads bereits laufen
• Eine GA4-Property mit korrekter Messungs-ID
• Consent Mode v2, sauber über dein Consent-Tool verdrahtet
• Saubere dataLayer-Events für deine Kern-Conversions (Formular, Terminbuchung, Anruf)
• DNS-Zugriff auf deine Domain, um eine Subdomain anzulegen

Der letzte Punkt ist der, an dem es in der Praxis am häufigsten hängt. In den Accounts, die ich übernehme, sitzt der DNS-Zugang oft bei einer Webagentur, die vor drei Jahren die Seite gebaut hat. Kläre das vorher, sonst stehst du mitten im Setup still.

Server-Side Tracking einrichten: die 8 Schritte

Schritt 1: Bestehendes Tracking dokumentieren

Schreib auf, welche Tags aktuell im Web-Container feuern, welche Conversion-Aktionen in Google Ads aktiv sind und wie viele Conversions du in den letzten 30 Tagen gemessen hast. Diese Zahl ist später dein Referenzwert.

Ohne diesen Schritt weißt du nach der Migration nicht, ob dein Setup besser geworden ist oder ob du dir eine Lücke eingebaut hast. Ich mache das in einer simplen Tabelle: Tag-Name, Auslöser, Ziel-Plattform, Conversions letzte 30 Tage.

Schritt 2: Server-Container in Google Tag Manager anlegen

Geh in Tag Manager auf Konten → neben dem Kontonamen auf die drei Punkte → Container erstellen. Vergib einen Namen (z. B. „Firmenname - Server"), wähle als Zielplattform Server und klicke auf Erstellen.

Danach öffnet sich der Dialog „Tagging-Server einrichten". Hier wählst du nicht die automatische Bereitstellung über Google Cloud, sondern „Tagging-Server manuell bereitstellen". Kopiere den Container-Konfigurationsstring (diesen langen Code brauchst du gleich beim Hoster). Details zum Ablauf stehen in der offiziellen Google-Dokumentation zum Server-Side Tagging.

Schritt 3: Hosting bei Stape oder TAGGRS aufsetzen

Erstelle einen Account bei Stape oder TAGGRS und lege dort einen neuen Container an. Du fügst den Container-Konfigurationsstring aus Schritt 2 ein, wählst eine Server-Region und klickst auf Deploy.

Für DACH-Kunden nehme ich immer eine EU-Region (Frankfurt oder Belgien). Das ist kein Nice-to-have, sondern erspart dir in der Datenschutz-Diskussion mit deinem Kunden oder deinem eigenen Datenschutzbeauftragten eine Menge Arbeit.

Nach zwei bis fünf Minuten läuft der Server. Beide Anbieter haben einen kostenlosen Tarif bis 10.000 Requests im Monat, also genug, um das Setup zu testen, aber nicht genug für Live-Traffic.

Schritt 4: Eigene Subdomain per CNAME verbinden

Der Hoster gibt dir einen Zielwert für einen CNAME-Eintrag. Leg in deinem DNS eine Subdomain an, zum Beispiel sgtm.deinefirma.de, und zeige damit auf diesen Zielwert. Das SSL-Zertifikat stellen Stape und TAGGRS automatisch aus.

Diesen Schritt darfst du nicht überspringen. Wenn dein Tagging-Server unter der Domain des Hosters läuft, sind die Cookies aus Browser-Sicht Third-Party und du hast dir den ganzen Aufwand gespart. Nur eine echte Subdomain deiner Hauptdomain macht daraus First-Party-Cookies.

Trag die fertige URL anschließend in Tag Manager unter Admin → Container-Einstellungen → Server-Container-URL ein.

Schritt 5: Web-Container auf den Server umleiten

Jetzt schickst du deine Daten an den eigenen Server statt direkt zu Google. Öffne im Web-Container dein Google-Tag beziehungsweise deine GA4-Konfiguration und ergänze unter den Konfigurationseinstellungen das Feld server_container_url mit dem Wert https://sgtm.deinefirma.de.

Teste das im Vorschaumodus, bevor du veröffentlichst. Im Tag Assistant siehst du, ob die Requests an deine Subdomain gehen statt an google-analytics.com. Erst wenn das sauber durchläuft, klickst du auf Senden.

Schritt 6: Server-Tags konfigurieren

Im Server-Container ist der GA4-Client standardmäßig aktiv, er nimmt die eingehenden Requests entgegen. Darauf baust du auf:

1. GA4-Tag anlegen (Tag-Typ „Google Analytics: GA4"), Messungs-ID eintragen, als Auslöser den Standard-Trigger „Alle Ereignisse" wählen.
2. Conversion Linker im Server-Container aktivieren. Ohne ihn wird die gclid nicht als First-Party-Cookie gespeichert und deine Google-Ads-Attribution bricht.
3. Google Ads Conversion Tracking Tag anlegen, Conversion-ID und Conversion-Label aus Google Ads eintragen, als Auslöser dein Lead-Event (z. B. generate_lead).
4. Enhanced Conversions: Häng im Web-Container ein user_data-Objekt mit E-Mail und Telefonnummer an das Conversion-Event. Das Google-Ads-Tag im Server-Container übernimmt die Daten und hasht sie automatisch. In Google Ads musst du dafür einmalig die Nutzungsbedingungen für Kundendaten akzeptieren.

Wenn du parallel noch client-seitig trackst, arbeite mit einer eindeutigen event_id oder transaction_id zur Deduplizierung. Sonst zählst du jede Anfrage doppelt und dein Smart Bidding optimiert auf Phantom-Conversions.

Schritt 7: Testen, bevor du live gehst

Öffne den Vorschaumodus von Web- und Server-Container gleichzeitig. Dann gehst du auf deine Website und löst eine echte Testanfrage aus.

Diese fünf Checks mache ich bei jedem Setup:

• Kommt das Event im Server-Container an, und feuern GA4- und Google-Ads-Tag beide?
• Landet das Event in GA4 DebugView mit den erwarteten Parametern?
• Zeigt der Tag Assistant die Requests an deine eigene Subdomain?
• Steht die Conversion-Aktion in Google Ads nach ein paar Stunden auf „Aktiv"?

Schritt 8: Veröffentlichen und 14 Tage beobachten

Veröffentliche erst den Server-Container, dann den Web-Container. Danach schaltest du die alten client-seitigen Google-Ads-Conversion-Tags ab. Nicht vorher, sonst hast du eine Messlücke.

In den folgenden zwei Wochen vergleichst du die Conversion-Zahlen mit deinem Referenzwert aus Schritt 1. Die Enhanced-Conversions-Matchrate siehst du im Diagnose-Tab der Conversion-Aktion, meist nach 48 bis 72 Stunden. Und behalte den Request-Verbrauch im Dashboard deines Hosters im Auge, damit dich die erste Rechnung nicht überrascht

Wie ich das immer umsetze

Bei allen Projekten läuft client-seitiges und server-seitiges Tracking parallel um zu ermitteln, ob die server-seitige Variante wirklich mehr Conversions trackt. Dabei laufen allerdings niemals beide Conversion-Aktionen primär, eine davon muss zwingend auf Sekundär gestellt werden, damit diese nur beobachtet, die Daten aber nicht doppelt für die Optimierung verwendet werden.

Die vier Fehler, die ich am häufigsten sehe

Fehler 1: Subdomain vergessen.

Das Setup läuft technisch, aber über die Hoster-Domain. Ergebnis: keine First-Party-Cookies, kaum Datengewinn. Lösung: CNAME wie in Schritt 4.

Fehler 2: Alte Tags bleiben aktiv.

Client- und Server-Tag feuern parallel, ohne Deduplizierung. Die Conversion-Zahlen steigen sprunghaft, der Cost-per-Lead sieht plötzlich super aus und ist gelogen.

Fehler 3: Consent Mode ignorieren.

Server-Side Tracking hebelt keine Einwilligungspflicht aus. Wer das behauptet, verkauft dir ein Problem.

Fehler 4: Kein Lead-Qualitäts-Rückkanal.

Du misst jetzt sauber, welche Klicks zu Formularen führen aber nicht, welche zu Kunden. Bei den Datenpionieren war genau diese CRM-Rückkopplung der Hebel, der aus Anfragen 76 qualifizierte Leads in drei Monaten gemacht hat.

Wann lohnt sich das Setup und wann nicht?

Server-Side Tracking rechnet sich, wenn du monatlich vierstellig in Google Ads investierst, lange Sales-Cycles hast und deine Zielgruppe technikaffin ist. Genau das trifft auf IT-Dienstleister und Software-Anbieter zu: Deren Entscheider nutzen überdurchschnittlich oft Adblocker und Safari. In typischen B2B-Accounts, die ich übernehme, fehlen 20 bis 40 Prozent der Conversion-Daten, weil Browser oder Blocker die Pixel abfangen.

Weniger sinnvoll ist es bei sehr kleinen Budgets, bei denen die Hosting-Kosten einen spürbaren Anteil des Werbebudgets fressen, oder wenn dein client-seitiges Tracking schlicht noch nie sauber aufgesetzt wurde. Repariere erst die Basis. Dann erst solltest du migrieren.

Und ganz ehrlich: Der laufende Aufwand ist der eigentliche Preis. Plattformen ändern ihre Schnittstellen mehrmals im Jahr. Ein Server-Setup, das niemand pflegt, ist nach zwölf Monaten schlechter als ein gepflegtes Client-Setup.