Bewährte Verfahren für die Datenmodellierung

Experience Data Model (XDM) ist der Kernrahmen, der Kundenerlebnisdaten standardisiert, indem gemeinsame Strukturen und Definitionen für nachgelagerte Adobe Experience Platform-Dienste bereitgestellt werden. Durch die Einhaltung von XDM-Standards können alle Kundenerlebnisdaten in eine gemeinsame Darstellung integriert werden, die Ihnen wertvolle Einblicke in Kundenaktionen ermöglicht, Audiencen durch Kundensegmente definiert und Kundenattribute zu Personalisierungszwecken ausdrückt.

Da XDM sehr vielseitig und von Design aus anpassbar ist, ist es daher wichtig, beim Entwerfen Ihrer Schema die Best Practices für die Datenmodellierung zu befolgen. In diesem Dokument werden die wichtigsten Entscheidungen und Überlegungen behandelt, die Sie bei der Zuordnung Ihrer Kundenerlebnisdaten zu XDM treffen müssen.

Erste Schritte

Bevor Sie dieses Handbuch lesen, lesen Sie sich bitte die XDM Systemübersicht durch, um eine Einführung in XDM und dessen Rolle in der Experience Platform zu erhalten.

Darüber hinaus konzentriert sich dieser Leitfaden ausschließlich auf wichtige Aspekte in Zusammenhang mit dem Schema-Design. Es wird daher dringend empfohlen, die Grundlagen der Schema-Komposition für detaillierte Erläuterungen der einzelnen Schema-Elemente, die in diesem Handbuch erwähnt werden, heranzuziehen.

Zusammenfassung der Best Practices

Der empfohlene Ansatz zum Entwerfen Ihres Datenmodells für die Verwendung in der Experience Platform lässt sich wie folgt zusammenfassen:

1. Machen Sie sich mit den geschäftlichen Nutzungsszenarien für Ihre Daten vertraut.
2. Identifizieren Sie die primären Datenquellen, die in Platform eingebracht werden sollten, um diese Anwendungsfälle zu beheben.
3. Finden Sie alle sekundären Datenquellen heraus, die ebenfalls von Interesse sein könnten. Wenn zum Beispiel derzeit nur eine Geschäftseinheit in Ihrem Unternehmen daran interessiert ist, ihre Daten an Platform zu übertragen, könnte eine ähnliche Geschäftseinheit auch daran interessiert sein, ähnliche Daten in Zukunft zu portieren. Die Betrachtung dieser sekundären Quellen hilft, das Datenmodell in Ihrer gesamten Organisation zu standardisieren.
4. Erstellen Sie ein hochrangiges Entitätsbeziehungsdiagramm (ERD) für die identifizierten Datenquellen.
5. Konvertieren Sie die ERD auf hoher Ebene in eine Platform-zentrierte ERD (einschließlich Profilen, Experience Ereignisses und Lookup-Entitäten).

Die Schritte zur Ermittlung der für die Durchführung Ihrer geschäftlichen Nutzungsszenarien erforderlichen Datenquellen sind von Unternehmen und Organisation zu Organisation unterschiedlich. Während sich die restlichen Abschnitte in diesem Dokument auf die letzten Schritte der Organisation und des Aufbaus einer ERD nach der Identifizierung der Datenquellen konzentrieren, können die Erläuterungen der verschiedenen Diagrammkomponenten Ihre Entscheidungen darüber informieren, welche Ihrer Datenquellen nach Platform migriert werden sollen.

Erstellen eines EFD auf hoher Ebene

Nachdem Sie die Datenquellen ermittelt haben, die Sie in Platform einbinden möchten, erstellen Sie eine ERD auf hoher Ebene, die Ihnen bei der Zuordnung Ihrer Daten zu XDM-Schemas helfen soll.

Das folgende Beispiel stellt eine vereinfachte ERD für eine Firma dar, die Daten in Platform einbringen möchte. Das Diagramm zeigt die wesentlichen Entitäten an, die in XDM-Klassen, darunter Kundenkonten, Hotels, Adressen und mehrere gängige E-Commerce-Ereignis, sortiert werden sollten.

Sortieren von Entitäten in Profil-, Lookup- und Ereignis-Kategorien

