Server Side Tracking: der technische Guide, um deine kaputte Analytics zu reparieren

Was Server Side Tracking repariert, und was nicht

Beim Server Side Tracking steht ein Server, den du kontrollierst, zwischen dem Browser deiner Besucher und den Werbeplattformen. Der Browser schickt seine Events an deinen Server, und dein Server entscheidet, was über die offiziellen Schnittstellen an Google, Meta und die anderen weitergeht. Sauber gebaut bekommst du sauberere Daten, dauerhafte First Party Cookies dort, wo die Besucher zugestimmt haben, Conversions direkt aus der Bestellung statt aus einer Seite, die vielleicht nie lädt, und volle Kontrolle darüber, welche Parameter deine Domain verlassen.

Was es nicht ändert: ob du eine Einwilligung brauchst. Der Browser führt weiterhin Code aus, der Informationen an deinen Server schickt, und dieser Schritt fällt unter dasselbe Gesetz wie jedes Pixel. Die ehrliche Reihenfolge lautet also: zuerst fragen, dann leitet der Server nur weiter, was die Entscheidung des Besuchers erlaubt.

Die frühere Fassung dieses Artikels begann mit der Behauptung, Browser Pixel würden 30 bis 50 % der Conversions verpassen, und verkaufte Server Side Tracking als etwas, das Ad Blocker nicht aufhalten können. Für die Zahl habe ich keine Quelle gefunden, und die zweite Erzählung verwende ich nicht. Beides ist raus. Stattdessen stehen hier der Mechanismus, die Dokumentation der Anbieter und ein Beispiel, das vollständig durchgerechnet ist.

Ein erfundenes Unternehmen trägt alle Beispiele. Donauspeiche ist ein Shop für Radbekleidung in Linz, geführt von Theresa, online unter donauspeiche.example. Alle Zahlen dazu sind erfunden. Das Recht und die Dokumentation der Anbieter nicht, sie sind mit Fußnoten belegt.

Warum Browser Tags Conversions verlieren

Zwischen einem Verkauf und dem Bericht der Werbeplattform stehen drei Dinge, und nur eines davon ist ein technischer Fehler.

Das erste ist das Banner. Wer Werbecookies ablehnt, soll für Werbezwecke nicht gemessen werden, und die Plattform soll den Verkauf nicht sehen. Das ist kein Leck, das man stopft. Das ist das Gesetz, das funktioniert, und meistens ist es die größte Lücke.

Das zweite ist der Browser. Safaris Intelligent Tracking Prevention löscht Cookies, die per JavaScript gesetzt wurden, und jeden anderen Speicher, den ein Script beschreiben kann, nach sieben Tagen ohne Interaktion mit der Website. Kommt der Besucher über einen Link mit Klick ID, sind per JavaScript gesetzte Cookies auf dieser Landingpage auf 24 Stunden begrenzt.¹ Eine Klick ID von Google oder Meta, die ein Tag speichert, ist genau so ein Cookie. Firefox trennt Cookies seit Juni 2022 für alle Nutzer standardmäßig pro Website, mit Total Cookie Protection.²

Das dritte ist die Verrohrung. Der Zahlungsanbieter schickt die Käuferin zurück auf eine Bestätigungsseite, die nie fertig lädt, der Tab wird geschlossen, bevor das Tag gefeuert hat, oder ein Content Blocker stoppt die Anfrage. Die Bestellung steht in der Datenbank des Shops. Der Browser hat es nur niemandem erzählt.

Die alte Fassung machte auch Apples App Tracking Transparency verantwortlich. Dieses Framework regelt Apps, keine Websites, deshalb habe ich es gestrichen.

Was sich ändert, wenn ein Server in der Mitte sitzt

Im klassischen Aufbau lädt die Seite das Tag jedes Anbieters, und jedes Tag schickt Daten direkt aus dem Browser an seinen Anbieter. Beim Server Side Tagging schickt die Seite einen einzigen Strom von Events an einen Tagging Server auf deiner eigenen Domain. Ein Client in diesem Server macht aus jeder Anfrage ein Event, und Server Tags leiten an jeden Anbieter weiter, was du erlaubst. Google empfiehlt, den Server auf der eigenen First Party Domain zu betreiben, und schreibt, dass du steuerst, wie die Daten aussehen und wohin sie gehen, und dass nur du Zugriff auf die Daten im Server hast, bis du sie weiterschickst.³

