Neukunden in der Shop-Analyse: die erste Bestellung mit dem CRM abgleichen
Neukunden in der Shop-Analyse sind nicht dasselbe wie neue Besucher oder neue Datensätze im CRM. Um eine verlässliche Zahl der Erstkunden zu erhalten, definieren Sie zunächst, wer als Kunde gilt und wann ein Kauf im führenden Geschäftssystem bestätigt wird. Gleichen Sie anschließend die Bestellungen anhand einer stabilen Kennung mit den Ereignissen in Google Analytics ab und ordnen Sie Abweichungen nach ihren Ursachen.
Das ist eine Aufgabe für die E-Commerce-Leitung, den Analysten und den Integrationsentwickler. Wenn Sie die Akquisekosten durch eine beliebige Kennzahl für „Neue“ teilen, kann eine Änderung der Einstellungen wie eine Verbesserung der CAC — der Kundenakquisekosten — aussehen. Im Folgenden geht es nicht um die Auswahl von Werbekanälen, sondern um die Prüfung des Nenners: Wer wurde tatsächlich erstmals Kunde und auf welcher Datengrundlage?
Legen Sie zuerst fest, wen der Shop als Kunden betrachtet
Halten Sie die Definition schriftlich fest, bevor Sie den Bericht erstellen. Eine Arbeitsdefinition zur Prüfung: Ein Neukunde ist ein eindeutiger Kunde, dessen frühester bestätigter und bezahlter Kauf in den Berichtszeitraum fällt. Das ist eine betriebliche Steuerungsregel und keine allgemeingültige Vorgabe von Google. Bei Zahlung per Nachnahme kann der Geldeingang als Bestätigung gelten und nicht der Klick auf den Bestellbutton. Bei Vorkasse müssen Sie gesondert festlegen, wie Teilzahlungen behandelt werden.
Der Status „erstellt“ belegt keine Zahlung, und ein neuer Kontaktdatensatz bedeutet keinen neuen Kunden: Es kann sich um eine Dublette nach einem Import handeln. Stimmen Sie die Regel zwischen Marketing, Finanzen und operativem Team ab und benennen Sie eine für Änderungen verantwortliche Person.
Definieren Sie außerdem den Geltungsbereich: nur die Website, alle Geschäfte der Marke oder eine einzelne juristische Person. Ein Kunde, der zuvor offline gekauft hat, kann für die Website neu sein, nicht aber für das Unternehmen. Vermischen Sie diese beiden Kennzahlen nicht. Den allgemeinen Kontext betrieblicher Steuerungskennzahlen erläutert der Beitrag über zentrale Kennzahlen zur Geschäftseffizienz; hier geht es bereits um die Prüfung konkreter Datensätze.
Was der erste Kauf in Google Analytics genau bedeutet
In der Dokumentation zum Bericht User acquisition beschreibt Google die Gewinnung neuer Nutzer, nicht das Auftauchen erstmals zahlender Kunden im CRM. Der erste Besuch und die erste Bestellung können in unterschiedlichen Zeiträumen liegen.
Ersetzen Sie Kunden nicht durch neue Nutzer
Die Kennzahl New users bezieht sich auf erste Interaktionen, die durch die Ereignisse first_visit oder first_open erfasst werden. Sie bestätigt keine Zahlung. Laut der Beschreibung von Monetization overview zählt First time purchasers eindeutige Nutzer, für die purchase erstmals erfasst wurde. Das kommt der gesuchten Antwort näher, doch der Beobachtungsumfang von Analytics entspricht nicht der vollständigen Historie Ihres CRM.
Planen Sie kein separates Web-Ereignis first_purchase als verbindlichen Standard ein: Die beschriebene Kennzahl verwendet purchase. Wenn Sie ein eigenes Ereignis first_purchase haben, prüfen Sie dessen Spezifikation: Der Name macht es nicht zum Äquivalent der Standardkennzahl.
Die Nutzeridentität hat Grenzen
Google ermöglicht es, Aktivitäten über eine vom Unternehmen erstellte User-ID zu verknüpfen. Dadurch werden nicht automatisch alle Gastkäufe oder die Historie der alten Website rekonstruiert. Das Ergebnis hängt von der Implementierung und der Identität für die Berichterstellung ab. Bauen Sie das Register bestätigter Kunden auf abgestimmten Daten aus den Geschäftssystemen auf.
Stellen Sie ein minimales Register für den Abgleich zusammen
Der Abgleich der ersten Bestellung mit dem CRM beginnt mit zwei Datensätzen: Bestellungen mit Zahlungsstatus und verfügbaren purchase-Einträgen mit Transaktionskennungen. Für einen kleinen Shop genügen kontrollierte Exporte. Ein Data Warehouse wird benötigt, wenn sich das manuelle Verfahren nicht mehr reproduzieren lässt oder viele Quellen hinzukommen. Ein neues Dashboard ohne Zuordnungsregeln löst das Problem nicht.
| Kriterium | Was festzuhalten ist | So prüfen Sie es |
|---|---|---|
| Bestellschlüssel | Unveränderliche order_id und zugehörige transaction_id | Ein Kauf erhält bei erneuter Zustellung des Ereignisses keine unterschiedlichen Schlüssel |
| Kundenschlüssel | Interner customer_key und Grundlage der Verknüpfung | Eine erneute Zahlung desselben Kunden erzeugt keinen neuen Kunden |
| Kaufzeitpunkt | Zeitpunkt der Zahlungsbestätigung und Zeitzone | Datensätze an Periodengrenzen fallen in denselben Berichtszeitraum |
| Eignung des Datensatzes | Zahlung, Test, Stornierung, vollständige oder teilweise Erstattung | Jeder Ausschluss hat einen Grund, statt nur aus der Summe zu verschwinden |
| Historischer Umfang | Beginn der verlässlichen Erfassung und abgedeckte Kanäle | „Erster in der Datenbank“ wird nicht als „erster überhaupt“ ausgegeben |
Speichern Sie den Stichtag des Datenabzugs, die Quelle, die Regelversion und das Zuordnungsergebnis. Überschreiben Sie die ursprünglichen Exporte nicht: Das Gesamtergebnis muss ohne versteckte manuelle Korrekturen reproduzierbar sein.
Der Algorithmus lautet: Ermitteln Sie die nach der abgestimmten Regel anrechenbaren Käufe; suchen Sie für jeden customer_key den frühesten in der gesamten verfügbaren Historie; wählen Sie erst danach die Kunden nach dem Berichtszeitraum aus. Wenn Sie die Historie zuerst auf den aktuellen Monat beschränken, wird ein Bestandskunde mit einem Wiederholungskauf fälschlich zum Neukunden. Kennzeichnen Sie eine unvollständige Historie gesondert, statt sie mit Vermutungen zu korrigieren.
Verknüpfen Sie einen Gast mit einem Kunden, ohne riskant zusammenzuführen
Bei einem registrierten Kunden kann eine stabile interne Kennung als Bezugspunkt dienen. Für einen Gast benötigen Sie abgestimmte Zuordnungsregeln in der geschützten Umgebung des Shops. Eine bestätigte Kontaktangabe kann helfen, eine Verbindung zu finden. Eine gemeinsame Familien-E-Mail-Adresse oder eine geschäftliche Telefonnummer beweist jedoch nicht, dass die Bestellungen derselben Person gehören. Allein ein übereinstimmender Name oder eine identische Lieferadresse reicht nicht aus.
Bewahren Sie die Grundlage der Zusammenführung und die Möglichkeit auf, sie rückgängig zu machen. Geben Sie zweifelhafte Paare zur Prüfung weiter oder belassen Sie sie in der Gruppe „Identität ungeklärt“. Eine erzwungene Zusammenführung kann unterschiedliche Personen vereinen.
Die Kundenidentifikation erfordert eine klare Trennung der Systeme. Übermitteln Sie E-Mail-Adressen, Telefonnummern und vollständige Namen nicht als User-ID, transaction_id oder beliebige Ereignisparameter. Prüfen Sie URLs und Seitentitel auf Kontaktangaben aus Formularen entsprechend den Google-Empfehlungen zur Vermeidung von PII. Belassen Sie die Verknüpfung zwischen technischen Schlüsseln und Kontaktangaben innerhalb der kontrollierten Umgebung.
Hashing ist keine pauschale Erlaubnis, Kontaktangaben in gewöhnlichen purchase-Parametern zu übermitteln. Verwenden Sie für diesen Abgleich Bestellschlüssel und keine Kontaktangaben der Kunden.
Ordnen Sie Abweichungen nach Ursachen, statt das Ergebnis passend zu machen
Gleichen Sie zuerst die Bestellungen ab und zählen Sie erst danach die eindeutigen Kunden. Im Abgleichbericht werden folgende Gruppen benötigt: in beiden Quellen vorhanden; nur im führenden Geschäftssystem vorhanden; nur in Analytics vorhanden; Schlüsselkonflikt; Status oder Zeitpunkt stimmen nicht überein. Legen Sie für jede Gruppe den nächsten Schritt fest. Ein fehlendes purchase erfordert beispielsweise eine Prüfung der Ereigniszustellung und nicht das automatische Entfernen eines zahlenden Kunden aus dem CRM.
Laut der Dokumentation zu transaction_id entfernt Analytics doppelte purchase-Ereignisse mit derselben Kennung in Web-Datenstreams. Der Schlüssel muss für die Bestellung eindeutig und nicht leer sein und darf nicht von verschiedenen Kunden gemeinsam verwendet werden. Die Deduplizierung von Transaktionen ist jedoch keine Deduplizierung von Kunden: Unterschiedliche Käufe einer Person haben naturgemäß unterschiedliche Schlüssel.
Stornierungen und Erstattungen erfordern eine eigene Richtlinie
Eine unbezahlte, stornierte Bestellung erfüllt die vorgeschlagene Regel für einen bestätigten Kauf nicht. Eine vollständige Erstattung nach der Zahlung ist ein anderer Fall: Die Zahlung hat stattgefunden, doch das Unternehmen kann Kunden, die ihren Kauf behalten haben, gesondert zählen. Stellen Sie diese Kennzahlen bei Bedarf nebeneinander dar und ändern Sie die Definition nicht rückwirkend ohne Kennzeichnung. Auch eine teilweise Erstattung ist nicht mit dem Ausbleiben eines Kaufs gleichzusetzen.
Das Ereignis refund mit der zugehörigen transaction_id ist in Googles E-Commerce-Anleitung vorgesehen. Gehen Sie jedoch nicht davon aus, dass sein Versand Ihre CRM-Kohorte der Erstkunden automatisch nach der gewünschten Regel neu berechnet. Das ist eine separate Logik. Vereinbaren Sie für Nachnahme, späte Bestätigungen und Erstattungen einen erneuten Datenstichtag und kennzeichnen Sie vorläufige Ergebnisse.
Hypothetisches Beispiel: Ein Gast kehrt mit einem anderen Gerät zurück
Stellen wir uns vor, jemand kauft als Gast, legt später auf einem anderen Gerät ein Kundenkonto an und bezahlt erneut eine Bestellung. Wenn der Shop eine bestätigte Verknüpfung zwischen dem Gastkauf und dem Profil hat, bleibt der interne customer_key gleich. Der früheste anrechenbare Kauf gehört zum vorherigen Zeitraum, sodass der Kunde im aktuellen Zeitraum nicht zum Neukunden wird.
„Korrigieren“ Sie das Ergebnis ohne eine solche Verknüpfung nicht aufgrund eines ähnlichen Nachnamens: Kennzeichnen Sie die Unsicherheit. Wurde die erste Bestellung nicht bezahlt, wird sie nicht zum ersten anrechenbaren Kauf. Wurde sie bezahlt und anschließend erstattet, wenden Sie die Erstattungsrichtlinie an und nicht die Regel für eine Stornierung vor der Zahlung.
Das ist ein hypothetisches Szenario und keine Fallstudie von GL.ua. Stimmen Sie für die Verwendung des Ergebnisses in den CAC die Kosten, den Zeitraum und die Kanalabdeckung ab. Ein allgemeines Kundenregister allein liefert keine korrekten CAC für eine einzelne Kampagne.
Prüfen Sie die Abnahmekriterien vor dem Start des Berichts
Der Analyst prüft den Piloten gemeinsam mit dem Entwickler und der für den Vertrieb verantwortlichen Person. Das Bereitschaftskriterium ist die Erklärung der Abweichungen und nicht eine erzwungene Gleichheit zwischen Analytics und CRM.
- Testen Sie einen erstmals zahlenden Kunden und einen Wiederkäufer. Im Register erhält nur der erste die Kennzeichnung für einen neuen Kauf im Zeitraum.
- Wiederholen Sie das Laden der Bestätigung und die Zustellung desselben Ereignisses. Die Bestellung behält ihren Schlüssel, und die interne Summe steigt nicht.
- Prüfen Sie einen Gast, die Anmeldung im Kundenkonto und eine zweifelhafte Übereinstimmung von Kontaktangaben. In jedem Fall ist die Grundlage der Verknüpfung oder eine ausdrückliche Unsicherheit erkennbar.
- Durchlaufen Sie Zahlung, unbezahlte Stornierung sowie teilweise und vollständige Erstattung. Die Ergebnisse entsprechen den schriftlichen Regeln und nicht der aktuellen Statusbezeichnung.
- Gleichen Sie Datensätze an der Periodengrenze und eine späte Zahlungsbestätigung ab. Zeitzone, Datenstichtag und erneute Berechnung sind dokumentiert.
- Prüfen Sie Ereignisparameter, URLs und Protokolle auf die Offenlegung von Kontaktangaben. Bewahren Sie einen anonymisierten Prüfbeleg auf und benennen Sie eine für das Monitoring verantwortliche Person.
Prüfen Sie gesondert den Fall, dass purchase aufgrund von Einschränkungen der Datenerhebung nicht eingegangen ist. Ein zahlender Kunde darf nicht aus der Kennzahl des führenden Geschäftssystems verschwinden. Erfassen Sie das fehlende Analytics-Ereignis als Beobachtungslücke, ohne zu versuchen, die Entscheidung des Nutzers zu umgehen. Wiederholen Sie die Abnahmetests nach Änderungen an der Zahlungsabwicklung, am CRM oder am Tag-Container.
Zeitplan, Kosten und Grenzen sinnvoller Genauigkeit
Der Zeitplan hängt von der Verfügbarkeit der Historie, der Qualität der Statusangaben und den Identitätsregeln ab. Die Schritte sind: Bestandsaufnahme der Quellen, Kennzahlenlexikon, probeweiser Abgleich, Korrektur der Integrationen und erneuter Datenabzug. Geben Sie eine kalendarische Schätzung nach der Bestandsaufnahme ab: Ein alter Import kann mehr Arbeit erfordern als die Einrichtung von purchase.
Trennen Sie bei den Kosten die Analyse und Bereinigung der Historie, die Weiterentwicklung des CRM-Datenaustauschs, die Ereigniskonfiguration, Tests, Speicherung und regelmäßige Kontrollen. Wenn kontrollierte Exporte bereits ein reproduzierbares Ergebnis liefern, kann eine komplexe Plattform zur Profilzusammenführung überflüssig sein.
Die Hauptrisiken sind eine unvollständige Historie, die falsche Zusammenführung von Personen und versteckte Änderungen der Methodik. Es ist besser, ehrlich über den ersten bekannten Kauf zu berichten, als ihn als ersten Kauf überhaupt zu bezeichnen. Ein verlässliches Gesamtergebnis hat eine Erklärung und eine für Ausnahmen verantwortliche Person.
Wenn das Problem im Datenaustausch zwischen Website, Zahlung und CRM liegt, besprechen Sie mit GL.ua (Glyanets) die Entwicklung eines Onlineshops mit CRM und Integrationen. Bereiten Sie eine Beschreibung des Ablaufs und anonymisierte Beispiele für Abweichungen vor, um Anpassungen und Abnahmekriterien zu bewerten.
Nur ein Schritt zu Ihrer perfekten Website
