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 werden, die es Ihnen ermöglicht, wertvolle Erkenntnisse aus Kundenaktionen zu gewinnen, Kundenzielgruppen zu definieren und Kundenattribute für Personalisierungszwecke auszudrücken.
Da XDM vom Design her äußerst vielseitig und anpassbar ist, ist es daher wichtig, bei der Erstellung Ihrer Schemata Best Practices für die Datenmodellierung einzuhalten. In diesem Dokument werden die wichtigsten Entscheidungen und Überlegungen behandelt, die Sie beim Zuordnen Ihrer Kundenerlebnisdaten zu XDM treffen müssen.
Bevor Sie dieses Handbuch lesen, sollten Sie sich mit der Übersicht zum XDM-System beschäftigen, um eine allgemeine Einführung in XDM und seine Rolle in Experience Platform zu erhalten.
Darüber hinaus konzentriert sich dieses Handbuch ausschließlich auf wichtige Aspekte beim Design von Schemata. Es wird daher dringend empfohlen, sich mit den Grundlagen der Schemakomposition zu beschäftigen, um detaillierte Erläuterungen zu den einzelnen Schemaelementen, die in diesem Handbuch erwähnt werden, zu erhalten.
Der empfohlene Ansatz zum Entwerfen Ihres Datenmodells für die Verwendung in Experience Platform kann wie folgt zusammengefasst werden:
Die Schritte zur Identifizierung der für Ihre geschäftlichen Anwendungsfälle erforderlichen Datenquellen variieren von einer Organisation zur anderen. 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.
Nachdem Sie die Datenquellen ermittelt haben, die Sie in Platform integrieren möchten, erstellen Sie ein allgemeines ERD, das 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.
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:
Kategorie | Beschreibung |
---|---|
Profilentitäten | Profilentitäten stellen Attribute dar, die sich auf eine einzelne Person beziehen, normalerweise eine Kundin oder einen Kunden. Entitäten, die unter diese Kategorie fallen, sollten durch Schemata auf Basis der XDM Individual Profile-Klasse dargestellt werden. |
Lookup-Entitäten | Lookup-Entitäten stellen Konzepte dar, die sich auf eine einzelne Person beziehen, aber nicht direkt zur Identifizierung der Person verwendet werden können. Entitäten, die unter diese Kategorie fallen, sollten durch Schemata dargestellt werden, die auf benutzerdefinierten Klassen basieren, und sind durch Schemabeziehungen mit Profilen und Ereignissen verknüpft. |
Ereignisentitäten | Ereignisentitäten stellen Konzepte dar, die sich auf Aktionen, die eine Kundin oder eine Kunde ausführen kann, Systemereignisse oder andere Konzepte, bei denen Sie vielleicht Änderungen im Laufe der Zeit verfolgen möchten, beziehen. Entitäten, die unter diese Kategorie fallen, sollten durch Schemata auf Basis der XDM ExperienceEvent-Klasse dargestellt werden. |
Die folgenden Abschnitte enthalten weitere Anleitungen zum Sortieren Ihrer Entitäten in die oben genannten Kategorien.
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.
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:
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:
Kunden-ID | Typ | Produkt-ID | Menge | Zeitstempel |
---|---|---|---|---|
1234567 | Hinzufügen | 275098 | 2 | 1. Oktober, 10:32 Uhr |
1234567 | Entfernen | 275098 | 1 | 1. Oktober, 10:33 Uhr |
1234567 | Hinzufügen | 486502 | 1 | 1. Oktober, 10:41 Uhr |
1234567 | Hinzufügen | 910482 | 5 | 3. Oktober, 14:15 Uhr |
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:
Zusätzlich zu Überlegungen zu Anwendungsfällen für die Segmentierung sollten Sie für diese Zielgruppen auch die Anwendungsfälle für die Aktivierung ü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.
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 aufgenommenen Ereignisse zu reduzieren, können Sie einen Aggregatwert numberOfPurchases
über einen Wochen- oder Monatszeitraum erstellen. Andere Aggregatfunktionen wie MIN und MAX können ebenfalls auf diese Situationen angewendet werden.
Experience Platform führt derzeit keine automatische Wertaggregation durch, obwohl dies für zukünftige Versionen geplant ist. Wenn Sie aggregierte Werte verwenden möchten, müssen Sie die Berechnungen extern durchführen, bevor Sie die Daten an Platform senden.
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 für „viele“ steht, 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.
Da es keinen universellen Ansatz für alle Anwendungsfälle gibt, ist es wichtig, die Vor- und Nachteile jeder Situation bei der Kategorisierung von Entitäten auf Grundlage der Kardinalität zu berücksichtigen. Weitere Informationen finden Sie im nächsten Abschnitt.
In der folgenden Tabelle sind einige allgemeine Entitätsbeziehungen und die daraus abgeleiteten Kategorien aufgeführt:
Beziehung | Kardinalität | Entitätskategorien |
---|---|---|
Kunden und Warenkorb-Kassengänge | Eins zu viele | Eine Kundin oder ein Kunde kann über viele Warenkorb-Kassengänge verfügen, bei denen es sich um Ereignisse handelt, die im Laufe der Zeit verfolgt werden können. Kundinnen und Kunden wären daher eine Profilentität, Warenkorb-Kassengänge hingegen eine Ereignisentität. |
Kunden und Treuekonten | Eins zu eins | Eine Kundin oder ein Kunde kann nur über ein Treuekonto verfügen und umgekehrt. Da es sich um eine Eins-zu-eins-Beziehung handelt, stellen sowohl Kunden als auch Treuekonten Profilentitäten dar. |
Kunden und Abonnements | Eins zu viele | Eine Kundin oder ein Kunde kann über viele Abonnements verfügen. Da es dem Unternehmen nur um die aktuellen Abonnements einer Kundin oder eines Kunden geht, handelt es sich bei den Kunden um eine Profilentität, bei den Abonnements hingegen um eine Lookup-Entität. |
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:
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
Nachteile
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
Nachteile
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:
Während Ereignisentitäten fast immer durch separate Schemata dargestellt werden, können Entitäten in Profil- oder Lookup-Kategorien je nach Kardinalität in einem einzelnen XDM-Schema kombiniert werden.
Da beispielsweise die Entität „Kunden“ eine Eins-zu-eins-Beziehung zur Entität „Treuekonten“ hat, könnte das Schema für die Entität „Kunden“ auch ein 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.
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 Schemas 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.
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 als Identitäten markierte Felder enthalten kann, muss eine einzige primäre Identität definiert werden, damit das Schema zur Verwendung in Real-Time Customer Profile aktiviert wird. 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 mögliche 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.
Experience Platform bietet mehrere vordefinierte XDM-Schemafeldgruppen zur Erfassung von Daten, die sich auf die folgenden Adobe-Anwendungen beziehen:
Beispielsweise ermöglicht Ihnen die Feldergruppe der Adobe Analytics ExperienceEvent-Vorlage das Zuordnen Analytics-spezifischer Felder zu Ihren XDM-Schemata. Je nach den Adobe-Anwendungen, mit denen Sie arbeiten, sollten Sie diese von Adobe bereitgestellten Feldergruppen in Ihren Schemas 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 einer Kundin oder einem Kunden bereitgestellt wird, lautet die primäre Identität stattdessen „AAID“.
Bei Verwendung von Feldergruppen für Adobe-Anwendungen sollten keine anderen Felder als primäre Identität markiert werden. Wenn es zusätzliche als Identitäten zu markierende Eigenschaften gibt, müssen diese Felder stattdessen als sekundäre Identitäten zugewiesen werden.
In diesem Dokument wurden die allgemeinen Richtlinien und Best Practices zum Entwerfen Ihres Datenmodells für Experience Platform behandelt. Zur Zusammenfassung:
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.