Lies den Ablauf von oben. Das Banner kommt, bevor irgendetwas gesendet wird. Die Entscheidung ist der Server, der die Wahl des Besuchers anwendet, und die beiden Zweige treffen sich nie wieder: Eine abgelehnte Bestellung erreicht keine Werbeplattform durch die Hintertür. Das letzte Feld erinnert daran, dass die eigene Datenbank jede Bestellung zählt, egal was darüber passiert ist.

Server Side verschiebt die Einwilligungsfrage nicht

Die Leitlinien des Europäischen Datenschutzausschusses zum technischen Anwendungsbereich der ePrivacy Regel sind hier eindeutig. Wenn Software auf dem Gerät einen API Endpunkt aufruft oder JavaScript den Browser anweist, asynchrone Anfragen mit den gewünschten Informationen zu senden, fällt dieser Zugriff klar unter Artikel 5 Absatz 3.⁴ Tracking Pixel zählen ebenso: Der Ausschuss behandelt das Erheben von Kennungen über sie als Zugriff.⁴ Ein Event, das der Browser an track.donauspeiche.example statt an Meta schickt, ist immer noch ein Event, das der Browser auf Anweisung schickt.

In Österreich steht das in § 165 Absatz 3 TKG 2021. Eine Ermittlung dieser Daten ist nur zulässig, wenn der Nutzer seine Einwilligung aktiv und auf Grundlage klarer und umfassender Informationen erteilt hat. Ausgenommen sind nur die technische Speicherung oder der Zugang zur Übertragung einer Nachricht und das, was unbedingt erforderlich ist, damit ein ausdrücklich gewünschter Dienst bereitgestellt werden kann.⁵ Ein Conversion Tag für Werbung ist das nicht. Verkauft ein Linzer Shop nach Deutschland, gilt dort § 25 TDDDG mit derselben Struktur.⁶ Wie Österreich und Deutschland sich vom Vereinigten Königreich unterscheiden und warum die Aufsicht hier strenger ist, steht im Artikel über Cookies, Consent und das ePrivacy Chaos in DACH.

Server Side Tracking ist also kein Weg an der Einwilligung vorbei. Der Client fragt weiterhin, bevor er etwas auf dem Gerät setzt oder ausliest, und der Server leitet nur weiter, was der Einwilligungsstatus erlaubt.

Basismodus oder erweiterter Modus

Googles Einwilligungsmodus trägt die Antwort aus dem Banner zu Googles Tags, und es gibt ihn in zwei Formen. Im Basismodus laden Googles Tags erst, wenn der Besucher mit dem Banner interagiert hat, und bei einer Ablehnung geht nichts an Google. Im erweiterten Modus laden die Tags sofort, mit abgelehnter Einwilligung als Standard, und senden, solange sie abgelehnt bleibt, cookielose Pings, die Google für Modellierung nutzt.⁷ Googles Anleitung für Server Side Tagging bestätigt, dass im Basismodus keine Analytics Cookies gesetzt, gelesen oder abgerufen werden, weder auf dem Client noch auf dem Server.⁸

In Österreich baue ich deshalb den Basismodus. Den erweiterten Modus schalte ich nur ein, wenn der Anwalt des Shops das schriftlich empfohlen hat. Der vollständige Aufbau in der Reihenfolge, die funktioniert, steht in Event Tracking und Consent Mode.

Die Einwilligung reist mit jedem Event

In einem Google Tag Manager Setup fährt der Einwilligungsstatus mit jeder Anfrage mit. Das Banner gibt die Wahl an das Google Tag, das Google Tag hängt Einwilligungsparameter an die HTTP Anfrage an deinen Server, und Googles eigene Produkt Tags im Server Container berücksichtigen die Einwilligung und passen an, was sie senden. Google schreibt dazu, dass du den Einwilligungsmodus deshalb nur im Web Container einrichten musst.⁸

