GA4 Server-Side-Tracking über die Redirect-Ebene

GA4-Client-Side-Tagging via gtag.js oder GTM ist die Attributionsbasis, auf die die meisten Teams standardmäßig zurückgreifen. Unter idealen Bedingungen funktioniert es gut: ein Chrome-Desktop-Nutzer mit schneller Verbindung, kein Ad-Blocker, eine Safari-Session, die das 24-Stunden-Script-Set-Cookie-Limit von ITP noch nicht ausgelöst hat. Ideale Bedingungen decken in 2026 vielleicht 65-75 % des EU-Traffics ab.

Der Rest - uBlock-Origin-Nutzer, Braves eingebautes Blocking, Safaris Intelligent Tracking Prevention auf iOS, die wachsende Gruppe an Netzwerk-Blockern wie NextDNS und Pi-hole - sendet Events, die entweder vor dem Erreichen von www.google-analytics.com abfallen oder ohne brauchbaren Client-Identifier ankommen, weil das _ga-Cookie geleert wurde. Die typische Lücke auf EU-lastigen Zielgruppen liegt bei 25-35 % der Conversion-Events. Für manche Branchen - Fintech, Privacy-Tools, Dev-Tooling - läuft sie höher, weil das Nutzerprofil mit der Ad-Blocker-Adoption korreliert.

GA4s Measurement Protocol ist der serverseitige Pfad, der all das umgeht. Ihr Server spricht direkt mit Googles Collection-Endpoint. Der Zustand des Browsers ist irrelevant. Dieser Post deckt das exakte Setup ab: Credentials, Payload-Form, client_id-Verknüpfung, Validierung und das Deduplikationsmuster für Teams, die gtag neben dem serverseitigen Pfad fahren.

Die zugrundeliegende Conversion-Forwarding-Architektur - warum Server-Side gewinnt und wie Fan-out an mehrere Plattformen funktioniert - wird in der server-side conversion tracking overview abgedeckt. Die Meta-CAPI-Version dieses Tutorials liegt bei forwarding conversions to Meta CAPI; das Setup-Muster hat dieselbe Form, hier mit GA4-spezifischen Parametern.

TL;DR

• GA4 gtag.js verliert auf typischem EU-Traffic 25-35 % der Conversion-Events an Ad-Blocker (uBlock, Brave) und ITP (Cookie-Lebensdauer-Limits in Safari); das Measurement Protocol umgeht all das, weil die Anfrage von Ihrem Server ausgeht.
• Sie brauchen zwei Credentials: die Measurement ID (G-XXXXXXXX) aus Ihrem Datenstream und ein API-Secret, das unter Admin → Data Streams → Measurement Protocol API secrets generiert wird. Beide verlangt auch die GA4-Integration von Elido, die Klick-Events (keine Käufe) weiterleitet und in etwa zwei Minuten eingerichtet ist.
• Die client_id ist das, was ein Server-Side-Event mit einer GA4-Session verknüpft; Elido setzt keine Klick-ID und kein Cookie beim Redirect und leitet Käufe noch nicht an GA4 weiter, Sie erfassen die client_id also auf Ihrer eigenen Seite und senden das Measurement-Protocol-Event von Ihrem eigenen Server.
• Die Validierung dauert etwa zehn Minuten: GA4 DebugView zeigt Measurement-Protocol-Events innerhalb von rund zehn Sekunden; Standardberichte füllen sich über 24-48 Stunden nach.

Die zwei Credentials, die Sie brauchen

GA4 Measurement Protocol verlangt zwei Informationen, beide aus der GA4-Admin-Konsole.

Measurement ID. Die Datenstream-Kennung, formatiert als G-XXXXXXXX. Sie finden sie unter Admin → Data Streams → Ihr Web-Stream → das Stream-Detail-Panel. Es ist dieselbe ID, die Sie an gtag('config', 'G-XXXXXXXX') in Ihrem Client-Side-Setup übergeben - sie ist kein Secret und erscheint im Seitenquelltext.

