GA4 Server-Side-Tracking ueber die Redirect-Ebene

GA4-Client-Side-Tagging via gtag.js oder GTM ist die Attributionsbasis, auf die die meisten Teams standardmaessig zurueckgreifen. 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 ausgeloest 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 Luecke auf EU-lastigen Zielgruppen liegt bei 25-35 % der Conversion-Events. Fuer manche Branchen - Fintech, Privacy-Tools, Dev-Tooling - laeuft sie hoeher, 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-Verknuepfung, Validierung und das Deduplikationsmuster fuer 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 eingefuegt.
• Die client_id ist das, was ein Server-Side-Event mit einer GA4-Session verknuepft; 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 fuellen sich ueber 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 uebergibst - sie ist kein Secret und erscheint im Seitenquelltext.

API Secret. Das ist der Credential, der serverseitige Schreibvorgaenge 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 fuegst du diese Werte unter Workspace Settings → Integrations → GA4 ein. Nach dem Speichern validiert Elido das Paar gegen den GA4-Debug-Endpoint und bestaetigt die Konnektivitaet. 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 traegt eine client_id, eine optionale user_id und ein events-Array. Hier das Payload fuer 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 (grosses 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 zaehlt GA4 das Event, schreibt der Session aber kein Engagement gut, und einige Attributionsmodelle schliessen Events ohne Engagement-Zeit aus. 1 zu setzen reicht, um die Anforderung zu erfuellen.

event_params ist auf 25 Parameter pro Event gedeckelt. Das Measurement Protocol weist Payloads zurueck, die das Limit ueberschreiten. Die Zurueckweisung erfolgt standardmaessig stillschweigend - die Anfrage gibt 204 ohne Body zurueck, unabhaengig davon, ob das Event akzeptiert wurde. Nutze den Debug-Endpoint (im Validierungsabschnitt behandelt), um Ueberlaeufe 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 fuer Cross-Device-Attribution, und er verbessert das Matching zwischen serverseitigen und clientseitigen Events.

client_id-Verknuepfung: warum sie zaehlt und wie Elido sie handhabt#

Die client_id ist das Feld, mit dem GA4 ein serverseitiges Event mit einer Browser-Session verknuepft. Wenn gtag.js auf einer Seite laeuft, liest es das _ga-Cookie und verwendet dessen UUID als client_id fuer alle Events, die es feuert. Traegt dein serverseitiges Event dieselbe client_id, kann GA4 diese Events in dieselbe Nutzerreise und Session zusammenfuegen.

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 loest 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 angehaengt (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 traegt dein Bestell-Webhook die UUID. Elido schlaegt sie nach, baut das Measurement-Protocol-Payload mit client_id auf diese UUID und leitet an GA4 weiter.

Das ist zuverlaessiger 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 ueberschreibt, persistiert Elidos _elido_cid-Cookie als First-Party-Cookie unter deiner Kurzlink-Domain - und das Bestell-Attribut persistiert unabhaengig davon in deiner Datenbank.

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

Elido forwarded: das tatsaechliche 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 fuer gueltige als auch fuer ungueltige Events 204 zurueck. Du kannst ein fehlerhaftes Event nicht allein am HTTP-Status-Code von einem erfolgreichen Ingest unterscheiden. Um zu sehen, ob das Event tatsaechlich gelandet ist, nutze waehrend 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 zurueck, der Validierungsfehler fuer jedes Event auflistet. Ein Event mit falschem Parameternamen, einem Payload, das 25 Params ueberschreitet, oder einer fehlerhaften client_id taucht hier auf.

Bei Nutzung von Elido ist dieselbe Validierungs-Sichtbarkeit ueber GET /v1/conversions/{id} verfuegbar - 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 waehrend des Setups. Um sie fuer serverseitige Events zu aktivieren, fuege dem params-Objekt des Events "debug_mode": 1 hinzu. Events mit diesem Flag erscheinen innerhalb von rund zehn Sekunden in der DebugView; sie zaehlen 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 pruefen 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 bestaetigt die Event-Form; die Berichte bestaetigen Attribution und Summen.

Haeufige Fehler#

Fehlende client_id. Events ohne client_id werden vom Measurement Protocol stillschweigend verworfen. Das ist der haeufigste Einzelfehler. Der Verlust ist unsichtbar - die Anfrage gibt 204 zurueck, DebugView zeigt nichts, die Conversion erscheint nie. Stelle sicher, dass das Feld client_id immer befuellt ist, bevor die Anfrage feuert. In Elidos Setup heisst eine fehlende client_id, dass der Parameter elido_click zum Conversion-Zeitpunkt nicht in die Bestellung geschrieben wurde - pruefe 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 Kaeufen in den GA4-Berichten teilt sich auf zwei Event-Namen auf. Die Loesung 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 fuer E-Commerce-Events.

Ueberschreiten von 25 event_params. Das Measurement Protocol weist Payloads mit mehr als 25 Parametern pro Event stillschweigend zurueck. Teams, die volle Bestell-Metadaten (alle Positionen, alle Custom Attributes) weiterleiten, stossen oft an dieses Limit, ohne es zu merken. Nutze den Debug-Endpoint, um Ueberlaeufe 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 standardmaessig 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 ueber 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 ueber beide Pfade hinweg auf Purchase-Events.

Fuer Purchase-Events: setze transaction_id auf deine Order-ID. Dein browserseitiges gtag feuert purchase mit transaction_id: "ord_98231", wenn die Bestaetigungsseite laedt; dein serverseitiges Measurement-Protocol-Event traegt 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.

Fuer 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 verfuegbar wird.

Das Dedup-Fenster in GA4 ist nicht oeffentlich mit der Praezision dokumentiert, die Meta fuer CAPI veroeffentlicht. In der Praxis werden Events mit uebereinstimmender client_id + transaction_id, die innerhalb desselben Session-Fensters eintreffen, dedupliziert. Beide Pfade gleichzeitig zu fahren ist die sicherere Konfiguration - sie bietet Fallback-Abdeckung fuer die Ad-Blocker-lastige Zielgruppe und liefert dem Algorithmus saubereres Signal aus dem Server-Pfad.

Wo das in die Attributionspipeline passt#

Das Measurement Protocol schliesst die GA4-Signal-Luecke auf dieselbe Weise, wie CAPI die Meta-Signal-Luecke schliesst. 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 abhaengt.

Fuer 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. Fuer Kampagnen, bei denen UTM-Tagging der vorgelagerte Schritt ist, ist tracking UTM campaigns end-to-end die Pflichtlektuere.

Die Produktoberflaeche fuer dieses Setup: conversion tracking features dokumentiert die komplette /v1/conversions-API, einschliesslich 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 fuer elido_click auf der Landingpage, Order-Webhook-Verkabelung - dauert fuer die meisten Teams einen halben Tag. Der DebugView-Validierungs-Schritt fuegt weitere dreissig Minuten hinzu. Das Ergebnis sind GA4-Conversion-Daten, die das widerspiegeln, was deine Kampagnen tatsaechlich treiben, nicht die 65-75 %, die den browserseitigen Pfad ueberleben.

---

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)