Was ist Server-Side-Tracking? Ein Leitfaden für Webshops

Server-Side-Tracking bedeutet, dass Conversion-Events, etwa ein Kauf, von einem Server an Werbeplattformen gesendet werden, statt nur von einem Skript im Browser des Käufers. Bei einem Webshop sendet der Server jede Bestellung über deren APIs an Meta, TikTok oder Google, sodass der Verkauf auch dann gemeldet wird, wenn das Browser-Pixel blockiert wird oder nie lädt.

Dieser Leitfaden erklärt den Unterschied zwischen einem Browser-Pixel und Server-Side-Tracking, folgt den Daten vom Anzeigenklick bis zur Werbeplattform und zeigt, was ein Server-Event enthält. Außerdem geht er auf Deduplizierung, Server-Side-Tagging, Einwilligung und die Frage ein, woran du erkennst, ob dein Shop es braucht. Für die Einrichtung in Shopify selbst lies Server-Side-Tracking auf Shopify.

Browser-Pixel und Server-Side-Tracking im Vergleich

Ein Browser-Pixel ist ein Stück JavaScript der Werbeplattform. Es läuft auf deinen Seiten und sendet Events vom Gerät des Käufers direkt an die Plattform: einen Seitenaufruf, ein Hinzufügen zum Warenkorb, einen Kauf auf der Dankeseite. Es funktioniert nur, wenn das Skript lädt, läuft und die Plattform erreicht, bevor der Käufer die Seite verlässt.

Server-Side-Tracking verlagert das Senden auf einen Server. Das Event kann von Daten ausgehen, die dein Shop schon hat, etwa einer bezahlten Bestellung, und der Server sendet es an die API der Plattform. Meta nennt diese API Conversions API, TikTok nennt sie Events API. Google Ads nutzt erweiterte Conversions, die einer Conversion gehashte Kundendaten hinzufügen.

Wenn du beide nutzt, hat die Plattform die vollständigsten Daten. Das Browser-Event liefert Cookies und Seitenkontext. Das Server-Event kommt auch dann an, wenn der Browser versagt. Eine gemeinsame Event-ID sorgt dafür, dass die Plattform jeden Kauf nur einmal zählt.

Wie funktioniert Server-Side-Tracking?

Server-Side-Tracking für einen Webshop hat zwei Hälften. Die erste passiert im Browser: Wenn ein Käufer über eine Anzeige landet, speichert ein Skript die Click-ID aus der URL. Die zweite passiert auf dem Server: Wenn die Bestellung bezahlt ist, verknüpft der Server diese Click-ID mit der Bestellung und sendet den Kauf.

Den Klick erfassen

Werbeplattformen hängen eine Click-ID an die Landing-URL an: fbclid bei Meta, ttclid bei TikTok, gclid bei Google Ads und msclkid bei Microsoft Ads. Die Click-ID ist die stärkste Verbindung zwischen einem Verkauf und der Anzeige, die ihn ausgelöst hat, deshalb muss sie beim ersten Seitenaufruf gespeichert werden. UTM-Parameter ergänzen die Namen von Kampagne, Anzeigengruppe und Anzeige in einem Format, das du selbst bestimmst.

Die Bestellung zuordnen

Der Server muss dann wissen, welcher Besucher die Bestellung aufgegeben hat. Die zuverlässigste Verbindung ist ein Wert, der mit dem Warenkorb in die Bestellung wandert, etwa eine im Warenkorb gespeicherte Besucher-ID. Andere Methoden sind schwächer: eine E-Mail-Adresse, die der Besucher zuvor auf der Seite eingegeben hat, oder dieselbe IP-Adresse und derselbe Browser kurz vor der Bestellung. Jede Webshop-Plattform bietet andere Möglichkeiten. Unser Leitfaden für andere Webshops listet die Methoden auf, die ROASaurus je Plattform nutzt.

Das Event senden

