Wo Conversion-Daten auf dem Weg verloren gehen

Am Tag der Einrichtung sieht alles gut aus. Der Tag Assistant zeigt grüne Haken, der dataLayer liefert saubere Werte, die Testbestellung erscheint im Werbekonto. Ein paar Wochen später passen die Zahlen trotzdem nicht mehr zum Backend, und die Differenz wird als „übliche Abweichung“ abgehakt.

Diese Abweichung hat aber Ursachen. Ein Ereignis legt einen erstaunlich langen Weg zurück: vom Browser des Kunden über Cookies, Werbeblocker und Consent-Banner bis zur Schnittstelle der Plattform. An jeder Station kann es verloren gehen. Es lohnt sich, die Stationen einzeln anzusehen, denn sie verlangen sehr unterschiedliche Antworten.

1. BrowserEreignis entsteht beim Kunden
2. CookiesLaufzeit begrenzt die Wiedererkennung
3. Werbeblockerblockieren bekannte Tracking-Adressen
4. ConsentAblehnung stoppt Daten, gewollt
5. PlattformSchnittstelle empfängt das Ereignis

Einrichtung und Ankunft sind zwei verschiedene Probleme

Ein Tag, das im Vorschaumodus feuert, beweist nur, dass das Ereignis entsteht. Ob es bei echten Kunden, in echten Browsern und über Wochen hinweg beim Ziel ankommt, ist eine andere Frage. Genau dort hat sich in den letzten Jahren am meisten verändert: Browser begrenzen Speicher, Werbeblocker sind verbreitet, Einwilligungen sind Pflicht.

Die Stationen im Überblick:

Station	Was verloren geht	Lässt sich das beheben?
Cookie-Laufzeit (Safari ITP)	Wiedererkennung von Besuchern, Zuordnung zur Anzeige	Ja, mit serverseitig gesetzten Cookies
Werbeblocker	Anfragen an bekannte Tracking-Adressen	Teilweise, mit eigener Subdomain
Fragile Browser-Trigger	Ereignisse nach Änderungen an Formularen oder Theme	Ja, mit robusterer Erfassung
Fehlende Einwilligung	Daten von Nutzern, die abgelehnt haben	Nein – und das ist richtig so
Zu viele Scripts	Ladezeit, Datensparsamkeit, einheitliche Zahlen	Ja, mit Bündelung über einen Server

Station 1: Die Cookie-Laufzeit

Safari begrenzt Cookies, die per JavaScript gesetzt werden, auf höchstens sieben Tage, in bestimmten Fällen sogar auf 24 Stunden. Kommt ein Kunde nach Ablauf zurück, sieht er für Ihre Analyse aus wie ein neuer Besucher. Die Verbindung zwischen Anzeigenklick und Kauf ist weg.

Das trifft Shops mit längeren Kaufentscheidungen besonders: Wer eine Woche über ein Sofa oder ein Fahrrad nachdenkt, landet in der Auswertung schnell unter „Direct“.

Die Antwort ist ein Cookie, das nicht per JavaScript, sondern vom eigenen Server per HTTP-Antwort gesetzt wird – über einen Server-Container unter einer Subdomain Ihres Shops. Solche Cookies behandelt Safari als echte First-Party-Cookies, solange die Infrastruktur zur Hauptdomain passt. Die Details und Einschränkungen beschreiben wir im Beitrag zu Safari ITP.

Station 2: Werbeblocker

Werbeblocker arbeiten meist mit Listen bekannter Adressen und Script-Namen. Eine Anfrage an die Standard-Adresse von Google oder Meta fällt darunter und erreicht ihr Ziel gar nicht erst.

Läuft das Tracking dagegen über eine eigene Subdomain, etwa daten.ihr-shop.de, ist die Anfrage für den Blocker zunächst normaler Datenverkehr Ihrer eigenen Website. Bei Stape kommt dafür der Custom Loader hinzu, der auch das Tag-Manager-Script selbst über diese Subdomain ausliefert.

Wichtig ist die Grenze: Es geht um Nutzer, die eingewilligt haben, deren Browser aber trotzdem blockiert. Ein Werbeblocker ist keine Einwilligung und keine Ablehnung – die Einwilligung regelt das Consent-Banner. Dazu gleich mehr.

Station 3: Trigger, die still kaputtgehen

Klick- und Formular-Trigger im Web-Container sind schnell eingerichtet, ohne Entwickler und ohne Änderung am Shop. Genau das macht sie verlockend. Ihr Nachteil: Sie hängen an der Struktur der Seite. Wird ein Formular neu gebaut, ein Theme aktualisiert oder ein Button umbenannt, feuert der Trigger nicht mehr. Eine Fehlermeldung gibt es nicht. Auffallen tut es oft erst Wochen später, wenn jemand fragt, warum die Anfragen „eingebrochen“ sind.