API Secret. Das ist der Credential, der serverseitige Schreibvorgänge gegen den Collection-Endpoint autorisiert. Navigieren Sie zu Admin → Data Streams → Ihr Web-Stream → Measurement Protocol API secrets → Create. Das Secret ist eine kurze alphanumerische Zeichenfolge. Behandeln Sie es wie einen Service-Account-Key: speichern Sie es als Workspace-Secret, rotieren Sie es zusammen mit anderen Service-Credentials, committen Sie es nicht in den Quellcode.

In Elido fügen Sie diese Werte unter Workspace Settings → Integrations → GA4 ein. Test connection sendet anschließend ein Test-Event an den GA4-Validierungsserver und sendet es, wenn das Payload die Prüfung besteht, mit gesetztem debug_mode tatsächlich. Diese Prüfung deckt das Payload ab, nicht die Credentials: Der Validierungsserver akzeptiert jedes API-Secret und sogar eine Measurement ID, die zu keiner Property gehört, sodass ein Bestehen nicht beweist, dass das Paar korrekt ist. Bestätigen Sie das Test-Event in DebugView oder Realtime, bevor Sie sich darauf verlassen.

Die Event-Form

Die GA4 Measurement Protocol reference (abgerufen am 12.05.2026) spezifiziert das Request-Format. Der Endpoint lautet:

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>

Der Body trägt eine client_id, eine optionale user_id und ein events-Array. Hier das Payload für ein Purchase-Event:

{
  "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "user_id": "user-shop-12847",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "ord_98231",
        "value": 89.5,
        "currency": "EUR",
        "engagement_time_msec": 1,
        "items": [
          {
            "item_id": "sku-spring-jeans-32-blue",
            "item_name": "Spring Jeans 32 Blue",
            "quantity": 1,
            "price": 89.5
          }
        ]
      }
    }
  ]
}

Ein paar Dinge in diesem Payload, die leicht falsch laufen:

event_name muss lowercase snake_case sein. Die GA4 event reference (abgerufen am 12.05.2026) listet die empfohlenen Event-Namen: purchase, sign_up, generate_lead, add_to_cart. Senden Sie Purchase (großes P), erzeugt das ein separates Event in den GA4-Berichten, statt mit Ihren gtag-gefeuerten purchase-Events zu verschmelzen. Die Plattform warnt Sie nicht; das Event landet schlicht als seltsam benanntes Custom Event.

engagement_time_msec muss vorhanden sein und auf einen positiven Integer gesetzt sein. Ohne dieses Feld zählt GA4 das Event, schreibt der Session aber kein Engagement gut, und einige Attributionsmodelle schließen Events ohne Engagement-Zeit aus. 1 zu setzen reicht, um die Anforderung zu erfüllen.

event_params ist auf 25 Parameter pro Event gedeckelt. Das Measurement Protocol weist Payloads zurück, die das Limit überschreiten. Die Zurückweisung erfolgt standardmäßig stillschweigend - die Anfrage gibt 204 ohne Body zurück, unabhängig davon, ob das Event akzeptiert wurde. Verwenden Sie den Debug-Endpoint mit auf ENFORCE_RECOMMENDATIONS gesetztem validation_behavior (im Validierungsabschnitt behandelt), um Überläufe zu fangen; im Standardmodus wird ein 26. Parameter zugelassen.

user_id ist optional, aber wertvoll. Wenn Sie serverseitig einen persistenten Nutzer-Identifier haben - eine Kunden-ID in Ihrer Bestelltabelle, eine Subscriber-ID in Ihrem CRM -, senden Sie ihn. GA4 verwendet ihn für Cross-Device-Attribution, und er verbessert das Matching zwischen serverseitigen und clientseitigen Events.

client_id-Verknüpfung: warum sie zählt und wie Elido sie handhabt

