Ihre Analytics sagt, die Website habe letzten Monat 42.180 umgesetzt. Ihre Bestelldatenbank sagt 39.650. Jemand fragt, was stimmt, und die ehrliche Antwort ist meist keines von beiden, aus Gründen, die einzeln langweilig und zusammen teuer sind.

Hier sind die fünf Ursachen, grob geordnet danach, wie oft sich jede als die richtige entpuppt, mit einem Weg, sie auseinanderzuhalten.

1. Die Bestätigungsseite feuert mehr als einmal

Das ist mit Abstand die häufigste Ursache, und sie treibt die Zahl immer nach oben.

Das Kaufereignis sitzt meist auf der Bestellbestätigungsseite. Diese Seite wird jedes Mal erneut geladen, wenn jemand sie aktualisiert, zurück- und wieder vorblättert, sie aus seiner E-Mail öffnet oder ein Browser sie wiederherstellt, der beim Start die Tabs wieder öffnet. Jedes Mal wird das Ereignis erneut ausgelöst, mit demselben Wert.

Sie erkennen es an der Form der Abweichung: Die Analytics liegt höher als die Bestelldatenbank, die Lücke ist ein glattes Vielfaches bei einer Handvoll großer Bestellungen, und der Effekt ist auf Mobilgeräten stärker, wo häufiger zurücknavigiert wird.

Die Lösung ist eine Bestellnummer. Senden Sie die Bestellnummer mit dem Kaufereignis und lassen Sie die Analytics darüber deduplizieren. In GA4 heißt das Feld transaction_id; die meisten Werkzeuge nutzen diesen Namen, weil die GA-Konvention gewonnen hat. Wenn Ihre Tag-Manager-Vorlage ein Feld dafür hat und Sie es leer gelassen haben, ist das Ihr Fehler.

Es lohnt sich, offen zu sagen, was ein Fehler hier kostet. Eine erneut feuernde Kaufabwicklungsseite, die einen einzelnen Verkauf viermal zählt, sieht in einem Dashboard nicht wie ein Fehler aus. Sie sieht wie ein guter Monat aus.

2. Zwei Währungen zusammenaddiert

Wenn Sie in mehr als einer Währung verkaufen und Ihre Analytics eine einzige Umsatzsumme meldet, finden Sie heraus, was sie tut, bevor Sie ihr trauen.

Manche Werkzeuge rechnen in eine Berichtswährung um, zu einem Kurs, der beim Eintreffen der Daten festgehalten wurde. Manche rechnen zum Kurs des Tages um, an dem Sie hinsehen, was heißt, dass ein abgeschlossener Monat seinen Wert ändert, je nachdem, wann Sie ihn öffnen. Manche addieren schlicht die Zahlen und setzen ein Währungszeichen davor, was eine Zahl ergibt, die in keiner Währung Geld ist.

Das Anzeichen ist eine Summe, die zwischen der richtig umgerechneten Zahl und der naiven Summe liegt, oder eine Summe, die sich bewegt, wenn Sie einen Bericht für einen längst abgeschlossenen Monat erneut öffnen.

Am sichersten ist es, wenn die Währung beim Aufzeichnen am Ereignis vermerkt wird und das Werkzeug nie umrechnet. Ein Bericht über gemischte Währungen teilt dann entweder nach Währung auf oder verweigert eine Gesamtsumme, und beides ist nützlicher als eine selbstsichere falsche Zahl.

3. Erstattungen, Stornierungen und fehlgeschlagene Einzüge

Ihre Bestelldatenbank bildet den aktuellen Stand ab. Sie weiß, dass Bestellung 8814 am 14. erstattet wurde. Ihre Analytics hat den Kauf am 2. aufgezeichnet und glaubt weiterhin daran, sofern Sie ihr kein Erstattungsereignis geschickt haben.

Über einen Monat mit üblichen Rückgabequoten kann das allein einige Prozent ausmachen, und es ist die Ursache, die die Analytics gegenüber einem Finanzbericht hoch aussehen lässt statt gegenüber einer Bestelltabelle.

Verwandt und leichter zu übersehen: eine Bestellung, die angelegt, aber nie eingezogen wurde. Wenn das Ereignis auf der Bestätigungsseite feuert und die Zahlung später scheitert, oder die Bestellung unbezahlt liegen bleibt und durch Zeitablauf storniert wird, hat die Analytics einen Verkauf, den Ihre Buchhaltung nie hatte.

4. Blockierte, verworfene und nie gesendete Ereignisse

