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. Dein 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 deinem Server ausgeht.
• Du brauchst zwei Credentials: die Measurement ID (G-XXXXXXXX) aus deinem Datenstream und ein API-Secret, das unter Admin → Data Streams → Measurement Protocol API secrets generiert wird. Beide werden in unter zwei Minuten in Elidos Workspace-Einstellungen eingefügt.
• Die client_id ist das, was ein Server-Side-Event mit einer GA4-Session verknüpft; Elido setzt beim Kurzlink-Redirect ein First-Party-UUID-Cookie und nimmt es in jeden weitergeleiteten Conversion-Forward auf - du musst das _ga-Cookie also nicht aus dem Browser lesen.
• 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 du brauchst

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

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

API Secret. Das ist der Credential, der serverseitige Schreibvorgänge gegen den Collection-Endpoint autorisiert. Navigiere zu Admin → Data Streams → dein Web-Stream → Measurement Protocol API secrets → Create. Das Secret ist eine kurze alphanumerische Zeichenfolge. Behandle es wie einen Service-Account-Key: speichere es als Workspace-Secret, rotiere es zusammen mit anderen Service-Credentials, committe es nicht in den Quellcode.

In Elido fügst du diese Werte unter Workspace Settings → Integrations → GA4 ein. Nach dem Speichern validiert Elido das Paar gegen den GA4-Debug-Endpoint und bestätigt die Konnektivität. Die Validierung erfolgt sofort; ein 4xx an dieser Stelle bedeutet, dass Measurement ID oder API-Secret falsch sind.

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. Sendest du Purchase (großes P), erzeugt das ein separates Event in den GA4-Berichten, statt mit deinen gtag-gefeuerten purchase-Events zu verschmelzen. Die Plattform warnt dich 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. Nutze den Debug-Endpoint (im Validierungsabschnitt behandelt), um Überläufe zu fangen.

user_id ist optional, aber wertvoll. Wenn du serverseitig einen persistenten Nutzer-Identifier hast - eine Kunden-ID in deiner Bestelltabelle, eine Subscriber-ID in deinem CRM -, sende 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 dein 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 deiner Domain, dein 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 du an ITP und Ad-Blocker verlierst.

Elido löst das auf der Redirect-Ebene. Wenn ein Nutzer auf einen Kurzlink klickt, generiert Elidos Edge-Handler eine UUID und setzt sie als First-Party-Cookie _elido_cid auf der Redirect-Antwort - bevor der Nutzer deine Seite erreicht. Die UUID wird auch als ?elido_click=<uuid> an die Ziel-URL angehängt (pro Workspace konfigurierbar). Der Ablauf:

Deine Landingpage oder dein Tag Manager liest elido_click aus der URL und schreibt es in die Custom Attributes der Bestellung. Zum Conversion-Zeitpunkt trägt dein Bestell-Webhook die UUID. Elido schlägt sie nach, baut das Measurement-Protocol-Payload mit client_id auf diese UUID und leitet an GA4 weiter.

Das ist zuverlässiger als _ga aus dem Browser zu lesen, weil die UUID zum Klickzeitpunkt erfasst wird, bevor die Browser-Session entscheidet, ob Cookies akzeptiert werden. Selbst wenn ITP das _ga-Cookie innerhalb von 24 Stunden überschreibt, persistiert Elidos _elido_cid-Cookie als First-Party-Cookie unter deiner Kurzlink-Domain - und das Bestell-Attribut persistiert unabhängig davon in deiner 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

Wenn POST /v1/conversions mit einer click_id eintrifft, baut Elido das Measurement-Protocol-Payload zusammen und leitet es weiter. Um den Endpoint direkt aufzurufen - Elido zu umgehen und nur die GA4-MP-Seite der Verdrahtung zu testen - sieht das curl 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. Du kannst ein fehlerhaftes Event nicht allein am HTTP-Status-Code von einem erfolgreichen Ingest unterscheiden. Um zu sehen, ob das Event tatsächlich gelandet ist, nutze 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.

Bei Nutzung von Elido ist dieselbe Validierungs-Sichtbarkeit über GET /v1/conversions/{id} verfügbar - der Conversion-Datensatz zeigt den GA4-Forward-Status und jede Fehlerantwort des Debug-Endpoints im Testmodus.

Validierung: DebugView

GA4s DebugView ist die schnellste Feedback-Schleife während des Setups. Um sie für serverseitige Events zu aktivieren, füge 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 du die volle Session vom Klick bis zur Conversion verfolgen kannst.

Was zu prüfen ist, bevor du debug_mode entfernst:

• 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 deinem 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. Bewerte 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. Stelle sicher, dass das Feld client_id immer befüllt ist, bevor die Anfrage feuert. In Elidos Setup heißt eine fehlende client_id, dass der Parameter elido_click zum Conversion-Zeitpunkt nicht in die Bestellung geschrieben wurde - prüfe 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. Deine 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. Nutze den Debug-Endpoint, 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 dein gtag-Setup standardmäßig auf USD steht, deine 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. Beziehe die Currency aus dem Bestelldatensatz im Backend, nicht aus einer seitenweiten gtag-Konfiguration.

Deduplikation mit clientseitigem gtag

Wenn du gtag.js clientseitig und das Measurement Protocol serverseitig gleichzeitig fahren willst, brauchst du 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: trage eine konsistente transaction_id über beide Pfade hinweg auf Purchase-Events.

Für Purchase-Events: setze transaction_id auf deine Order-ID. Dein browserseitiges gtag feuert purchase mit transaction_id: "ord_98231", wenn die Bestätigungsseite lädt; dein 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. Die Klick-ID funktioniert hier: setze event_id auf die elido_click-UUID. Sowohl das browserseitige Pixel als auch der serverseitige Forward referenzieren denselben Wert. Das ist dieselbe Disziplin, die im end-to-end UTM tracking tutorial beschrieben wird, das das breitere Kampagnen-Tagging-Setup abdeckt, mit dem diese ID durch den gesamten Funnel verfügbar wird.

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 die komplette /v1/conversions-API, einschließlich Multi-Plattform-Fan-out, Refund-Events und Retry-Semantik. 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 die Workspace-Einstellungen, Tag-Manager-Schritt für elido_click auf der Landingpage, 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 deine 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)