Für umsatzrelevante Ereignisse lohnt deshalb eine robustere Quelle:

• Käufe aus dem dataLayer des Checkouts oder direkt aus dem Shop-System, statt aus einem Klick auf „Jetzt kaufen“. Wie ein sauberer dataLayer in Shopify aussieht, zeigt der Beitrag zum Shopify-dataLayer.
• Formulare und Leads über Webhooks, die das Formular-Tool oder das CRM erst nach erfolgreicher Verarbeitung auslöst.
• Abgleich der erfassten Ereignisse mit dem, was tatsächlich im Backend oder CRM angekommen ist.

Browser-Trigger bleiben sinnvoll für Ereignisse, deren Ausfall niemandem schadet: Scrolltiefe, Klicks auf Filter, Interaktionen mit Bildergalerien.

Station 4: Die Einwilligung

An dieser Station gehen Daten verloren, und das ist gewollt. Lehnt ein Besucher Marketing-Cookies ab, gilt das für den Server-Container genauso wie für den Browser. Der Consent-Status wird mit jedem Ereignis übermittelt, und der Server muss ihn beachten.

Server-Side Tracking wird gelegentlich als Weg verkauft, Einwilligungen zu umgehen. Das ist es nicht, und ein solches Setup wäre ein erhebliches Risiko für Ihr Unternehmen. Was der Server-Container leisten kann, ist etwas anderes: Er sorgt dafür, dass die Daten von Nutzern, die zugestimmt haben, auch tatsächlich ankommen – statt an Cookie-Laufzeiten oder Blockern zu scheitern.

Die Unterscheidung in einem Satz: Eingewilligte, aber blockierte Daten zurückzuholen ist Messung. Abgelehnte Daten trotzdem zu erfassen ist es nicht. Wie Einwilligung und Server-Setup zusammenspielen und wo eine rechtliche Prüfung im Einzelfall nötig ist, beschreiben wir auf unserer Seite zu Datenschutz und im Beitrag zu Consent Mode v2 in Shopify.

Station 5: Zu viele Scripts im Browser

Jede Plattform bringt ihr eigenes Script mit: Google, Meta, TikTok, Pinterest, dazu Bewertungs-Apps und Heatmaps. Jedes davon kostet Ladezeit, liest im Browser mit, was es lesen kann, und meldet Conversions nach eigener Logik. Addiert man, was die Plattformen sich selbst zuschreiben, kommt schnell mehr Umsatz heraus, als der Shop gemacht hat.

Ein Server-Container ändert die Richtung des Datenflusses. Der Browser schickt einen einzigen Datenstrom an Ihren Server. Von dort entscheiden Sie, welche Plattform welche Felder bekommt:

• Weniger Anfragen im Browser, was der Ladezeit zugutekommt.
• Datensparsamkeit pro Plattform: Meta erhält, was Meta braucht, nicht alles, was im Browser verfügbar ist.
• Eine gemeinsame Quelle für alle Plattformen, sodass Abweichungen erklärbar werden.

Die Selbstzuschreibung der Plattformen verschwindet dadurch nicht – jede rechnet weiter mit ihrem eigenen Attributionsmodell. Aber alle arbeiten mit denselben Rohdaten, und das macht den Vergleich deutlich ehrlicher.

In welcher Reihenfolge Sie vorgehen

1. Abgleich starten. Bestellungen im Backend gegen Käufe in GA4 und den Werbekonten, wöchentlich als Anzahl. Ohne diese Zahl wissen Sie nicht, wie groß die Lücke ist.
2. Consent prüfen. Erst klären, welcher Teil der Lücke auf Ablehnungen zurückgeht. Dieser Teil ist kein Fehler.
3. Umsatzrelevante Ereignisse absichern. Kauf und Lead aus robusten Quellen erfassen, nicht aus Klick-Triggern.
4. Server-Container unter eigener Subdomain einrichten, damit Cookie-Laufzeiten und Blocker eingewilligte Daten nicht mehr verschlucken.
5. Scripts im Browser reduzieren, sobald die Plattformen ihre Daten über den Server erhalten.

Was ein solches Setup laufend kostet, rechnet die Seite zu den Kosten von Server-Side Tracking vor.

Fazit

Die „übliche Abweichung“ besteht aus mehreren, klar unterscheidbaren Verlusten. Kurze Cookie-Laufzeiten, Werbeblocker, fragile Trigger und überladene Browser lassen sich technisch angehen. Fehlende Einwilligungen nicht – und dieser Teil der Lücke gehört zu einem sauberen Setup dazu.

Wer die Stationen einzeln betrachtet, sieht schnell, wo der eigene Shop Daten verliert. Den Aufbau für Shopify beschreiben wir unter Server-Side Tracking für Shopify, Begriffe wie ITP oder sGTM erklärt das Glossar. Für Ihr Setup: Erstgespräch anfragen.