Dieser Satz gilt für Googles eigene Tags, und über Vorlagen von Drittanbietern sagt Google nichts Vergleichbares. Ein Meta Tag im Server Container behandle ich deshalb als blind für die Einwilligung, bis ich ihm eine Bedingung gebe: Es feuert nur bei erteilter Werbeeinwilligung. In einem eigenen Aufbau prüft der Server selbst vor jeder Weiterleitung.

Beispiel: die Weiterleitungsregel von Donauspeiche

Wenn eine Bestellung abgeschlossen ist, kennt Theresas Backend drei Dinge: die Bestellung, den Einwilligungsstatus, den das Banner für diesen Besucher gespeichert hat, und sonst nichts. So sieht die Regel aus, geschrieben für die nächste Person, die sie anfasst:

// Läuft einmal pro abgeschlossener Bestellung, im Shop Backend oder auf dem Tag Server
function routeOrder(order) {
  const ads = order.consent.ad_storage === 'granted' && order.consent.ad_user_data === 'granted'
  const analytics = order.consent.analytics_storage === 'granted'

  if (ads) {
    sendToMeta({ event_name: 'Purchase', event_id: order.number, order })
    sendToGoogleAds({ transaction_id: order.number, order })
  }
  if (analytics) {
    sendToGA4({ name: 'purchase', transaction_id: order.number, order })
  }
  if (!ads) {
    // Abgelehnt: umbenannt, keine Kennungen, bleibt im eigenen Reporting
    ownReport.record({ name: 'purchase_nc', value: order.itemTotal, currency: 'EUR', day: order.day })
  }
}

Der Zweig für Ablehnungen ist die Regel, die ich auf jeder Website anwende, die ich baue, und ich formuliere sie als meine Praxis, nicht als Auslegung des Gesetzes. Eine Bestellung von jemandem, der Werbung abgelehnt hat, heißt purchase_nc. Sie trägt keine Klick ID, keine Cookie ID, keine gehashte Mailadresse, keine IP Adresse und keinen User Agent. Sie wird nie auf eine Conversion Aktion gemappt, nie zur Optimierung genutzt und ist nie für eine Zielgruppe oder für Retargeting zugelassen. Sie existiert, damit die Summe im eigenen Bericht des Shops zur Datenbank passt, und für nichts sonst. Ich halte sie in den eigenen Systemen des Shops: Die Werbeplattformen sehen nichts davon.

Warum ein neuer Name statt eines Merkmals: Die Leute, die Werbekonten betreuen, wechseln, und ein anderer Eventname lässt sich viel schwerer versehentlich missbrauchen als eine Einstellung, die jemand vergessen hat.

Der Aufbau mit Google Tag Manager Server Side

Der Server Container von Google Tag Manager ist der übliche Weg, und Google dokumentiert jeden Schritt.

Der Tagging Server

Du legst in Tag Manager einen neuen Container mit Server als Zielplattform an und stellst dann den Server bereit. Am einfachsten geht das mit Google Cloud Run. Google beziffert jeden Server auf ungefähr 45 US Dollar im Monat, als Cloud Run Instanz mit einer vCPU und 0,5 GB Arbeitsspeicher, empfiehlt mindestens zwei Instanzen, damit bei einem Ausfall keine Daten verloren gehen, und erwartet, dass zwei bis 10 Server je nach Tags 35 bis 350 Anfragen pro Sekunde schaffen.⁹ Google warnt außerdem, dass das Request Logging ab etwa einer Million Anfragen im Monat spürbar Geld kosten kann, und schlägt vor, es abzuschalten.⁹

Wer eigene Infrastruktur betreibt: Der Tagging Server ist ein Docker Image unter gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable, und dasselbe Image dient mit anderen Einstellungen als Preview Server.¹⁰ Google aktualisiert das Image regelmäßig, also muss auch, wer es betreibt, es regelmäßig aktualisieren.¹⁰

Die Domain, und was Safari daraus macht

