Warum GA4 nicht zu Ihren Bestellungen passt und welcher Teil der Differenz sich zurückholen lässt

Sie öffnen den Kaufbericht in GA4, öffnen die Bestellliste in PrestaShop, und die Zahlen passen nicht zusammen. Fast immer zählt GA4 weniger. Manchmal mehr. Und auf den Werbeplattformen ist die Differenz noch größer.

Als Erstes sollten Sie sich klarmachen: Sie werden nie zu hundert Prozent übereinstimmen, und das müssen sie auch nicht. Die Analyse misst, was der Browser des Besuchers sieht; das Backoffice erfasst, was tatsächlich passiert ist. Nützlich ist zu wissen, woher jeder Teil der Differenz kommt, welcher legitim ist und welcher ein Fehler, den man beheben kann.

Ursache 1: die Einwilligung

Wenn Ihr Cookie-Banner richtig funktioniert, sendet ein Besucher, der die Analyse ablehnt, keine vollständigen Daten. Mit Consent Mode v2 erhält Google cookielose Signale und kann einen Teil dieser Conversions schätzen, aber das ist ein Modell, keine Zählung.

Diese Differenz ist legitim: Sie ist der Preis der Rechtskonformität. Keine Technik sollte sie umgehen. Wenn Ihnen jemand verspricht, die Käufe von Besuchern „zurückzuholen“, die das Tracking abgelehnt haben, indem sie trotzdem mit ihren Daten gesendet werden, schlägt er Ihnen ein rechtliches Problem vor.

Ursache 2: Werbeblocker und restriktive Browser

Werbeblocker verhindern, dass Analyse- und Werbe-Tags geladen werden, auch wenn der Besucher den Cookies zugestimmt hat. Manche Browser verkürzen außerdem die Lebensdauer von Cookies, die vom Browser gesetzt werden, sodass ein Besucher, der Tage später zurückkommt, als neu erscheint und sein Kauf falsch zugeordnet wird.

Dieser Teil lässt sich verbessern, ohne die Einwilligung zu missachten: indem Sie die Conversion von Ihrem Server senden, den der Blocker nicht sieht, und die Kampagnenkennungen in einem vom Server gesetzten Cookie speichern.

Ursache 3: Der Kunde kehrt nicht vom Zahlungsanbieter zurück

In vielen Shops wird das Kauf-Event auf der Bestätigungsseite ausgelöst. Es gibt aber Kunden, die beim Zahlungsanbieter oder in der Banking-App bezahlen und nie in den Shop zurückkehren: Sie schließen den Tab, das Handy wechselt die App, die Weiterleitung schlägt fehl. Die Bestellung existiert, weil der Zahlungsanbieter den Server benachrichtigt hat, aber GA4 erfährt nichts davon.

Das ist eine der größten und am wenigsten bekannten Ursachen. Sie betrifft vor allem Zahlungsarten mit Authentifizierung außerhalb der Seite (Karte mit Bestätigung in der Banking-App, mobile Zahlungen). Beheben lässt sie sich nur, indem der Kauf gesendet wird, wenn der Server weiß, dass die Bestellung bezahlt ist, und nicht, wenn der Browser eine Seite erreicht.

Ursache 4: zu viele Käufe

Wenn GA4 mehr zählt als das Backoffice, prüfen Sie:

• Neuladen der Bestätigungsseite, das den Kauf erneut auslöst.
• Zwei Module oder ein Tag im Tag Manager, die dasselbe Event senden.
• Bestellungen mit fehlgeschlagener Zahlung, die beim Anlegen gezählt werden, obwohl sie später nicht bezahlt werden.
• Browser und Server senden denselben Kauf ohne gemeinsame Kennung, mit der die Plattform deduplizieren kann.

Ursache 5: Sie vergleichen nicht dasselbe

Bevor Sie nach technischen Fehlern suchen, prüfen Sie, ob Sie gleichwertige Zahlen vergleichen:

Und die Erstattungen: Wenn Sie sie nicht an GA4 senden, bleiben dessen Umsätze aufgebläht, während das Backoffice sie bereits abgezogen hat.

So machen Sie den Vergleich, Schritt für Schritt

Um zu wissen, wie viel Ihnen wirklich verloren geht, machen Sie diese Prüfung für einen abgeschlossenen Zeitraum, zum Beispiel den Vormonat:

1. Exportieren Sie aus PrestaShop die bezahlten Bestellungen des Zeitraums, ohne stornierte und erstattete, mit ihrer Referenz oder Kennung.
2. Exportieren Sie aus GA4 die Transaktionen desselben Zeitraums mit ihrer Transaktions-ID. Wenn Ihr Tracking die Bestellkennung nicht als Transaktions-ID sendet, ist das die erste Korrektur.
3. Gleichen Sie über die Kennung ab, nicht über Summen. Summen verbergen Ausgleichseffekte: zehn verlorene und zehn doppelte Käufe ergeben eine Differenz von null.
4. Gruppieren Sie die fehlenden Bestellungen nach Zahlungsart und Gerät. Wenn fast alle von einer bestimmten Zahlungsart oder vom Handy stammen, wissen Sie, wo Sie suchen müssen.
5. Gruppieren Sie die überzähligen danach, wie oft sie vorkommen: Wiederholungen deuten auf Neuladen oder doppelte Tags hin.

Wiederholen Sie die Prüfung nach jeder Änderung am Tracking oder an den Zahlungsmodulen. Ein Update eines Zahlungsmoduls, das die Rückkehrseite ändert, kann die Messung kaputt machen, ohne dass es jemand merkt.

Was Server-Side bringt und was nicht

Die Conversions vom Server des Shops (oder von einem Zwischenserver) an GA4, Meta oder Google Ads zu senden:

• Holt die Käufe zurück, die durch Werbeblocker und durch Kunden verloren gehen, die nicht vom Zahlungsanbieter zurückkehren.
• Ermöglicht es, den Kauf bei Zahlungseingang zu senden, nicht beim Aufruf einer Seite.
• Sendet auch Erstattungen und Stornierungen, die der Browser nie sieht.
• Holt nicht zurück, wofür der Besucher keine Einwilligung gegeben hat. Der Server muss dieselbe Entscheidung respektieren wie das Banner.
• Behebt kein fehlerhaftes Tracking: Sendet der Browser den Kauf zweimal ohne gemeinsame Kennung, fügt der Server nur einen dritten hinzu.

Wie Sie das in PrestaShop lösen

RKR API Conversions Pro sendet die Conversions von Ihrem Server an Meta, GA4, Google Ads, TikTok und weitere Plattformen, mit derselben Event-ID wie der Browser, damit nichts doppelt gezählt wird. Käufe lassen sich bei Zahlungseingang der Bestellung senden (die Voreinstellung bei neuen Installationen), und auch Teilerstattungen, Stornierungen und im Backoffice angelegte Bestellungen werden übertragen. Es wendet Consent Mode v2 mit wiederhergestellter Einwilligung an, bevor die Tags geladen werden, speichert die Klick-Kennungen in einem eigenen, vom Server gesetzten Cookie und bietet Statusampeln pro Plattform sowie einen täglichen Abgleich der Bestellungen. Wenn Sie den Server weder aufsetzen noch betreuen möchten, nimmt RKR Relay (Tarife Esencial und Profesional) die vom Modul signierten Events entgegen und liefert sie von unserem Server an jede Plattform aus, mit Warteschlange, Wiederholungen, verschlüsselten Zugangsdaten, gehashten personenbezogenen Daten und dem im Shop sichtbaren Status jeder Zustellung.