Nachdem Sie eine ERD erstellt haben, um die wesentlichen Entitäten zu identifizieren, die Sie in Platform einbinden möchten, müssen diese Entitäten in Profil-, Lookup- und Ereignis-Kategorien sortiert werden:

Überlegungen zur Entitätssortierung

Die folgenden Abschnitte enthalten weitere Anleitungen, wie Sie Ihre Entitäten in die oben genannten Kategorien sortieren können.

Kundenattribute

Wenn eine Entität Attribute enthält, die sich auf einen einzelnen Kunden beziehen, ist dies höchstwahrscheinlich eine Profil-Entität. Beispiele für Kundenattribute:

• Persönliche Angaben wie Name, Geburtsdatum, Geschlecht und Konto-ID(s).
• Standortinformationen wie Adressen und GPS-Informationen.
• Kontaktinformationen wie Telefonnummern und E-Mail-Adressen.

Verfolgen von Daten über einen bestimmten Zeitraum

Wenn Sie analysieren möchten, wie sich bestimmte Attribute innerhalb einer Entität im Laufe der Zeit ändern, ist dies höchstwahrscheinlich eine Ereignis-Entität. So können zum Beispiel Produktelemente zu einem Einkaufswagen als Add-to-cart-Ereignis in Platform nachverfolgt werden:

Anwendungsfälle für die Segmentierung

Bei der Kategorisierung Ihrer Entitäten ist es wichtig, über die Audiencen nachzudenken, die Sie erstellen möchten, um Ihre speziellen Geschäftszwecke zu bearbeiten.

Eine Firma möchte beispielsweise alle "Gold"- oder "Platin"-Mitglieder ihres Loyalitätsjahrs kennen, die im letzten Programm mehr als fünf Einkäufe getätigt haben. Auf der Grundlage dieser Segmentlogik können folgende Schlussfolgerungen zur Vertretung relevanter Stellen gezogen werden:

• "Gold"und "Platinum"stellen den Treuestatus eines einzelnen Kunden dar. Da die Segmentlogik nur den aktuellen Kundenloyalitätsstatus betrifft, können diese Daten als Teil eines Profil-Schemas modelliert werden. Wenn Sie Änderungen des Treuestatus im Laufe der Zeit verfolgen möchten, können Sie auch ein zusätzliches Ereignis-Schema für Änderungen des Treuestatus erstellen.
• Einkäufe sind Ereignis, die zu einem bestimmten Zeitpunkt auftreten, und die Segmentlogik bezieht sich auf Ereignis innerhalb eines bestimmten Zeitraums. Diese Daten sollten daher als Ereignis-Schema modelliert werden.

Anwendungsfälle der Aktivierung

Zusätzlich zu Überlegungen zu den Anwendungsfällen für die Segmentierung sollten Sie auch die Anwendungsfälle für die Aktivierung dieser Segmente überprüfen, um weitere relevante Attribute zu identifizieren.

Eine Firma hat beispielsweise ein Audiencen-Segment basierend auf der Regel country = US erstellt. Beim Aktivieren dieses Segments in bestimmten nachgelagerten Zielgruppen möchte die Firma dann alle exportierten Profil auf Grundlage des Heimatstatus filtern. Daher sollte ein state-Attribut auch in der entsprechenden Profil-Entität erfasst werden.

Aggregierte Werte

Je nach Anwendungsfall und Granularität Ihrer Daten sollten Sie entscheiden, ob bestimmte Werte voraggregiert werden müssen, bevor sie in eine Profil- oder Ereignis-Entität aufgenommen werden.

Eine Firma möchte beispielsweise ein Segment basierend auf der Anzahl der Einkaufswagen erstellen. Sie können diese Daten mit der niedrigsten Granularität einbeziehen, indem Sie jedes Ereignis mit Zeitstempel als eigene Entität einbeziehen. Dies kann jedoch manchmal die Anzahl der aufgezeichneten Ereignis exponentiell erhöhen. Um die Anzahl der erfassten Ereignis zu reduzieren, können Sie einen Aggregat-Wert numberOfPurchases über einen Wochen- oder Monatszeitraum erstellen. Andere Aggregat-Funktionen wie MIN und MAX können auch auf diese Situationen angewendet werden.

Kardinalität

