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 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.

Erste Schritte

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.

Zusammenfassung der Best Practices

Der empfohlene Ansatz zum Entwerfen Ihres Datenmodells für die Verwendung in Experience Platform kann wie folgt zusammengefasst werden:

1. Machen Sie sich mit den geschäftlichen Anwendungsfällen für Ihre Daten vertraut.
2. Identifizieren Sie die primären Datenquellen, die für diese Anwendungsfälle in Platform integriert werden sollten.
3. 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.
4. Erstellen Sie ein allgemeines Entitätsbeziehungsdiagramm (Entity Relationship Diagram, ERD) für die identifizierten Datenquellen.
5. 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 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.

Erstellen eines allgemeinen ERD

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.

Sortieren von Entitäten in Profil-, Lookup- und Ereigniskategorien

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

Die folgenden Abschnitte enthalten weitere Anleitungen zum Sortieren Ihrer Entitäten in die oben genannten Kategorien.

Veränderliche und unveränderliche Daten

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

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

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

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

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.

Aggregierte Werte

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.

Kardinalität

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.

In der folgenden Tabelle sind einige allgemeine Entitätsbeziehungen und die daraus abgeleiteten Kategorien aufgeführt:

Vor- und Nachteile verschiedener Entitätsklassen

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:

1. Verwenden von Profilattributen
2. Verwenden von Ereignisentitäten

Ansatz 1: Verwenden von Profilattributen

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 eine Kundin oder 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, ist es eine Herausforderung, das neueste aktualisierte Array über alle Kanäle hinweg zu synchronisieren.

Ansatz 2: Verwenden von Ereignisentitäten

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 Abonnementliste 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 eine zusätzliche Logik, um das letzte Abonnementereignis für eine Kundin bzw. einen Kunden hervorzuheben, um den Status zu überprüfen.
• 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 Schemas basierend auf kategorisierten Entitäten

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.

Die folgenden Abschnitte enthalten allgemeine Anleitungen zum Erstellen von Schemata basierend auf Ihrem ERD.

Anwendung eines iterativen Modellierungsansatzes

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.

Identitätsfelder

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.

Schemafeldgruppen für Adobe-Anwendungen

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

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“.

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.

Ressourcen für Business.Adobe.com