Googles Anleitung zur eigenen Domain nennt für eine Website unter www.example.com drei Möglichkeiten: denselben Ursprung, etwa https://www.example.com/metrics, den Google als Best Practice bezeichnet, eine Subdomain wie https://metrics.example.com, und die Standarddomain des Cloud Anbieters, die im Drittanbieterkontext läuft und nur JavaScript Cookies setzen kann.¹¹ In Googles Tabelle hat die Subdomain vollen Zugriff auf serverseitig gesetzte Cookies.

Safari sieht das anders. WebKit begrenzt jedes Cookie, das in einer HTTP Antwort gesetzt wird, auf sieben Tage, wenn die Anfrage an eine First Party Subdomain geht, die über einen CNAME auf einen anderen Host zeigt, oder an einen Server mit einer IP Adresse eines Dritten.¹ Eine Subdomain, die auf einen Cloud Host zeigt, ist genau das. Wenn dir dauerhafte Cookies wichtig sind, hält in Safari also nur der Weg über denselben Ursprung: ein Pfad auf deiner Hauptdomain, ausgeliefert über denselben Load Balancer oder dasselbe CDN wie die Website.

Ein dauerhaftes Cookie ist nur zulässig, wenn der Besucher dem Zweck zugestimmt hat. Die Domain entscheidet, wie lange ein Cookie mit Einwilligung hält. Sie entscheidet nicht, ob du eines setzen darfst.

Den Web Container auf den Server zeigen lassen

Im Web Container sagst du dem Google Tag, dass es an die URL deines Server Containers senden soll, in gtag.js über die Option server_container_url.³ Google empfiehlt, über das Google Analytics Tag an den Server zu senden, weil es mehrere Übertragungswege nutzen kann, und nennt die Einträge in der Content Security Policy, die deine Website braucht, damit diese Anfragen nicht von deiner eigenen Seite blockiert werden.¹²

Im Server übernimmt ein Client jede eingehende Anfrage und macht daraus ein Event. Der GA4 Client verarbeitet Anfragen im Google Format. Bevor ein Tag das Event sieht, kannst du mit Transformationen nur benannte Parameter zulassen, Parameter ändern oder ergänzen, oder Parameter von Tags ausschließen, für alle Tags oder nur für einige.¹³ An dieser Stelle entferne ich die IP Adresse und alles, was einen Anbieter nichts angeht.

Beispiel: was der Server von Donauspeiche kostet

Theresas Website hat etwa 1.500 Sitzungen am Tag mit rund 15 Events pro Sitzung, also $1{.}500 \times 15 = 22{.}500$ Events am Tag. Verteilt auf $86{.}400$ Sekunden sind das $22{.}500 / 86{.}400 \approx 0{,}26$ Anfragen pro Sekunde, weit unter den 35, die Google zwei Servern zutraut. Zwei Instanzen sind schlicht Googles Untergrenze. Kosten: $2 \times 45 = 90$ US Dollar im Monat, in Dollar abgerechnet, vor Kosten für den Datenverkehr. Mit $22{.}500 \times 30 = 675{.}000$ Anfragen im Monat bleibt sie unter der Million, ab der Google das Abschalten des Request Loggings empfiehlt, und kann es vorerst behalten.

Google Ads und GA4 vom Server

Google Ads Conversions und erweiterte Conversions

Das Google Ads Conversion Tag läuft im Server Container und braucht dort auch das Conversion Linker Tag. Ist ad_storage abgelehnt, schreibt und liest Google nach eigener Aussage keine Ads Cookies.⁸

Erweiterte Conversions hängen eine gehashte Mailadresse oder Telefonnummer an eine Conversion, damit Google sie einem angemeldeten Konto zuordnen kann. Die Daten werden vor dem Senden mit SHA256 gehasht.¹⁴ Hashing ist keine Anonymisierung, und Google behandelt es auch so: Im Server Container funktionieren erweiterte Conversions nur bei erteilter Einwilligung,⁸ und ist ad_user_data abgelehnt, werden keine personenbezogenen Daten für Werbung gesendet.⁷

Server Events für GA4