Zum Schluss sendet der Server den Kauf an die API jeder Plattform. Das Event enthält den Bestellwert, die Click-ID und Kundendaten, mit denen die Plattform die Person findet, die geklickt hat. Wenn eine Plattform nicht erreichbar ist oder einen Fehler zurückgibt, versucht ein gutes Setup es später erneut, damit der Kauf nicht verloren geht.

Was enthält ein Server-Event?

Jede Plattform hat eigene Feldnamen, aber ein Purchase-Event enthält überall dieselben Arten von Daten. Hier ein gekürztes Beispiel für die Meta Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Beim Hashen wird aus einer E-Mail-Adresse eine Zeichenfolge fester Länge. Dieselbe Adresse ergibt immer dieselbe Zeichenfolge, aber die Zeichenfolge verrät die Adresse nicht. Die Plattform nutzt die gehashten Werte nur, um unter ihren eigenen Nutzern nach einer Übereinstimmung zu suchen. So lässt sich ein Kauf der Person zuordnen, die die Anzeige gesehen oder angeklickt hat, auch wenn deren Browser das Pixel blockiert hat.

Wie funktioniert die Deduplizierung?

Wenn das Pixel und der Server denselben Kauf senden, muss die Plattform ihn einmal zählen. Beide Kopien tragen denselben Eventnamen und dieselbe Event-ID, zum Beispiel order-1042. Meta vergleicht das Paar und behält eine Kopie, solange die zweite Kopie innerhalb von 48 Stunden nach der ersten eintrifft.

Die meisten Doppelzählungen entstehen durch zwei Sender, die keine IDs teilen. Ein typischer Fall sind die Shop-App einer Plattform und ein separates Tracking-Tool, die beide Käufe mit ihren eigenen IDs senden. Unser Hilfeartikel zum Vermeiden von Doppelzählungen listet die üblichen Ursachen und Lösungen auf.

Server-Side-Tagging und Senden aus Bestelldaten im Vergleich

Der Begriff Server-Side-Tracking wird für zwei verschiedene Setups verwendet. Beide senden Events von einem Server, aber sie beginnen an unterschiedlichen Stellen.

Server-Side-Tagging, etwa mit Google-Tag-Manager-Server-Containern

Beim Server-Side-Tagging sendet der Browser seine Events an deinen eigenen Server statt an jeden Anbieter einzeln. Der Server-Container des Google Tag Managers ist ein bekanntes Beispiel. Er läuft in deinem eigenen Google-Cloud-Projekt oder in einer anderen Umgebung, die du wählst. Er empfängt Anfragen vom Browser, und seine Tags leiten die Daten an Google Analytics, Meta und andere Anbieter weiter. Du bestimmst, welche Daten wohin gehen, und der Server kann auf einer Subdomain deiner Website laufen.

Die Events beginnen weiterhin im Browser. Wird das Tag im Browser blockiert oder lädt die Dankeseite nie, hat der Server-Container nichts weiterzuleiten. Außerdem betreibst, bezahlst und aktualisierst du den Server selbst.

Senden aus Bestelldaten

Der zweite Ansatz lässt den Kauf von der Bestellung in deinem Shop ausgehen. Der Shop meldet die bezahlte Bestellung per Webhook oder API an den Server, und der Server sendet sie an jede verbundene Plattform. Der Browser wird nur früher gebraucht, um die Click-ID zu speichern, wenn der Käufer landet.

Die beiden Ansätze lassen sich kombinieren. Viele Shops erfassen Seitenaufrufe und Add-to-Cart-Events im Browser und senden den Kauf aus den Bestelldaten. Der Kauf ist das Event, mit dem Werbeplattformen den ROAS melden und das Bieten optimieren, deshalb muss er am dringendsten vollständig sein.

Was löst Server-Side-Tracking, und was löst es nicht?

Die Einwilligung gilt weiterhin