Die in Ihrer ERD festgelegten Kardinalitäten können auch Hinweise zur Kategorisierung Ihrer Entitäten liefern. Wenn es eine Eins-zu-viele-Beziehung zwischen zwei Entitäten gibt, wird die Entität, die das "viele"darstellt, wahrscheinlich eine Entität des Ereignisses sein. Es gibt jedoch auch Fälle, in denen "viele"eine Reihe von Nachschlageentitäten sind, die als Array innerhalb einer Profil-Entitä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

Während im vorherigen Abschnitt einige allgemeine Richtlinien für die Entscheidung, wie Sie Ihre Entitäten kategorisieren, angegeben wurden, ist es wichtig zu verstehen, dass es oft Vor- und Nachteile für die Auswahl einer Entitäts-Kategorie gegenüber einer anderen geben kann. Die folgende Fallstudie soll zeigen, wie Sie in diesen Situationen Ihre Optionen in Betracht ziehen können.

Eine Firma verfolgt aktive Abonnement für ihre Kunden, bei denen ein Kunde viele Abonnement haben kann. Die Firma möchte auch Abonnement für Anwendungsfälle der Segmentierung einschließen, z. B. alle Benutzer mit aktiven Abonnements suchen.

In diesem Szenario verfügt die Firma über zwei potenzielle Optionen zur Darstellung der Abonnement eines Kunden in ihrem Datenmodell:

1. Profil-Attribute verwenden
2. Ereignis-Entitäten verwenden

Ansatz 1: Profil-Attribute verwenden

Der erste Ansatz besteht darin, ein Array von Abonnements als Attribute in die Kundenentität des Profils einzuschließen. Objekte in diesem Array enthalten Felder für category, status, planName, startDate und endDate.

Vorteile

• Die Segmentierung ist für den vorgesehenen Verwendungsfall möglich.
• Das Schema bewahrt nur die neuesten Kundendatensätze auf.

Nachteile

• Das gesamte Array muss bei jeder Änderung an einem Feld im Array neu angegeben werden.
• Wenn verschiedene Datenquellen oder Geschäftseinheiten Daten in das Array einspeisen, wird es schwierig, das neueste aktualisierte Array über alle Kanal hinweg zu synchronisieren.

Ansatz 2: Ereignis-Entitäten verwenden

Der zweite Ansatz wäre, Ereignis-Schema zur Darstellung von Abonnements zu verwenden. Hierzu müssen dieselben Abonnement-Felder wie beim ersten Ansatz verwendet werden, wobei eine Abonnement-ID, eine Kunden-ID und ein Zeitstempel zum Zeitpunkt des Ereignisses des Abonnements hinzugefügt werden müssen.

Vorteile

• Segmentierungsregeln können flexibler sein (z. B. bei der Suche nach allen Kunden, die ihre Abonnement in den letzten 30 Tagen geändert haben).
• Wenn sich der Status des Abonnements eines Kunden ändert, müssen Sie kein langes, potenziell komplexes Array mehr innerhalb der Kundenattribute aktualisieren. Dies ist besonders dann nützlich, wenn die Liste des Abonnements des Kunden aus mehreren Quellen gleichzeitig geändert wird.

Nachteile

• Die Segmentierung wird für den ursprünglich vorgesehenen Anwendungsfall komplexer (d. h. die Identifizierung des Status der letzten Abonnement des Kunden). Das Segment benötigt nun zusätzliche Logik, um das Ereignis des letzten Abonnements für einen Kunden zu kennzeichnen, um dessen Status zu überprüfen.

Erstellen Sie Schema basierend auf Ihren kategorisierten Entitäten

Nachdem Sie Ihre Entitäten in Profil-, Lookup- und Ereignis-Kategorien sortiert haben, können Sie Ihren Beginn zur Konvertierung Ihres Datenmodells in XDM-Schema verwenden. Zu Demonstrationszwecken wurde das zuvor dargestellte Datenmodell im folgenden Diagramm in geeignete Kategorien sortiert:

Die Kategorie, unter der eine Entität sortiert wurde, sollte die XDM-Klasse bestimmen, auf der das Schema basiert. Zu wiederholen:

• Profil-Entitäten sollten die XDM Individual Profile-Klasse verwenden.
• Ereignis-Entitäten sollten die XDM ExperienceEvent-Klasse verwenden.
• Suchentitäten sollten benutzerdefinierte XDM-Klassen verwenden, die von Ihrem Unternehmen definiert wurden.

Die folgenden Abschnitte enthalten allgemeine Anleitungen zum Aufbau von Schemas auf Basis Ihrer ERD.

Anwenden eines iterativen Modellierungsansatzes

Die Regeln der Schema-Evolution schreiben vor, dass nur nicht-destruktive Änderungen an Schemas vorgenommen werden können, sobald sie implementiert wurden. Mit anderen Worten, wenn Sie einem Schema ein Feld hinzufügen und Daten für dieses Feld erfasst wurden, kann das Feld nicht mehr entfernt werden. Daher ist es unerlässlich, beim ersten Erstellen Ihrer Schema einen iterativen Modellierungsansatz zu wählen, beginnend mit einer vereinfachten Implementierung, die im Laufe der Zeit immer komplexer wird.

Wenn Sie sich nicht sicher sind, ob ein bestimmtes Feld in ein Schema einbezogen werden muss, sollten Sie es am besten auslassen. Wenn später festgestellt wird, dass das Feld erforderlich ist, kann es immer in der nächsten Iteration des Schemas hinzugefügt werden.

Identitätsfelder

In der Experience Platform werden als Identitäten markierte XDM-Felder verwendet, um Informationen über einzelne Kunden aus mehreren Datenquellen zusammenzuführen. 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 für die Verwendung in Real-time Customer Profile aktiviert werden kann. Detailliertere Informationen zum Verwendungsfall dieser Schemas finden Sie im Abschnitt Identitätsfelder in den Grundlagen der Feldzusammensetzung.

Beim Entwerfen Ihrer Schema 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 von Kunden, Telefonnummern, Konto-IDs und ECID.

Feldgruppen Adobe Application Schema

Experience Platform bietet mehrere vordefinierte XDM-Schema-Feldgruppen zum Erfassen von Daten zu den folgenden Adoben:

• Adobe Analytics
• Adobe Audience Manager
• Adobe Campaign
• Adobe Target

Beispielsweise können Sie mit der Feldgruppe Adobe Analytics ExperienceEvent Template Analytics-spezifische Felder Ihren XDM-Schemas zuordnen. Abhängig von den Adoben, mit denen Sie arbeiten, sollten Sie diese mit Adobe bereitgestellten Feldgruppen in Ihren Schemas verwenden.

Anwendungsfeldgruppen der Adobe weisen automatisch eine primäre Standardidentität zu, indem sie das Feld identityMap verwenden. Es handelt sich dabei um ein systemgeneriertes schreibgeschütztes Objekt, das Standardidentitätswerte für einen einzelnen Kunden zuordnet.

Bei Adobe Analytics ist die ECID die primäre Standardidentität. Wenn kein ECID-Wert von einem Kunden bereitgestellt wird, lautet die primäre Identität stattdessen standardmäßig AAID.

Nächste Schritte

In diesem Dokument wurden die allgemeinen Richtlinien und Best Practices für das Entwerfen Ihres Datenmodells zur Experience Platform behandelt. Zusammenfassung:

• Verwenden Sie einen Top-Down-Ansatz, indem Sie Ihre Datentabellen in Profil-, Lookup- und Ereignis-Kategorien sortieren, bevor Sie Ihre Schema erstellen.
• Es gibt oft mehrere Ansätze und Optionen, wenn es darum geht, Schema für unterschiedliche Zwecke zu gestalten.
• Ihr Datenmodell sollte Ihre geschäftlichen Anwendungsfälle wie Segmentierung oder Journey-Analyse unterstützen.
• Machen Sie Ihre Schemas so einfach wie möglich und fügen Sie nur dann neue Felder hinzu, wenn dies unbedingt erforderlich ist.

Sobald Sie bereit sind, finden Sie im Lernprogramm unter Erstellen eines Schemas in der Benutzeroberfläche schrittweise Anweisungen zum Erstellen eines Schemas, zum Zuweisen der entsprechenden Klasse für die Entität und zum Hinzufügen von Feldern zur Zuordnung Ihrer Daten.