Das Measurement Protocol schickt Events direkt an GA4, von Server zu Server. Das passt für Erstattungen, Offline Verkäufe und alles, was ohne Seite passiert. Google beschreibt seinen Platz klar: Es ergänzt die Erfassung über gtag, Tag Manager oder Firebase und ersetzt sie nicht, und wer nur über das Measurement Protocol sendet, bekommt unter Umständen nur teilweise Berichte.¹⁵

Jede Anfrage braucht ein API Secret aus den Einstellungen des Datenstroms. Events lassen sich bis zu 72 Stunden rückdatieren. Ein consent Objekt trägt ad_user_data und ad_personalization, und lässt du es weg, nimmt GA4 die Einwilligungseinstellungen aus den Online Interaktionen des Besuchers.¹⁶ Ich setze es bei jeder Anfrage ausdrücklich, damit der Server sich nie auf einen Standard verlässt, den er nicht sieht.

Käufe vom Server an Meta senden

Metas Conversions API nimmt Events von deinem Server entgegen. Ein Kauf sieht so aus:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1792852200,
      "event_id": "DS10482",
      "action_source": "website",
      "event_source_url": "https://donauspeiche.example/checkout/complete",
      "user_data": {
        "em": ["<sha256 der normalisierten Mailadresse>"],
        "ph": ["<sha256 der normalisierten Telefonnummer>"],
        "client_ip_address": "203.0.113.24",
        "client_user_agent": "<User Agent des Browsers>",
        "fbc": "fb.1.1792850400000.<fbclid>",
        "fbp": "fb.1.1792850400000.1234567890"
      },
      "custom_data": { "currency": "EUR", "value": 89.00 }
    }
  ]
}

Was jeder Teil sein muss, laut Metas Parameterreferenz: action_source ist Pflicht. event_time ist ein Unix Zeitstempel in Sekunden und darf bis zu sieben Tage vor dem Senden liegen. Ist ein Event im Paket älter, gibt Meta für die ganze Anfrage einen Fehler zurück und verarbeitet keines davon.¹⁷

Die Kundenfelder gibt es in zwei Sorten. Mailadresse und Telefonnummer müssen mit SHA256 gehasht werden. Vor dem Hashen wird eine Mailadresse von Leerzeichen am Anfang und Ende befreit und kleingeschrieben, und eine Telefonnummer verliert Symbole, Buchstaben und führende Nullen und muss die Ländervorwahl enthalten. IP Adresse, User Agent, fbc und fbp gehen ungehasht. fbc hat das Format fb. plus Subdomain Index, Erstellungszeit und die fbclid aus der Landing URL.¹⁸

In Node ist das Hashen ein paar Zeilen:

const crypto = require('crypto')

const sha256 = (s) => crypto.createHash('sha256').update(s).digest('hex')
const normaliseEmail = (e) => e.trim().toLowerCase()
const normalisePhone = (p) => p.replace(/\D/g, '').replace(/^0+/, '')

// Österreichische Nummer: führende Null weg, Ländervorwahl 43 davor
const atPhone = (p) => '43' + normalisePhone(p)

Nichts in der Conversions API filtert für dich nach Einwilligung. Alles in diesem Paket sind personenbezogene Daten für Werbezwecke, also sendet der Server sie nur für Besucher, die in Werbung eingewilligt haben. Das ist die Weiterleitungsregel von oben, und sie ist nicht optional.

Deduplizierung: jeden Verkauf einmal zählen

Schicken Browser Pixel und Server denselben Kauf, bekommt Meta ihn doppelt. Meta empfiehlt, Pixel und Conversions API gemeinsam zu betreiben, nennt das ein redundantes Setup und schreibt, dass du in diesem Fall eine Deduplizierung einrichten musst.¹⁹

Die empfohlene Methode sind Event ID und Eventname. Die eventID des Pixels muss zur event_id des Servers passen, und das Event des Pixels zum event_name des Servers. Meta dedupliziert passende Events, die innerhalb von 48 Stunden nach dem ersten Event mit dieser ID eintreffen.¹⁹ Die ID muss also an beiden Stellen derselbe Wert sein, und das heißt: einmal erzeugen. Die Bestellnummer bietet sich an, eindeutig pro Verkauf und sowohl dem Browser auf der Bestätigungsseite als auch dem Server bekannt.