Server-Side-Tracking ist eine Art, Daten zu übermitteln, kein Weg, Datenschutzregeln zu umgehen. Wo das Gesetz eine Einwilligung für Marketing-Cookies oder Tracking verlangt, gilt diese Anforderung für die Daten, die du erfasst, auf welchem Weg sie auch zur Plattform gelangen. Wenn du einen Tracker auf deinen Server verlegst, ändert das nichts daran, wozu ein Besucher zugestimmt hat.

Die Attribution bleibt plattformspezifisch

Jede Plattform schreibt Käufe weiterhin mit ihren eigenen Fenstern und Regeln gut. Server-Events geben jeder Plattform bessere Daten, aber die Summen von Meta, TikTok und Google können zusammen immer noch mehr ergeben als der Umsatz deines Shops. Um Kanäle nach einem einheitlichen Regelwerk zu vergleichen, nutze über alle ein einziges Attributionsmodell, etwa die Modelle der ROASaurus-Attribution.

Braucht dein Shop Server-Side-Tracking?

Ein Shop, der ein nennenswertes Budget für Paid-Social- oder Suchanzeigen ausgibt, profitiert in der Regel davon. Am stärksten ist der Fall, wenn mehrere dieser Punkte zutreffen:

• Die Werbeplattform erhält deutlich weniger Purchase-Events, als dein Shop Web-Bestellungen hat. Unser Leitfaden zu Adblockern und Tracking zeigt, wie du diese Lücke misst.
• Viele deiner Besucher nutzen Safari auf dem iPhone oder Mac, wo von Skripten gesetzte Cookies höchstens 7 Tage halten. Siehe Safari ITP und Anzeigen-Tracking.
• Käufer kaufen oft erst Tage nach dem ersten Anzeigenklick.
• Die Zahlung wird außerhalb deiner Seite abgeschlossen oder Bestellungen werden später bezahlt, etwa bei Nachnahme oder Banküberweisung.
• Du optimierst Kampagnen auf Käufe oder Kaufwert, daher braucht die Plattform jeden Verkauf, um daraus zu lernen.

So verändert eine Lücke Entscheidungen in der Praxis. Ein Beispiel-Shop hat in einem Monat 1,000 Web-Bestellungen. Sein Meta-Pixel hat 820 Purchase-Events gemeldet, also haben 18% der Bestellungen Meta nie aus dem Browser erreicht.

Der Break-even-ROAS des Shops liegt bei 2.5, und der Ads Manager zeigt auf Basis der Pixeldaten einen ROAS von 2.3. Nach diesen Zahlen verlieren die Kampagnen Geld. Wären durch Anzeigen ausgelöste Bestellungen mit derselben Quote von 18% verpasst worden, läge der echte ROAS bei etwa 2.3 ÷ 0.82 = 2.8, also über dem Break-even. Das ist eine obere Schätzung, weil nicht jede fehlende Bestellung von einer Anzeige kam. Sie zeigt trotzdem, wie eine Tracking-Lücke eine profitable Kampagne wie einen Verlust aussehen lassen kann.

Für einen Shop, der keine Werbung schaltet oder nur sehr wenig für Anzeigen ausgibt, spielt Server-Side-Tracking eine geringere Rolle.

So sendet ROASaurus Server-Events

ROASaurus erfasst beim Landen 19 Click-IDs und sechs UTM-Felder und speichert sie mit einer First-Party-Besucher-ID. Es sendet jeden Kauf aus den bezahlten Bestellungen deines Shops an Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll und Outbrain. Auf Shopify werden Google-Ads-Conversions aus dem Shopify-Checkout gesendet. Browser-Pixel können mit derselben Event-ID neben den Server-Events laufen, und Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin und Spotify deduplizieren sie. Jede Zustellung und die Antwort der Plattform stehen im Event log.

Mehr dazu findest du auf der Seite Server-Side-Tracking, oder suche deinen Webshop auf der Seite Integrationen.

Quellen

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

In ROASaurus

• Server-Side-Tracking in ROASaurus
• Einwilligung und Datenschutz
• Doppelzählungen vermeiden

Weiterlesen