Kundendaten sind nicht nur eine Liste aus Namen und E-Mail-Adressen. In einem E-Commerce-Shop bilden sie die Account-Ebene, die Identität, Adressen, Bestellhistorie, Preisberechtigung, Steuerbehandlung, Marketingstatus, Supportkontext, B2B-Beziehungen und Segmentierungslogik miteinander verbindet.
Ein Kundendatensatz kann im Admin einfach aussehen und im Hintergrund dennoch mehrere operative Bedeutungen tragen. Eine Plattform speichert einen Kundentyp vielleicht als Gruppe, eine andere verwendet Tags, Kundenattribute, Unternehmen, Preislisten, Kundensegmente, Erweiterungen oder ein externes CRM. Derselbe Kunde kann sich deshalb auf einer neuen Plattform anders verhalten, obwohl die sichtbaren Profildaten vollständig erscheinen.
Die technische Prüfung sollte damit beginnen, das Kundendatenmodell, die Funktion der einzelnen Kundenfelder und die Abhängigkeit von nativer Plattformlogik gegenüber Apps, Plugins, Modulen oder externen Systemen zu verstehen.
Kundendaten bilden die Identitätsebene des Accounts
Das Kundenprofil ist das sichtbare Zentrum des Kundenmodells, aber selten das vollständige Modell. Das Profil identifiziert normalerweise die Person oder Organisation. Verknüpfte Datensätze bestimmen, wie diese Person kaufen, Bestellungen empfangen, Preise erhalten, mit dem Shop kommunizieren und in Reports erscheinen kann.
Ein typisches Kundenmodell kann umfassen:
| Datenebene | Typische Informationen | Betroffene Shop-Funktion |
|---|---|---|
| Identität | Name, E-Mail, Telefonnummer, Account-ID, Benutzername, Kundennummer | Account-Suche, Login-Erkennung, Support-Suche, Bestellzuordnung |
| Kontaktdaten | Rechnungs- und Lieferadresse, Telefon, Firmenname | Checkout, Lieferung, Rechnung, Steuerberechnung, Kundenkomfort |
| Account-Status | aktiv, deaktiviert, eingeladen, genehmigt, ausstehend, gesperrt | Login, Account-Aktivierung, eingeschränkter Einkauf |
| Klassifizierung | Gruppe, Tag, Stufe, Segment, Kundentyp, Unternehmensrolle | Preise, Katalogsichtbarkeit, Aktionen, Steuern, B2B-Abläufe |
| Einwilligung und Kommunikation | Marketing-Opt-in, SMS-Einwilligung, Newsletterstatus, Sperrstatus | Kampagnen, Zielgruppen, compliance-sensible Kommunikation |
| Operativer Kontext | Notizen, benutzerdefinierte Attribute, Vertriebs- oder Account-Verantwortliche, externe ID | Support, CRM-Abgleich, ERP/POS-Verknüpfung, B2B-Account-Betreuung |
| Beziehungshistorie | Bestellungen, Retouren, Abonnements, Rewards, Reviews, Tickets | Kundenservice, Loyalty-Logik, Reporting, Wiederkaufsanalyse |
Das Profil ist damit nur ein Teil der Kundenkontinuität. Ein technisch erfolgreicher Kundenimport kann dennoch scheitern, wenn Account-Logik, Klassifizierung oder externe Kennungen nicht richtig dargestellt werden.
Profilfelder und Authentifizierung sind getrennte Strukturen
Kundenprofildaten und Account-Authentifizierung sollten getrennt betrachtet werden. Eine Plattform kann Namen, E-Mail-Adressen, Telefonnummern und Adressen importieren, gleichzeitig aber einschränken, wie Passwörter, Passwort-Hashes, Account-Aktivierung oder Login-Sitzungen übernommen werden.
Typische Authentifizierungsstrukturen sind:
- E-Mail-Adresse oder Benutzername als Login-Kennung;
- Passwort-Hash, Salt oder plattformspezifisches Passwortformat;
- Account-Aktivierungsstatus;
- Einladungsstatus;
- Pflicht zum Zurücksetzen des Passworts;
- Social-Login-Verbindung;
- Multi-Faktor-Authentifizierungsstatus;
- B2B-Account-Freigabe;
- deaktivierter, gesperrter oder suspendierter Account.
Diese Felder verhalten sich nicht wie gewöhnliche Profildaten. Passwortdaten sind häufig durch Sicherheitsregeln der Plattform geschützt und nicht in wiederverwendbarer Form verfügbar. Auch wenn Kundenprofile sauber übertragen werden, können bestehende Kunden deshalb eine Account-Einladung, ein neues Passwort oder einen Ablauf für den ersten Login benötigen.
Adressen sind abhängige Datensätze mit Checkout-Bezug
Kundenadressen sind meist abhängige Datensätze am Kundenkonto. Sie können als eine Standardadresse, mehrere Adressbucheinträge, getrennte Rechnungs- und Lieferadressen oder als Adress-Snapshots auf Bestellebene gespeichert sein.
Adressdatensätze enthalten häufig:
- Vor- und Nachname;
- Firmenname;
- Straßenzeilen;
- Ort;
- Bundesland, Provinz oder Region;
- Postleitzahl;
- Ländercode;
- Telefonnummer;
- steuerbezogene Adressfelder;
- Kennzeichnung als Standard-Rechnungs- oder Lieferadresse;
- Adress-IDs der Plattform oder angeschlossener Systeme.
Die Komplexität entsteht aus Validierungsregeln. Eine Plattform erlaubt vielleicht freie Regionsangaben, während eine andere standardisierte Bundesland- oder Provinzcodes verlangt. Manche Plattformen setzen Telefonnummern für den Versand voraus, andere nicht. Manche speichern mehrere Adressen dauerhaft im Account, andere behandeln zuletzt im Checkout verwendete Adressen anders.
Das Adressmodell beeinflusst mehr als die Anzeige. Es kann Versandkosten, Steuern, Betrugsprüfung, Rechnungsstellung, ERP-Synchronisierung und Kundenservice-Prozesse verändern.
Segmentierung verleiht Kundendatensätzen kommerzielle Funktion
Segmentierung macht aus Kundendaten Geschäftslogik. Segment, Gruppe, Tag, Kundentyp, Unternehmensrolle oder Stufe können bestimmen, was ein Kunde sieht und welche Regeln beim Browsen, Checkout und in der Kommunikation gelten.
Segmentierung kann steuern:
- Retail- gegenüber Wholesale-Behandlung;
- B2B- oder Unternehmenszugang;
- kundenspezifische Preislisten;
- Kundengruppenpreise;
- Sichtbarkeit von Katalogen oder Kollektionen;
- eingeschränkten Produktzugang;
- Steuerbefreiung oder Umsatzsteuerbehandlung;
- Aktionsberechtigung;
- verfügbare Versandarten;
- verfügbare Zahlungsarten;
- Loyalty-Stufe oder Reward-Status;
- Abonnement-, Mitgliedschafts- oder Freigabestatus;
- Marketing-Zielgruppen;
- Support-Priorität oder Account-Verantwortung.
Wichtig ist die Trennung von Bezeichnung und Funktion. Eine migrierte Kundengruppe namens Wholesale bewahrt nicht automatisch Wholesale-Preise, Katalogbeschränkungen, Zahlungsbedingungen, Steuerbehandlung oder Freigabestatus. Die Gruppe kann als Feld übertragen werden, während die Funktion über Preis-, Katalog-, B2B-, Aktions- oder Erweiterungslogik der Zielplattform neu aufgebaut werden muss.
Plattformen verwenden unterschiedliche Klassifizierungsmodelle
Kundenklassifizierung unterscheidet sich stark zwischen Plattformen. Einige nutzen feste Gruppen, andere flexible Tags oder dynamische, regelbasierte Segmente. B2B-Kunden können durch Unternehmenskonten und Kontakte dargestellt werden. Andere Shops sind stark von Erweiterungen oder externen Systemen abhängig.
| Plattformmodell | Wie Kundenbedeutung typischerweise dargestellt wird | Technisches Risiko |
|---|---|---|
| Kundengruppenmodell | Kunden gehören einer oder mehreren vordefinierten Gruppen an | Gruppennamen können übertragen werden, ohne dass Preis- oder Steuerregeln folgen |
| Tag-basiertes Modell | Freie Tags klassifizieren Kunden für Regeln, Filter oder Apps | Tags können inkonsistent werden, wenn sie zugleich Label und operativer Auslöser sind |
| Regelbasiertes Segmentmodell | Segmente werden aus Verhalten, Historie, Standort, Umsatz oder Tags berechnet | Mitgliedschaft muss eventuell neu berechnet statt statisch importiert werden |
| B2B-Unternehmensmodell | Unternehmen enthalten Kontakte, Rollen, Standorte, Rechte, Preislisten oder Zahlungsbedingungen | Einzelne Kundenprofile bewahren Unternehmensfunktion nicht automatisch |
| Attributreiches Modell | Benutzerdefinierte Kundenfelder speichern operative Daten | Vor Import können Schema, Mapping oder Erweiterungsunterstützung nötig sein |
| Erweiterungsgesteuertes Modell | Apps, Plugins, Module oder Integrationen definieren Kundenlogik | Kerndaten können migrieren, während die Funktion außerhalb des Exports bleibt |
| Externes Systemmodell | CRM, ERP, POS, Loyalty, Subscription oder Support besitzen Teile der Kundenbedeutung | Externe IDs und Synchronisationsregeln werden ebenso wichtig wie Profilfelder |
Eine belastbare Prüfung identifiziert das Modell der Quellplattform, die Möglichkeiten der Zielplattform und welche Klassifizierungen nur Bezeichnungen beziehungsweise echte Verhaltenstreiber sind.
B2B-Kundenstrukturen sind häufig Beziehungsmodelle
B2B-Daten gehen häufig über einzelne Accounts hinaus. Ein Käufer kann einem Unternehmen, einer Niederlassung, einem Standort, einer Abteilung, Rolle, Freigabelogik, Angebotsprozess, Zahlungsbedingung oder einer Preisliste zugeordnet sein.
B2B- und Wholesale-Modelle können enthalten:
- Unternehmenskonten;
- mehrere Käufer unter einem Unternehmen;
- Käuferrollen und Berechtigungen;
- Unternehmensstandorte;
- Abrechnungskonten;
- Kauflimits;
- Zahlungsbedingungen;
- Steuerbefreiungsfelder;
- verhandelte Preislisten;
- Angebotsberechtigungen;
- Account-Freigabestatus;
- zugewiesene Vertriebsmitarbeiter;
- ERP-Kunden-IDs;
- eingeschränkte Kataloge oder kundenspezifische Sortimente.
Ein flacher Kundenimport kann diese Struktur nicht vollständig darstellen, wenn die Zielplattform Unternehmensdatensätze, Rollen oder Preislistenbeziehungen erwartet. Es geht daher nicht nur darum, ob Kundenprofile importiert werden können, sondern ob das gesamte Beziehungsmodell dargestellt werden kann.
Marketing-Einwilligung und Kommunikationsstatus brauchen eine präzise Bedeutung
Marketing- und Kommunikationsdaten dürfen nicht wie gewöhnliche Kontaktdaten behandelt werden. E-Mail, Telefon und Einwilligungsstatus beeinflussen Zielgruppenbildung, Kampagnensperren, transaktionale Nachrichten, Newsletter-Abonnements und Kundenvertrauen.
Typische Felder sind:
- E-Mail-Adresse;
- Telefonnummer;
- Einwilligung in E-Mail-Marketing;
- SMS-Einwilligung;
- Newsletterstatus;
- Sperr- oder Abmeldestatus;
- Zeitpunkt der Einwilligung;
- Quelle der Einwilligung;
- Sprach- oder Locale-Präferenz;
- Kunden-Tags für Kampagnenauswahl;
- IDs externer Marketingplattformen.
Plattformen und Marketing-Systeme können diese Felder unterschiedlich definieren. Ein System speichert Newsletterstatus als Kundenattribut, ein anderes Einwilligungen in der Marketingplattform; ein weiteres trennt transaktionale Kommunikation von werblicher Zustimmung. Eine falsche Interpretation kann zu ungeeigneter Zielgruppenauswahl oder unbeabsichtigten Kommunikationsänderungen nach dem Launch führen.
Kundenhistorie liegt häufig außerhalb des Profils
Kundenhistorie ist meist über verknüpfte Datenarten und Datensätze verteilt. Bestellungen, Rückerstattungen, Retouren, Reviews, Reward-Punkte, Abonnements, Support-Tickets und CRM-Notizen können einen Kunden referenzieren, ohne im Profil selbst gespeichert zu sein.
Wichtige Beziehungen sind:
- Bestellungen müssen dem richtigen Kundenkonto zugeordnet bleiben;
- Gastbestellungen werden nicht zwingend automatisch mit Accounts verbunden;
- historische Adressen können auf Bestellungen statt im Adressbuch gespeichert sein;
- Loyalty-Guthaben kann einem Loyalty-System statt der Kundentabelle gehören;
- Abonnementstatus kann von einer App oder einem Zahlungsanbieter gesteuert werden;
- Support-Tickets und CRM-Aktivitäten können externe Kunden-IDs verwenden;
- Reviews können E-Mail, Account-ID, Product ID oder IDs des Review-Systems referenzieren.
Ein Kundenprofil kann daher migrieren, während der Kundenkontext fragmentiert bleibt. Die technische Prüfung muss festlegen, welche verknüpften Datensätze erhalten bleiben müssen und welche außerhalb des Standardumfangs für Kundendaten liegen.
Dynamische Segmente sind nicht dasselbe wie gespeicherte Segmente
Segmentierung kann gespeichert oder berechnet sein. Bei gespeicherter Klassifizierung trägt der Kundendatensatz Gruppe, Tag, Stufe oder Feldwert. Bei dynamischer Segmentierung berechnet die Plattform die Zugehörigkeit anhand von Regeln, etwa Bestellanzahl, Gesamtumsatz, Standort, gekauftem Produkt, letztem Bestelldatum oder Marketingverhalten.
Dynamische Segmente können abhängen von:
- verfügbarer Bestellhistorie;
- Produkt- und Kategoriebeziehungen;
- Land oder Region der Kundenadresse;
- Kunden-Tags oder benutzerdefinierten Feldern;
- Customer Lifetime Value;
- Kaufhäufigkeit;
- Warenkorbabbruch- oder Browsing-Verhalten;
- Loyalty- oder Abonnementstatus;
- Marketing-Interaktionsdaten.
Beim Plattformwechsel lässt sich ein dynamisches Segment möglicherweise nicht sinnvoll als feste Liste importieren. Die Regel muss eventuell auf der Zielplattform oder im angeschlossenen Marketing-, CRM- oder Analytics-System neu aufgebaut werden. Eine statische Bezeichnung bewahrt nur die Mitgliedschaft zu einem Zeitpunkt; eine dynamische Regel bewahrt die Logik, die das Segment fortlaufend aktualisiert.
Externe Kennungen schützen Kundenbeziehungen zwischen Systemen
Viele Shops nutzen Kundenkennungen, die außerhalb der E-Commerce-Plattform relevant sind. Sie verbinden Kunden mit ERP, CRM, POS, Helpdesk, Marketingplattform, Steuersystem, Loyalty- oder Abonnementsystem.
Beispiele:
- ERP-Kundennummer;
- CRM-Kontakt-ID;
- POS-Kunden-ID;
- Loyalty-Account-Nummer;
- Subscription-Kunden-ID;
- Steuer- oder VAT-Prüfreferenz;
- Support-Desk-Requester-ID;
- Unternehmens-Account-ID;
- Marketplace-Buyer-ID;
- Kunden-ID der bisherigen Plattform.
Verlust oder falsche Neuzuordnung solcher IDs kann Abstimmung, Support-Suche, automatisierte Segmentierung, Account-Reporting und Integrationen beschädigen. Die Prüfung muss klären, wo die Kennungen gespeichert sind und ob die Zielplattform sie sicher bewahren kann.
Auswirkungen der Migration hängen von der Funktion ab, nicht nur von Feldern
Die Qualität einer Kundendatenmigration lässt sich nicht allein an Datensatzanzahlen messen. Aussagekräftiger ist, ob jeder wichtige Kundentyp auf der Zielplattform weiterhin richtig funktioniert.
| Kundenszenario | Was geprüft werden sollte |
|---|---|
| Wiederkehrender Retail-Kunde | Profil, Adressbuch, Bestellzuordnung, erster Login oder Passwort-Reset |
| Kunde mit mehreren Adressen | Standardadressen, Checkout-Nutzbarkeit, Trennung von Rechnung und Lieferung |
| Wholesale-Kunde | Gruppen-/Unternehmenszuordnung, Preise, Katalogzugang, Steuerbehandlung |
| B2B-Unternehmenskäufer | Unternehmensbeziehung, Rollenrechte, Standortzugriff, Zahlungsbedingungen |
| Marketing-Abonnent | Einwilligung, Zielgruppenzugehörigkeit, Sperrstatus, Kommunikationsberechtigung |
| Steuerbefreiter Kunde | Befreiungsfeld, Steuerberechnung und verwendete Nachweise |
| Kunde mit externer ID | CRM/ERP/POS-Abgleich, Integrationskontinuität, Support-Suche |
| Kunde mit Loyalty- oder Abonnementhistorie | Verknüpfte externe Datensätze, Statusinterpretation, Verhalten nach Launch |
Wenn ein erforderliches Ergebnis von benutzerdefinierten Kundenfeldern, Unternehmensstrukturen, Erweiterungslogik, externen Kennungen oder nicht standardisierter Segmentierung abhängt, kann eine erweiterte Feld- oder Beziehungszuordnung, Werttransformation, Zielkonfiguration oder Prüfung einer individuellen Migrationslösung nötig sein. Entscheidend ist die Geschäftsfunktionsweise, die erhalten bleiben muss, nicht lediglich der übertragene Feldname.
Kundendaten vor der Migration prüfen
Ein praktisches Audit trennt Profilvollständigkeit von Account-Funktion.
Vor der Migration sollten Sie prüfen:
- welche Profilfelder auf der Zielplattform erforderlich sind;
- ob E-Mail-Adressen eindeutig, doppelt, fehlend oder geteilt sind;
- ob Telefon- und Adressformate die Validierungsregeln der Zielplattform erfüllen;
- welche Gruppen, Tags, Stufen oder Segmente Verhalten steuern;
- ob Segmentierung gespeichert, regelbasiert oder erweiterungsgesteuert ist;
- welche Kunden von B2B-Unternehmensstrukturen oder Wholesale-Logik abhängen;
- welche Kundenfelder nativ und welche benutzerdefiniert oder erweiterungseigen sind;
- welche externen Kennungen nach Launch verfügbar bleiben müssen;
- ob Marketing-Einwilligungsfelder eine klare Bedeutung besitzen;
- ob Bestellhistorie, Reviews, Loyalty, Abonnements oder Support-Datensätze verknüpft bleiben müssen;
- welche Kundentypen in repräsentative Tests gehören.
Die beste Stichprobe umfasst normale Retail-Accounts, Kunden mit mehreren Adressen, Wholesale- oder B2B-Accounts, steuerbefreite Kunden, Marketing-Abonnenten, Kunden mit externen IDs sowie Accounts, deren Funktion von Apps, Plugins, Modulen oder externen Systemen abhängt.
Fazit
Kundendatenmodelle bestimmen, wie eine E-Commerce-Plattform Personen, Unternehmen, Berechtigungen, Adressen, Kommunikationspräferenzen, Preisberechtigungen und Kundenbeziehungen erkennt. Das sichtbare Profil ist nur der Ausgangspunkt. Technisch entscheidend ist, welche Felder Identität darstellen, welche Verhalten steuern, welche Klassifizierungen dynamisch berechnet werden und welche Bedeutungen Erweiterungen oder externe Systeme besitzen.
Die Prüfung sollte nachweisen, dass wichtige Account-Szenarien nach der Migration weiterhin funktionieren: wiederkehrende Kunden werden erkannt, Adressen sind nutzbar, B2B-/Wholesale-Beziehungen korrekt dargestellt, Einwilligungsstatus sorgfältig interpretiert und externe Kennungen bleiben dort verbunden, wo das Geschäft sie benötigt. Wenn Funktion von benutzerdefinierten Feldern, Segmentregeln, Unternehmensstrukturen oder externen IDs abhängt, muss geklärt werden, ob direkte Zuordnung ausreicht oder Transformation, Zielkonfiguration oder individuelle Migrationsplanung erforderlich ist.
Häufige Fragen
Ist die Migration des Kundenprofils dasselbe wie das Bewahren des Kundenzugangs?
Nein. Kundenprofile und Authentifizierung sind getrennte Ebenen. Namen, E-Mail-Adressen, Telefonnummern und Adressen können migrieren, während Passwörter, Aktivierungsstatus oder erster Login den Sicherheitsregeln der Zielplattform folgen müssen.
Warum können Kundengruppen oder Tags migrieren und trotzdem anders funktionieren?
Gruppe oder Tag sind häufig nur Klassifizierungen. Preise, Katalogsichtbarkeit, Steuerbehandlung, Aktionen und B2B-Zugang können von getrennten Plattformregeln, Preislisten, Apps, Plugins, Modulen oder externen Systemen gesteuert werden.
Was ist der Unterschied zwischen gespeicherter und dynamischer Segmentierung?
Gespeicherte Segmentierung liegt als Gruppe, Tag, Stufe oder Feld direkt am Kundendatensatz. Dynamische Segmentierung wird aus Regeln wie Bestellhistorie, Umsatz, Standort, gekauften Produkten oder Marketingverhalten berechnet. Solche Regeln müssen möglicherweise neu aufgebaut werden, statt nur eine statische Mitgliedschaft zu importieren.
Warum sind externe Kunden-IDs wichtig?
Sie verbinden Kundendaten mit ERP, CRM, POS, Loyalty-, Subscription-, Marketing-, Steuer- und Support-Systemen. Gehen diese IDs verloren oder ändern sie sich ungeplant, können angeschlossene Systeme Kunden nach der Migration nicht mehr zuverlässig zuordnen.
Welche Kundendatensätze sollten zuerst validiert werden?
Priorität haben Kunden mit operativer Bedeutung: wiederkehrende Käufer, Accounts mit mehreren Adressen, Wholesale-/B2B-Kunden, steuerbefreite Kunden, Marketing-Abonnenten, Kunden mit externen IDs und Accounts mit Loyalty-, Abonnement-, Mitgliedschafts- oder Freigabeprozessen.