Die client_id ist das Feld, mit dem GA4 ein serverseitiges Event mit einer Browser-Session verknüpft. Wenn gtag.js auf einer Seite läuft, liest es das _ga-Cookie und verwendet dessen UUID als client_id für alle Events, die es feuert. Trägt Ihr serverseitiges Event dieselbe client_id, kann GA4 diese Events in dieselbe Nutzerreise und Session zusammenfügen.

Die Herausforderung ist, diese UUID auf die Serverseite zu bringen. Das _ga-Cookie ist ein First-Party-Cookie auf Ihrer Domain, Ihr Server kann es also zum Checkout-Zeitpunkt lesen und ins Conversion-Payload aufnehmen. Das funktioniert aber nur, wenn der Browser des Nutzers _ga gesetzt hat - also genau die Population, die Sie an ITP und Ad-Blocker verlieren.

Elido löst das auf der Redirect-Ebene noch nicht: Es setzt kein Cookie und hängt keine Klick-ID an die Ziel-URL an, und es leitet keine Conversions an GA4 weiter. Eine Klick-ID beim Redirect steht in unserem Backlog und ist nicht ausgeliefert. Bis dahin bauen Sie die Verknüpfung selbst, auf Ihrer eigenen Seite. Der Ablauf:

Ihre Landingpage oder Ihr Tag Manager liest den _ga-Wert, sofern vorhanden, oder erzeugt Ihre eigene First-Party-UUID, falls nicht, und schreibt ihn in die Custom Attributes der Bestellung. Zum Conversion-Zeitpunkt trägt Ihr Bestell-Webhook diesen Wert. Ihr Server baut das Measurement-Protocol-Payload mit client_id auf diesen Wert und sendet es an GA4.

Den Identifier zum Besuchszeitpunkt in die Bestellung zu schreiben ist zuverlässiger, als _ga beim Checkout zu lesen, denn selbst wenn ITP das Cookie innerhalb von 24 Stunden löscht, persistiert das Bestell-Attribut unabhängig davon in Ihrer Datenbank.

Der GA4 sending events guide (abgerufen am 12.05.2026) beschreibt, wie client_id über Client- und Server-Pfade hinweg funktioniert.

Elido forwarded: das tatsächliche curl

Elido baut dieses Payload für Käufe nicht zusammen und leitet es nicht weiter; Ihr eigener Server tut das, wenn Ihr Bestell-Webhook eintrifft. Der Aufruf, den er macht und den Sie auch von Hand ausführen können, um die GA4-Seite der Verdrahtung zu testen, sieht so aus:

curl -X POST \
  "https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "user_id": "user-shop-12847",
    "events": [
      {
        "name": "purchase",
        "params": {
          "transaction_id": "ord_98231",
          "value": 89.50,
          "currency": "EUR",
          "engagement_time_msec": 1
        }
      }
    ]
  }'

GA4 gibt sowohl für gültige als auch für ungültige Events 204 zurück. Sie können ein fehlerhaftes Event nicht allein am HTTP-Status-Code von einem erfolgreichen Ingest unterscheiden. Um zu sehen, ob das Event wohlgeformt ist, verwenden Sie während der Entwicklung den Debug-Endpoint:

POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET

Der Debug-Endpoint gibt einen JSON-Body zurück, der Validierungsfehler für jedes Event auflistet. Ein Event mit falschem Parameternamen, einem Payload, das 25 Params überschreitet, oder einer fehlerhaften client_id taucht hier auf. Einige davon werden erst sichtbar, wenn der Debug-Body validation_behavior auf ENFORCE_RECOMMENDATIONS setzt, und das API-Secret wird überhaupt nicht geprüft; der Leitfaden zum Debugging des Measurement Protocol beschreibt, was der Validator erfasst und was nicht.

Bei Nutzung von Elido führt Test connection in der GA4-Integration diese Prüfung für Sie aus und zeigt alle validationMessages als Fehler an. Ein sauberes Ergebnis sagt weiterhin nichts über das API-Secret aus. Darum folgt als Nächstes DebugView.

Validierung: DebugView