Auf der Pixel Seite ist das ein viertes Argument:

fbq('track', 'Purchase', { value: 89.00, currency: 'EUR' }, { eventID: 'DS10482' })

Beide Sendungen passieren nur nach erteilter Werbeeinwilligung. Ohne sie senden weder Pixel noch Server etwas.

Beispiel: Donauspeiches Oktober, doppelt und einfach gezählt

Im Oktober erzeugen Theresas Käufer mit Einwilligung 527 Kaufevents über das Pixel und 620 über den Server. Jeden Verkauf, den das Pixel gesehen hat, hat auch der Server gesehen. Was Meta berichtet, hängt davon ab, ob die IDs passen:

$$C_{\text{berichtet}} = C_{\text{Browser}} + C_{\text{Server}} - C_{\text{beide}}$$

Dabei ist $C_{\text{berichtet}}$ die Zahl der Käufe, die Meta zählt, $C_{\text{Browser}}$ die Zahl, die vom Pixel ankommt, $C_{\text{Server}}$ die Zahl vom Server, und $C_{\text{beide}}$ die Zahl, die Meta als denselben doppelt angekommenen Verkauf erkannt hat. Zwei Zählungen addieren und die Überschneidung abziehen ist die Zählregel hinter Grundlagen: Wahrscheinlichkeit.

Ohne passende IDs erkennt Meta keine Überschneidung, also $C_{\text{beide}} = 0$, und der Bericht zeigt $527 + 620 = 1{.}147$ Käufe, fast das Doppelte der Wahrheit. Mit der Bestellnummer als ID auf beiden Seiten ist $C_{\text{beide}} = 527$, und der Bericht zeigt $527 + 620 - 527 = 620$. Der Return on Ad Spend sähe im ersten Fall großartig aus und hieße nichts.

Was der Server zurückholen kann, und die Decke, die er nicht durchbricht

Die nützliche Frage ist nicht, wie viele Conversions Server Side Tracking dazubringt, sondern wie viele höchstens. Die Antwort setzt das Banner, nicht der Server:

$$C_{\max} = r \times O$$

$C_{\max}$ ist die größte Zahl von Käufen, die die Werbeplattformen rechtmäßig bekommen dürfen, $r$ der Anteil der Bestellungen mit Werbeeinwilligung und $O$ die Zahl der Bestellungen in der Datenbank des Shops. Einen Anteil auf eine Anzahl anwenden erklärt Grundlagen: Verhältnisse und Raten.

Beispiel: was das Banner bei Donauspeiche erlaubt

Theresas Datenbank enthält für Oktober 1.000 Webbestellungen. Jede trägt den beim Checkout gespeicherten Einwilligungsstatus: 620 mit Werbeeinwilligung, 380 ohne. Also $r = 620 / 1{.}000 = 0{,}62$ und $C_{\max} = 0{,}62 \times 1{.}000 = 620$.

Vor dem Server lieferte das Pixel 527 dieser 620. Die übrigen 93 waren Verkäufe mit Einwilligung, die der Browser nie gemeldet hat: Rückkehr vom Zahlungsanbieter ohne fertige Bestätigungsseite, früh geschlossene Tabs und ein paar Browser, die das Tag blockiert haben. Mit dem Server schickt das Backend jede Bestellung mit Einwilligung, also kommen alle 620 bei den Plattformen an.

Der Zugewinn, als Anteil dessen, was das Pixel geliefert hat:

$$\text{Zugewinn} = \frac{C_{\text{nachher}} - C_{\text{vorher}}}{C_{\text{vorher}}}$$

$\text{Zugewinn}$ ist der relative Anstieg, $C_{\text{nachher}}$ die Käufe, die mit Server ankommen, und $C_{\text{vorher}}$ die Käufe, die nur über das Pixel ankamen. Relative Veränderungen erklärt Grundlagen: Prozentrechnung.