Diese Ursache drückt die Zahl immer nach unten, und sie ist der Grund, warum die Analytics meist niedriger liegt als die Bestelltabelle, wenn sie nicht durch die Ursachen oben aufgebläht wird.

Inhaltsblocker halten die Anfrage auf. Ebenso manche Firmennetze, manche Filter auf DNS-Ebene und manche datenschutzorientierten Browser von Haus aus. Wenn Ihre Analytics eine Einwilligung braucht, fehlen auch alle, die abgelehnt haben. Und ein Kaufereignis, das beim Laden der Seite feuert, liefert sich ein Wettrennen mit dem Besucher, der den Tab schließt, was er sehr oft in dem Augenblick tut, in dem die Bestellung bestätigt ist.

Die Größe des blockierten Anteils schwankt enorm nach Publikum (eine Website für Entwicklerwerkzeuge verliert weit mehr als ein Blumenladen), jeder veröffentlichte Prozentsatz ist für Ihren Fall also wertlos. Messen Sie Ihren eigenen: Zählen Sie die von Ihrer Datenbank aufgezeichneten Bestellungen gegen die von der Analytics aufgezeichneten Kaufereignisse, verbunden über die Bestellnummer, für eine einzelne saubere Woche.

Wenn Sie nicht über die Bestellnummer verbinden können, ist das wieder Ursache Nummer 1.

5. Die beiden Systeme zählen verschiedene Augenblicke

Zum Schluss die langweilige Ursache, die den kleinen Rest erklärt, der übrig bleibt, nachdem Sie alles andere behoben haben.

Die Analytics versieht das Ereignis in der Sitzung des Besuchers mit einem Zeitstempel, in der Zeitzone, auf die der Bericht eingestellt ist. Ihre Bestelldatenbank versieht die Zeile mit einem Zeitstempel, wenn der Zahlungsdienstleister bestätigt hat, in UTC, womöglich Minuten später und gelegentlich auf der anderen Seite von Mitternacht. Eine Monatsgrenze macht daraus einen echten Unterschied: immer in dieselbe Richtung, immer klein.

Die Zuordnung kommt hinzu. Die Analytics weist Umsatz der Sitzung zu, die konvertierte (oder je nach Zuordnungsmodell einer früheren Sitzung), während Ihre Bestelltabelle ihn überhaupt nichts zuordnet. Eine Last-Click-Umsatzsumme mit einer rohen Bestellsumme zu vergleichen heißt, die Antworten auf zwei verschiedene Fragen zu vergleichen.

Ein Abgleich, den Sie tatsächlich durchführen können

  1. Wählen Sie eine abgeschlossene Woche.
  2. Exportieren Sie Bestellungen: Nummer, Zeitstempel in UTC, Währung, Nettowert nach Erstattungen.
  3. Exportieren Sie Kaufereignisse mit denselben Feldern.
  4. Verbinden Sie über die Bestellnummer.

Die vier Gruppen, die dabei entstehen, sind die Diagnose. Ereignisse ohne Bestellung sind Doppelauslösungen oder Testverkehr. Bestellungen ohne Ereignis sind Blockierung oder ein kaputtes Tag. Zusammengehörige Paare mit verschiedenen Werten sind der Umgang mit Währungen oder eine Verwechslung von Brutto und Netto. Zusammengehörige Paare an verschiedenen Tagen sind die Zeitzone.

Tun Sie das einmal, schreiben Sie den Rest als Prozentsatz auf, und Sie haben etwas weit Wertvolleres als eine passende Summe: einen bekannten und stabilen Unterschied. Zwei Systeme, die um beständige 4 % uneinig sind, sind beide brauchbar. Zwei Systeme, die zufällig übereinstimmen, sind es nicht.

Wo Skomi steht

Skomi liest die Bestellnummer aus order_id und auch aus GAs transaction_id, eine bereits für GA4 getaggte Website braucht also keine Änderung. Ein Ereignis mit einer Nummer, die es schon gesehen hat, wird nicht erneut gezählt.

Umsatz wird im Augenblick der Aufzeichnung mit seiner Währung versehen, und Skomi rechnet nie zwischen Währungen um: Ein Bericht über zwei Währungen zeigt zwei Zahlen, denn die eine Zahl wäre eine Erfindung. Mehr dazu steht auf der Analytics-Seite, und das Snippet installieren behandelt das Senden des Ereignisses.

Zwei Definitionen leisten hier die meiste Arbeit: Umsatz wird dem Besuch zugeordnet, der ihn eingebracht hat, und nicht der Seite, auf der er bezahlt wurde, und die Umsatzwährung wird beim Eingang festgehalten und nie umgerechnet.