Best Practices für die Datenmodellierung
Experience Data Model (XDM) ist das zentrale Framework, das Kundenerlebnisdaten standardisiert, indem gemeinsame Strukturen und Definitionen für nachgelagerte Adobe Experience Platform-Services bereitgestellt werden. Durch die Einhaltung von XDM-Standards können alle Kundenerlebnisdaten in eine gemeinsame Darstellung integriert und verwendet werden, um wertvolle Einblicke aus Kundenaktionen zu gewinnen, Kundenzielgruppen zu definieren und Kundenattribute für Personalisierungszwecke auszudrücken.
Da XDM sehr vielseitig und designanpassbar ist, ist es wichtig, bei der Erstellung Ihrer Schemas Best Practices für die Datenmodellierung zu befolgen. In diesem Dokument werden die wichtigsten Entscheidungen und Überlegungen behandelt, die Sie beim Zuordnen Ihrer Kundenerlebnisdaten zu XDM treffen müssen.
Erste Schritte
Lesen Sie vor dem Lesen dieses Handbuchs die XDM-System - Übersicht für eine allgemeine Einführung in XDM und seine Rolle innerhalb von Experience Platform.
Da sich dieses Handbuch ausschließlich auf wichtige Aspekte im Zusammenhang mit der Schemagestaltung konzentriert, wird dringend empfohlen, die Grundlagen der Schemakomposition für detaillierte Erläuterungen der einzelnen Schemaelemente, die in diesem Handbuch erwähnt werden.
Zusammenfassung der Best Practices summary
Der empfohlene Ansatz zum Entwerfen Ihres Datenmodells für die Verwendung in Experience Platform kann wie folgt zusammengefasst werden:
- Machen Sie sich mit den geschäftlichen Anwendungsfällen für Ihre Daten vertraut.
- Identifizieren Sie die primären Datenquellen, die für diese Anwendungsfälle in Platform integriert werden sollten.
- Identifizieren Sie alle sekundären Datenquellen, die ebenfalls von Interesse sein könnten. Wenn beispielsweise derzeit nur eine der Geschäftseinheiten in Ihrem Unternehmen daran interessiert ist, ihre Daten nach Platform zu portieren, könnte eine ähnliche Geschäftseinheit in Zukunft auch daran interessiert sein, ähnliche Daten zu portieren. Die Berücksichtigung dieser sekundären Quellen hilft, das Datenmodell in Ihrem gesamten Unternehmen zu standardisieren.
- Erstellen Sie ein allgemeines Entitätsbeziehungsdiagramm (Entity Relationship Diagram, ERD) für die identifizierten Datenquellen.
- Konvertieren Sie das allgemeine ERD in ein Platform-orientiertes ERD (einschließlich Profilen, Erlebnisereignissen und Lookup-Entitäten).
Die Schritte zur Identifizierung der für Ihre geschäftlichen Anwendungsfälle erforderlichen Datenquellen variieren von Organisation zu Organisation. Während sich die restlichen Abschnitte in diesem Dokument auf die letzteren Schritte der Organisation und Erstellung eines ERD nach der Identifizierung der Datenquellen konzentrieren, können die Erläuterungen der verschiedenen Diagrammkomponenten für Ihre Entscheidungen Informationen darüber liefern, welche Datenquellen nach Platform migriert werden sollen.
Erstellen eines allgemeinen ERD create-an-erd
Nachdem Sie die Datenquellen ermittelt haben, die Sie in Platformerstellen Sie eine allgemeine ERD, die Ihnen dabei hilft, Ihre Daten XDM-Schemas zuzuordnen.
Das folgende Beispiel stellt ein vereinfachtes ERD für eine Firma dar, die Daten in Platform integrieren möchte. Das Diagramm zeigt die wesentlichen Entitäten, die in XDM-Klassen unterteilt werden sollten, darunter Kundenkonten, Hotels, Adressen und mehrere häufige E-Commerce-Ereignisse.
Sortieren von Entitäten in Profil-, Lookup- und Ereigniskategorien sort-entities
Nachdem Sie ein ERD erstellt haben, um die wesentlichen Entitäten zu identifizieren, die Sie in Platform integrieren möchten, müssen diese Entitäten nach Profil-, Lookup- und Ereigniskategorien sortiert werden:
Überlegungen zum Sortieren von Entitäten considerations
Die folgenden Abschnitte enthalten weitere Anleitungen zum Sortieren Ihrer Entitäten in die oben genannten Kategorien.
Veränderliche und unveränderliche Daten mutable-and-immutable-data
Eine grundlegende Möglichkeit zur Sortierung zwischen Entitätskategorien besteht darin, ob die erfassten Daten veränderlich sind oder nicht.
Attribute, die zu Profilen oder Lookup-Entitäten gehören, sind normalerweise veränderlich. Beispielsweise können sich die Präferenzen einer Kundin oder eines Kunden im Laufe der Zeit ändern, und die Parameter eines Abonnementplans können je nach Markttrends aktualisiert werden.
Im Gegensatz dazu sind Ereignisdaten normalerweise unveränderlich. Da Ereignisse mit einem bestimmten Zeitstempel verbunden sind, ändert sich der von einem Ereignis bereitgestellte „System-Schnappschuss“ nicht. Beispielsweise kann ein Ereignis die Kundenpräferenzen beim Kassengang erfassen. Dies ändert sich auch dann nicht, wenn sich die Kundenpräferenzen später ändern. Ereignisdaten können nach ihrer Aufzeichnung nicht mehr geändert werden.
Zusammenfassend lässt sich sagen, dass Profile und Lookup-Entitäten veränderliche Attribute enthalten und aktuelle Informationen über die von ihnen erfassten Themen darstellen, während es sich bei Ereignissen um unveränderliche Aufzeichnungen des Systems zu einem bestimmten Zeitpunkt handelt.
Kundenattribute customer-attributes
Wenn eine Entität Attribute enthält, die sich auf eine einzelne Kundin oder einen einzelnen Kunden beziehen, ist sie höchstwahrscheinlich eine Profilentität. Beispiele für Kundenattribute sind:
- Persönliche Daten wie Name, Geburtsdatum, Geschlecht und Konto-ID(s).
- Standortinformationen wie Adressen und GPS-Informationen.
- Kontaktinformationen wie Telefonnummern und E-Mail-Adressen.
Tracking von Daten im Laufe der Zeit track-data
Wenn Sie analysieren möchten, wie sich bestimmte Attribute innerhalb einer Entität im Laufe der Zeit ändern, handelt es sich höchstwahrscheinlich um eine Ereignisentität. Das Hinzufügen von Produktelementen zum Warenkorb kann beispielsweise in Platform als Ereignis vom Typ „In den Warenkorb legen“ verfolgt werden:
Anwendungsfälle für die Segmentierung segmentation-use-cases
Bei der Kategorisierung Ihrer Entitäten ist es wichtig, über die Zielgruppen nachzudenken, die Sie für Ihre speziellen geschäftlichen Anwendungsfälle erstellen möchten.
Ein Unternehmen möchte beispielsweise alle „Gold“- oder „Platin“-Mitglieder seines Treueprogramms kennen, die im letzten Jahr mehr als fünf Käufe getätigt haben. Basierend auf dieser Segmentierungslogik können die folgenden Schlussfolgerungen zur Darstellung relevanter Entitäten gezogen werden:
- „Gold“ und „Platin“ stellen den Treuestatus einer Kundin oder eines Kunden dar. Da sich die Segmentierungslogik nur auf den aktuellen Treuestatus von Kundinnen und Kunden bezieht, können diese Daten als Teil eines Profilschemas modelliert werden. Wenn Sie jedoch Änderungen des Treuestatus im Laufe der Zeit verfolgen möchten, können Sie auch ein zusätzliches Ereignisschema für Änderungen des Treuestatus erstellen.
- Käufe sind Ereignisse, die zu einem bestimmten Zeitpunkt auftreten. Die Segmentierungslogik bezieht sich auf Kaufereignisse innerhalb eines bestimmten Zeitfensters. Diese Daten sollten daher als Ereignisschema modelliert werden.
Anwendungsfälle für die Aktivierung activation-use-cases
Zusätzlich zu Überlegungen zu Segmentierungsanwendungsfällen sollten Sie auch die Aktivierungsanwendungsfälle für diese Zielgruppen überprüfen, um zusätzliche relevante Attribute zu identifizieren.
Zum Beispiel hat ein Unternehmen eine Zielgruppe basierend auf der Regel country = US erstellt. Wenn diese Zielgruppe dann für bestimmte nachgelagerte Ziele aktiviert wird, möchte das Unternehmen alle exportierten Profile nach dem Heimat-Bundesstaat filtern. Daher sollte ein state-Attribut auch in der entsprechenden Profilentität erfasst werden.
Aggregierte Werte aggregated-values
Basierend auf dem Anwendungsfall und der Granularität Ihrer Daten sollten Sie entscheiden, ob bestimmte Werte vorab aggregiert werden müssen, bevor sie in eine Profil- oder Ereignisentität aufgenommen werden.
Beispielsweise möchte ein Unternehmen eine Zielgruppe basierend auf der Anzahl der Warenkorbkäufe erstellen. Sie können festlegen, dass diese Daten mit der niedrigsten Granularität integriert werden, indem Sie jedes Kaufereignis mit Zeitstempel als eigene Entität hinzufügen. Dadurch kann sich jedoch manchmal die Anzahl der aufgezeichneten Ereignisse exponentiell erhöhen. Um die Anzahl der erfassten Ereignisse zu reduzieren, können Sie einen Aggregatwert erstellen numberOfPurchases über einen langen oder monatigen Zeitraum. Andere Aggregatfunktionen wie MIN und MAX können ebenfalls auf diese Situationen angewendet werden.
Kardinalität cardinality
Die in Ihrem ERD festgelegten Kardinalitäten können auch einige Hinweise zur Kategorisierung Ihrer Entitäten liefern. Wenn eine Eins-zu-viele-Beziehung zwischen zwei Entitäten besteht, ist die Entität, die die "viele"darstellt, wahrscheinlich eine Ereignisentität. Es gibt jedoch auch Fälle, in denen es sich bei „viele“ um eine Gruppe von Lookup-Entitäten handelt, die als Array innerhalb einer Profilentität bereitgestellt werden.
In der folgenden Tabelle sind einige allgemeine Entitätsbeziehungen und die daraus abgeleiteten Kategorien aufgeführt:
Vor- und Nachteile verschiedener Entitätsklassen pros-and-cons
Der vorherige Abschnitt liefert zwar einige allgemeine Richtlinien zur Kategorisierung von Entitäten, es ist jedoch wichtig zu verstehen, dass es häufig Vor- und Nachteile bei der Auswahl einer Entitätskategorie gegenüber einer anderen geben kann. Die folgende Fallstudie soll veranschaulichen, wie Sie in diesen Situationen Ihre Möglichkeiten abwägen können.
Ein Unternehmen verfolgt die aktiven Abonnements seiner Kundschaft nach, bei denen eine Kundin oder ein Kunde über viele Abonnements verfügen kann. Das Unternehmen möchte auch Abonnements für Anwendungsfälle zur Segmentierung einbeziehen, z. B. alle Benutzende mit aktiven Abonnements finden.
In diesem Szenario hat das Unternehmen zwei Möglichkeiten, die Abonnements einer Kundin oder eines Kunden in seinem Datenmodell darzustellen:
Ansatz 1: Verwenden von Profilattributen profile-approach
Der erste Ansatz besteht darin, ein Array von Abonnements als Attribute in die Profilentität für Kundinnen und Kunden aufzunehmen. Objekte in diesem Array enthalten Felder für category, status, planName, startDate und endDate.
Vorteile
- Eine Segmentierung ist für den vorgesehenen Anwendungsfall möglich.
- Das Schema behält nur die neuesten Abonnementdatensätze für einen Kunden bei.
Nachteile
- Das gesamte Array muss jedes Mal neu aufgenommen werden, wenn Änderungen an einem Feld im Array auftreten.
- Wenn verschiedene Datenquellen oder Geschäftseinheiten Daten in das Array einspeisen, wird es schwierig, das neueste aktualisierte Array über alle Kanäle hinweg zu synchronisieren.
Ansatz 2: Verwenden von Ereignisentitäten event-approach
Der zweite Ansatz besteht darin, Ereignisschemata zur Darstellung von Abonnements zu verwenden. Dazu müssen dieselben Abonnementfelder wie beim ersten Ansatz aufgenommen werden, wobei eine Abonnement-ID, eine Kunden-ID und ein Zeitstempel hinzugefügt werden, aus denen hervorgeht, wann das Abonnementereignis eingetreten ist.
Vorteile
- Segmentierungsregeln können flexibler sein (z. B. Suchen nach allen Kundinnen und Kunden, die ihre Abonnements in den letzten 30 Tagen geändert haben).
- Wenn sich der Abonnementstatus einer Kundin oder eines Kunden ändert, müssen Sie kein langes, potenziell komplexes Array mehr innerhalb der Profilattribute der Kundin oder des Kunden aktualisieren. Dies ist besonders nützlich, wenn gleichzeitige Änderungen an der Abonnement-Liste der Kundin oder des Kunden aus mehreren Quellen auftreten.
Nachteile
- Die Segmentierung wird für den ursprünglich vorgesehenen Anwendungsfall komplexer (Identifizierung des Status der neuesten Abonnements von Kundinnen und Kunden). Die Zielgruppe benötigt jetzt zusätzliche Logik, um das letzte Abonnementereignis zu kennzeichnen, damit ein Kunde seinen Status überprüfen kann.
- Bei Ereignissen besteht ein höheres Risiko, dass sie automatisch ablaufen und aus dem Profilspeicher gelöscht werden. Weitere Informationen finden Sie im Handbuch zum Ablaufen von Erlebnisereignissen.
Erstellen von Schemata basierend auf kategorisierten Entitäten schemas-for-categorized-entities
Nachdem Sie Ihre Entitäten nach Profil-, Lookup- und Ereigniskategorien sortiert haben, können Sie mit der Konvertierung Ihres Datenmodells in XDM-Schemata beginnen. Zu Demonstrationszwecken wurde das zuvor dargestellte Datenmodell im folgenden Diagramm in geeignete Kategorien unterteilt:
Die Kategorie, in der eine Entität eingeordnet wurde, sollte die XDM-Klasse bestimmen, auf der Sie deren Schema basieren. Zur Wiederholung:
- Profilentitäten sollten die XDM Individual Profile-Klasse verwenden.
- Ereignisentitäten sollten die XDM ExperienceEvent-Klasse verwenden.
- Lookup-Entitäten sollten benutzerdefinierte XDM-Klassen verwenden, die von Ihrem Unternehmen definiert wurden. Profil- und Ereignisentitäten können diese Lookup-Entitäten dann über Schemabeziehungen referenzieren.
LoyaltyAccount-Objekt mit den entsprechenden Treuefeldern für jede Kundin oder jeden Kunden enthalten. Bei einer Eins-zu-viele-Beziehung kann die Entität, die für „viele“ steht, je nach ihrer Komplexität durch ein separates Schema oder ein Array von Profilattributen dargestellt werden.Die folgenden Abschnitte enthalten allgemeine Anleitungen zum Erstellen von Schemata basierend auf Ihrem ERD.
Anwendung eines iterativen Modellierungsansatzes iterative-modeling
Die Regeln zur Schemaentwicklung schreiben vor, dass nur zerstörungsfreie Änderungen an Schemata vorgenommen werden können, nachdem sie implementiert wurden. Mit anderen Worten: Wenn Sie einem Schema ein Feld hinzufügen und Daten für dieses Feld aufgenommen wurden, kann das Feld nicht mehr entfernt werden. Daher ist es wichtig, bei der Ersterstellung Ihrer Schemata einen iterativen Modellierungsansatz anzuwenden, beginnend mit einer vereinfachten Implementierung, die im Laufe der Zeit immer komplexer wird.
Wenn Sie nicht sicher sind, ob ein bestimmtes Feld für die Aufnahme in ein Schema erforderlich ist, empfiehlt es sich, es auszuschließen. Wenn später festgestellt wird, dass das Feld erforderlich ist, kann es jederzeit bei der nächsten Iteration des Schemas hinzugefügt werden.
Identitätsfelder identity-fields
In Experience Platform werden als Identitäten markierte XDM-Felder verwendet, um Informationen über einzelne Kundinnen und Kunden aus mehreren Datenquellen zusammenzufügen. Obwohl ein Schema mehrere Felder haben kann, die als Identitäten markiert sind, muss eine einzige primäre Identität definiert werden, damit das Schema zur Verwendung in aktiviert werden kann Real-Time Customer Profile. Ausführlichere Informationen zum Anwendungsfall für diese Felder finden Sie im Abschnitt zu Identitätsfeldern in den Grundlagen der Schemakomposition.
Beim Entwerfen Ihrer Schemas sind alle Primärschlüssel in Ihren relationalen Datenbanktabellen wahrscheinlich Kandidaten für primäre Identitäten. Weitere Beispiele für anwendbare Identitätsfelder sind E-Mail-Adressen, Telefonnummern, Konto-IDs und ECID der Kundschaft.
Schemafeldgruppen für Adobe-Anwendungen adobe-application-schema-field-groups
Experience Platform bietet mehrere vordefinierte XDM-Schemafeldgruppen zur Erfassung von Daten, die sich auf die folgenden Adobe-Anwendungen beziehen:
- Adobe Analytics
- Adobe Audience Manager
- Adobe Campaign
- Adobe Target
Sie können beispielsweise die Adobe Analytics ExperienceEvent-Vorlage Feldergruppe Zuordnen Analytics-spezifische Felder für Ihre XDM-Schemas. Je nach den Adobe-Anwendungen, mit denen Sie arbeiten, sollten Sie diese von Adobe bereitgestellten Feldergruppen in Ihren Schemata verwenden.
Feldergruppen der Adobe-Anwendungen weisen automatisch eine standardmäßige primäre Identität über das Feld identityMap zu, ein systemgeneriertes, schreibgeschütztes Objekt, das standardmäßige Identitätswerte für einzelne Kundinnen und Kunden zuordnet.
Bei Adobe Analytics ist ECID die standardmäßige primäre Identität. Wenn ein ECID-Wert nicht von einem Kunden bereitgestellt wird, wird als primäre Identität stattdessen "AAID"verwendet.
Datenvalidierungsfelder data-validation-fields
Wenn Sie Daten in den Daten-Pool erfassen, wird die Datenvalidierung nur für eingeschränkte Felder erzwungen. Um ein bestimmtes Feld während einer Batch-Erfassung zu validieren, müssen Sie das Feld im XDM-Schema als eingeschränkt markieren. Um zu verhindern, dass fehlerhafte Daten in Platform aufgenommen werden, sollten Sie beim Erstellen Ihrer Schemas die Kriterien für die Validierung auf Feldebene definieren.
Um Einschränkungen für ein bestimmtes Feld festzulegen, wählen Sie das Feld im Schema-Editor aus, um die Feldeigenschaften Seitenleiste. Siehe die Dokumentation unter Typspezifische Feldeigenschaften für genaue Beschreibungen der verfügbaren Felder.
Tipps zur Gewährleistung der Datenintegrität data-integrity-tips
Im Folgenden finden Sie eine Sammlung von Vorschlägen zur Gewährleistung der Datenintegrität bei der Erstellung eines Schemas.
- Primäre Identitäten berücksichtigen: Bei Adobe-Produkten wie Web SDK, Mobile SDK, Adobe Analytics und Adobe Journey Optimizer wird die
identityMap-Feld dient oft als primäre Identität. Vermeiden Sie die Benennung zusätzlicher Felder als primäre Identitäten für dieses Schema. - Vermeiden von
_idals Identität: Vermeiden Sie die Verwendung der_id-Feld in Experience Event-Schemas als Identität. Sie ist für die Eindeutigkeit von Datensätzen und nicht zur Verwendung als Identität gedacht. - Festlegen von Längenbeschränkungen: Es empfiehlt sich, Mindest- und Höchstlängen für Felder festzulegen, die als Identitäten gekennzeichnet sind. Ein Warnhinweis-Trigger, wenn Sie versuchen, einem Identitätsfeld einen benutzerdefinierten Namespace zuzuweisen, ohne die Mindest- und Höchstlängenbeschränkungen zu erfüllen. Diese Einschränkungen helfen bei der Gewährleistung von Konsistenz und Datenqualität.
- Anwenden von Mustern für konsistente Werte: Wenn Ihre Identitätswerte einem bestimmten Muster entsprechen, sollten Sie die Muster -Einstellung, um diese Einschränkung zu erzwingen. Diese Einstellung kann Regeln wie nur Ziffern, Groß- oder Kleinbuchstaben oder bestimmte Zeichenkombinationen enthalten. Verwenden Sie reguläre Ausdrücke, um Muster in Ihren Zeichenfolgen abzugleichen.
- eVars in Analytics-Schemata begrenzen: In der Regel sollte für ein Analytics-Schema nur ein eVar als Identität benannt sein. Wenn Sie mehr als eine eVar als Identität verwenden möchten, sollten Sie überprüfen, ob die Datenstruktur optimiert werden kann.
- Eindeutigkeit eines ausgewählten Felds gewährleisten: Ihr ausgewähltes Feld sollte im Vergleich zur primären Identität im Schema eindeutig sein. Ist dies nicht der Fall, markieren Sie es nicht als Identität. Wenn beispielsweise mehrere Kunden dieselbe E-Mail-Adresse angeben können, ist dieser Namespace keine geeignete Identität. Dieses Prinzip gilt auch für andere Identitäts-Namespaces wie Telefonnummern.
- Beschränkt Trigger-Warnungen für benutzerdefinierte Namespace-Felder: Legen Sie Begrenzungen fest, um eine Warnung Trigger, wenn ein Schemafeld mit einem benutzerdefinierten Namespace markiert ist, ohne die Mindest- und Höchstlänge anzugeben. Die Warnung dient als wichtige Vorsichtsmaßnahme zur Wahrung der Datenintegrität. Siehe Typspezifische Feldeigenschaften Dokumentation für Informationen zum Festlegen von Einschränkungen für ein bestimmtes Feld.
Nächste Schritte
In diesem Dokument wurden die allgemeinen Richtlinien und Best Practices zum Entwerfen Ihres Datenmodells für Experience Platform behandelt. Zur Zusammenfassung:
- Verwenden Sie einen Oben-nach-unten-Ansatz, indem Sie Ihre Datentabellen nach Profil-, Lookup- und Ereigniskategorien sortieren, bevor Sie Ihre Schemata erstellen.
- Es gibt oft mehrere Ansätze und Optionen beim Entwerfen von Schemata für unterschiedliche Zwecke.
- Ihr Datenmodell sollte Ihre geschäftlichen Anwendungsfälle wie Segmentierung oder Analyse der Customer Journey unterstützen.
- Machen Sie Ihre Schemata so einfach wie möglich und fügen Sie nur dann neue Felder hinzu, wenn dies unbedingt erforderlich ist.
Wenn Sie fertig sind, finden Sie im Tutorial zum Erstellen eines Schemas in der Benutzeroberfläche schrittweise Anweisungen zum Erstellen eines Schemas, Zuweisen der entsprechenden Klasse für die Entität und Hinzufügen von Feldern, um diesen Daten zuzuordnen.