Schritt für Schritt: $620 - 527 = 93$, dann $93 / 527 \approx 0{,}176$, also rund 18 %. Echt, nützlich fürs Bieten, und weit weg von den 30 bis 50 %, die die alte Fassung versprochen hat. Die 380 abgelehnten Bestellungen bewegen sich überhaupt nicht. Sie stehen in Theresas eigenem Bericht als purchase_nc und sonst nirgends.

Donauspeiche, Webbestellungen im Oktober 2026

Die waagrechte Achse zeigt, wer zählt, die senkrechte Achse Bestellungen. Der Server schließt die Lücke zwischen dem dritten und dem vierten Balken. Die Lücke zwischen dem zweiten und dem ersten schließt nichts, und das soll auch so sein.

Die Klick ID ist eine zweite Ebene. Eine Klick ID von Google oder Meta in einem per JavaScript gesetzten Cookie hält in Safari 24 Stunden, wenn der Besucher über einen Link mit Klick ID kam.¹ Bei einem Aufbau über denselben Ursprung kann der Server die Klick ID mit Einwilligung in einem selbst gesetzten Cookie halten oder mit der Sitzung in der eigenen Datenbank des Shops speichern, sodass eine Safari Käuferin, die nach einer Woche zurückkommt, noch zugeordnet werden kann. Das verbessert die Zuordnung der 620. Eine 621. Bestellung macht es nicht daraus.

Testen, bevor irgendjemand den Zahlen traut

Server Side Tracking ist schwerer zu sehen als ein Pixel, deshalb gehört das Testen zum Bau und kommt nicht hinterher.

Die Server Vorschau in Tag Manager listet jede eingehende Anfrage, zeigt, welcher Client sie übernommen hat, welches Event daraus wurde, welche Tags gefeuert haben, und die ausgehenden Anfragen an jeden Anbieter mit ihren Parametern.²⁰ Metas Events Manager hat eine Ansicht für Testevents, und GA4 hat DebugView, beide zeigen Events, sobald sie ankommen.

Ich teste in dieser Reihenfolge. Erstens: In einem privaten Fenster, ohne das Banner anzufassen, kommt beim Tag Server nichts an außer dem, was die Ausnahme für unbedingt Erforderliches erlaubt. Zweitens: Nach einer Ablehnung erzeugt eine Testbestellung purchase_nc im Bericht des Shops und nichts bei Meta oder Google Ads. Drittens: Nach einer Zustimmung kommt dieselbe Bestellung genau einmal bei jeder Plattform an, mit der Bestellnummer als ID und ohne IP Adresse, wo ich das zugesagt habe. Ein Setup, das die ersten beiden besteht und am dritten scheitert, verliert Daten. Ein Setup, das an den ersten beiden scheitert, bricht das Gesetz.

Wann sich der Aufbau lohnt

Server Side Tracking rechnet sich, wenn das Werbebudget groß genug ist, dass ein besseres Signal mit Einwilligung die Gebote verändert, wenn ein spürbarer Teil der Käufer Safari nutzt und wenn der Shop kontrollieren will, was seine Domain verlässt. Es lohnt sich nicht, um Besuchern nachzulaufen, die Nein gesagt haben, denn die erreicht es rechtmäßig nicht.

Für die meisten Shops ist die Reihenfolge gleich. Zuerst ein korrektes Banner und der Einwilligungsmodus im Browser, mit dem Standard, der vor jedem Tag lädt, wie in Event Tracking und Consent Mode beschrieben. Dann der Server, mit der Weiterleitungsregel im Code. Dann First Party Daten dort, wo Menschen zugestimmt haben, das Thema der Cookieless Marketing und First Party Data Strategie. Deine Rohdaten bleiben deine, und die Regeln für Code und Modelle stehen in den Bedingungen für Analytics und Data Science.

Wenn du wissen willst, was deine Tags senden, bevor jemand das Banner anfasst, und was ein Server wirklich bringen würde, biete ich einen kostenlosen Workshop an, und die ersten zwei Wochen Arbeit gehen auf mich.

Quellen