Ihre Analytics sagt, die Website habe letzten Monat 42.180 gemacht. 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 bläht immer auf.

Das Kaufereignis lebt meist auf der Bestellbestätigungsseite. Diese Seite wird jedes Mal neu geladen, wenn jemand sie neu lädt, zurück und wieder vor geht, sie aus seiner E-Mail öffnet oder sie von einem Browser wiederhergestellt bekommt, der Tabs beim Start wieder öffnet. Jedes davon feuert das Ereignis erneut, 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 auf einer Handvoll großer Bestellungen, und der Effekt ist auf dem Telefon schlimmer, wo das Zurückgehen häufiger ist.

Die Behebung ist eine Bestellnummer. Senden Sie die Bestellnummer mit dem Kaufereignis und lassen Sie die Analytics daran entdoppeln. 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, deutlich zu sagen, was es kostet, das falsch zu machen. 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 Zeichen 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.

Die sicherste Anordnung ist, dass die Währung dem Ereignis bei der Aufzeichnung aufgeprägt 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 ist ein lebender Nachweis. 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 Ihr Buch nie hatte.

4. Blockierte, verworfene und nie gesendete Ereignisse

Diese hier senkt immer ab, 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, wettrennt gegen den 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, die den kleinen Rest erklärt, der übrig bleibt, nachdem Sie alles andere behoben haben.

Die Analytics stempelt das Ereignis in der Sitzung des Besuchers, in der Zeitzone, auf die der Bericht eingestellt ist. Ihre Bestelldatenbank stempelt die Zeile, 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 zuweist. 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 Eimer, die dabei herausfallen, sind die Diagnose. Ereignisse ohne Bestellung sind Doppelfeuer 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 gekennzeichnete 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 gestempelt, 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 verdient hat, und nicht der Seite, auf der er bezahlt wurde, und die Umsatzwährung wird bei der Aufnahme gestempelt und nie umgerechnet.