GA4s DebugView ist die schnellste Feedback-Schleife während des Setups. Um sie für serverseitige Events zu aktivieren, fügen Sie dem params-Objekt des Events "debug_mode": 1 hinzu. Events mit diesem Flag erscheinen innerhalb von rund zehn Sekunden in der DebugView; sie zählen nicht zu den produktiven Berichtsdaten.

In der DebugView (GA4 Admin → DebugView) zeigt jedes Event seinen Namen, die mitgetragenen Parameter und ob Parameter abgewiesen wurden. Die Ansicht gruppiert Events nach client_id, sodass Sie die volle Session vom Klick bis zur Conversion verfolgen können.

Was zu prüfen ist, bevor Sie debug_mode entfernen:

• Der Event-Name erscheint im DebugView-Event-Stream genau wie erwartet (purchase, nicht Purchase oder ecommerce_purchase).
• Der transaction_id-Parameter ist sichtbar und entspricht Ihrem Order-ID-Format.
• Die client_id ist eine UUID-formatierte Zeichenfolge - nicht leer, kein Fallback-String "unknown".
• Die currency ist der korrekte ISO 4217-Code (EUR, nicht eur, nicht Euro).

Standard-GA4-Berichte brauchen 24-48 Stunden, um serverseitige Conversion-Daten zu spiegeln. Bewerten Sie die Berichtsgenauigkeit nicht am ersten Tag. DebugView bestätigt die Event-Form; die Berichte bestätigen Attribution und Summen.

Häufige Fehler

Fehlende client_id. Events ohne client_id werden vom Measurement Protocol stillschweigend verworfen. Das ist der häufigste Einzelfehler. Der Verlust ist unsichtbar - die Anfrage gibt 204 zurück, DebugView zeigt nichts, die Conversion erscheint nie. Stellen Sie sicher, dass das Feld client_id immer befüllt ist, bevor die Anfrage feuert. Im obigen Setup heißt eine fehlende client_id, dass der Identifier zum Conversion-Zeitpunkt nicht in die Bestellung geschrieben wurde - prüfen Sie das Tag auf der Landingpage oder den Webhook-Handler.

Falsches Event-Namen-Format. Purchase erzeugt ein Custom Event namens Purchase neben allen bestehenden purchase-Events aus gtag. Ihre Gesamtzahl an Käufen in den GA4-Berichten teilt sich auf zwei Event-Namen auf. Die Lösung ist, lowercase snake_case auf allen Event-Namen zu erzwingen, die an den Measurement-Protocol-Endpoint gesendet werden. Die oben verlinkte GA4-Event-Referenz listet die kanonischen Namen für E-Commerce-Events.

Überschreiten von 25 event_params. Das Measurement Protocol weist Payloads mit mehr als 25 Parametern pro Event stillschweigend zurück. Teams, die volle Bestell-Metadaten (alle Positionen, alle Custom Attributes) weiterleiten, stoßen oft an dieses Limit, ohne es zu merken. Nutzen Sie den Debug-Endpoint im Modus ENFORCE_RECOMMENDATIONS, um Überläufe in der Entwicklung zu fangen. In Produktion: nicht-essentielle Parameter entfernen und Event-Payloads schlank halten.

Currency aus der Page-Config, nicht aus der Bestellung. Wenn Ihr gtag-Setup standardmäßig auf USD steht, Ihre Bestellungen aber in EUR sind, tragen serverseitiges und clientseitiges Event unterschiedliche Currency-Werte. GA4 erfasst sie unter demselben Event-Namen, kann die Werte aber nicht aggregieren. Beziehen Sie die Currency aus dem Bestelldatensatz im Backend, nicht aus einer seitenweiten gtag-Konfiguration.

Deduplikation mit clientseitigem gtag

Wenn Sie gtag.js clientseitig und das Measurement Protocol serverseitig gleichzeitig fahren wollen, brauchen Sie Deduplikation. GA4 dedupliziert Events über client_id in Kombination mit einem Zeitstempel-Fenster. Der Mechanismus ist weniger explizit als das event_id-Feld von Meta CAPI, aber der praktische Ansatz ist derselbe: tragen Sie eine konsistente transaction_id über beide Pfade hinweg auf Purchase-Events.

Für Purchase-Events: setzen Sie transaction_id auf Ihre Order-ID. Ihr browserseitiges gtag feuert purchase mit transaction_id: "ord_98231", wenn die Bestätigungsseite lädt; Ihr serverseitiges Measurement-Protocol-Event trägt dieselbe transaction_id: "ord_98231". GA4 dedupliziert innerhalb desselben Session-Fensters. Trifft dieselbe Kombination aus client_id + transaction_id innerhalb des Dedup-Fensters zweimal ein, wird die zweite ignoriert.

Für Upstream-Events - generate_lead, sign_up, add_to_cart - gibt es keine Order-ID. Ein von Ihnen erzeugter Besucher-Identifier funktioniert hier: setzen Sie event_id auf die UUID, die Sie auf Ihrer eigenen Seite gespeichert haben. Sowohl das browserseitige Pixel als auch der serverseitige Aufruf referenzieren denselben Wert. Das ist dieselbe Disziplin, die im end-to-end UTM tracking tutorial beschrieben wird, das das breitere Kampagnen-Tagging-Setup abdeckt, das Identifier durch den gesamten Funnel trägt.

Das Dedup-Fenster in GA4 ist nicht öffentlich mit der Präzision dokumentiert, die Meta für CAPI veröffentlicht. In der Praxis werden Events mit übereinstimmender client_id + transaction_id, die innerhalb desselben Session-Fensters eintreffen, dedupliziert. Beide Pfade gleichzeitig zu fahren ist die sicherere Konfiguration - sie bietet Fallback-Abdeckung für die Ad-Blocker-lastige Zielgruppe und liefert dem Algorithmus saubereres Signal aus dem Server-Pfad.

Wo das in die Attributionspipeline passt

Das Measurement Protocol schließt die GA4-Signal-Lücke auf dieselbe Weise, wie CAPI die Meta-Signal-Lücke schließt. Die Mechanismen unterscheiden sich - GA4 verwendet client_id und transaction_id, wo Meta event_id und Match-Keys verwendet -, aber die Architektur ist identisch: ein serverseitiges Event, das nicht vom Zustand des Browsers abhängt.

Für das Gesamtbild, welche Plattformen weiterzuleiten sind und wie Fan-out in Skalierung funktioniert, deckt die server-side conversion tracking overview GA4, Meta CAPI und TikTok Events Seite an Seite ab. Für Kampagnen, bei denen UTM-Tagging der vorgelagerte Schritt ist, ist tracking UTM campaigns end-to-end die Pflichtlektüre.

Die Produktoberfläche für dieses Setup: conversion tracking features dokumentiert, was heute ausgeliefert wird: Stripe- und Shopify-Käufe, die über elido_link_id dem Link zugeordnet werden. Die Weiterleitung von Käufen an GA4, Meta oder TikTok ist noch nicht verfügbar. Solutions for marketers zeigt, wie die Conversion-Pipeline in einen Kampagnen-Workflow neben UTM-Templates und Smart-Link-Routing passt.

Das Setup selbst - Credentials in Ihrer Server-Konfiguration, ein Tag-Manager-Schritt, der den Identifier auf der Landingpage speichert, Order-Webhook-Verkabelung - dauert für die meisten Teams einen halben Tag. Der DebugView-Validierungs-Schritt fügt weitere dreißig Minuten hinzu. Das Ergebnis sind GA4-Conversion-Daten, die das widerspiegeln, was Ihre Kampagnen tatsächlich treiben, nicht die 65-75 %, die den browserseitigen Pfad überleben.

Quellen

• Google Analytics 4: Measurement Protocol overview. developers.google.com/analytics/devguides/collection/protocol/ga4 (abgerufen am 12.05.2026)
• GA4 Measurement Protocol: Event reference. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (abgerufen am 12.05.2026)
• GA4 Measurement Protocol: Sending events. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (abgerufen am 12.05.2026)