Grundlagen der Schema-Komposition
Erstellt für:
- Entwickler
Erfahren Sie mehr über Experience-Datenmodell-Schemas (XDM) und die Bausteine, Prinzipien und Best Practices zum Erstellen von Schemas in Adobe Experience Platform. Allgemeine Informationen zu XDM und seiner Verwendung in Experience Platform finden Sie in der XDM-Systemübersicht.
Verstehen von Schemata
Ein Schema ist ein Regelsatz, der die Datenstruktur und das Datenformat darstellt und überprüft. Auf hoher Ebene bieten Schemata eine abstrakte Definition eines realen Objekts (z. B. einer Person) und legen dar, welche Daten in jeder Instanz dieses Objekts enthalten sein sollen (z. B. Vorname, Nachname, Geburtsdatum usw.).
Zusätzlich zur Beschreibung der Datenstruktur wenden Schemata Einschränkungen und Erwartungen an Daten an, damit diese bei ihren Bewegungen zwischen den Systemen validiert werden können. Diese Standarddefinitionen ermöglichen eine konsistente Interpretation der Daten, unabhängig von ihrer Herkunft, und machen eine anwendungsübergreifende Übersetzung überflüssig.
Experience Platform erhält diese semantische Normalisierung mithilfe von Schemata aufrecht. Schemata sind die Standardmethode zur Beschreibung von Daten in Experience Platform. Dadurch können alle Daten, die mit Schemata konform sind, innerhalb einer Organisation ohne Konflikte wiederverwendet oder sogar von mehreren Organisationen gemeinsam genutzt werden.
XDM-Schemata eignen sich ideal zum Speichern großer Mengen komplexer Daten in einem eigenständigen Format. Weitere Informationen dazu, wie XDM dies , finden Sie in den AbschnittenEingebettete Objekte und Big Data im Anhang zu diesem Dokument.
Schema-basierte Workflows in Experience Platform
Die Standardisierung ist ein Schlüsselkonzept der Experience Platform. Das von Adobe unterstützte XDM-System ist ein Versuch, Kundenerlebnisdaten zu standardisieren und Schemata für das Customer Experience Management zu definieren.
Die Infrastruktur XDM System, auf der Experience Platform basiert, vereinfacht schemabasierte Workflows und umfasst die Schema Registry, Schema Editor, Schemadateien und Dienstnutzungsmuster. Weitere Informationen finden Sie in der XDM-Systemübersicht.
Die Verwendung von Schemata in Experience Platform bietet mehrere wichtige Vorteile. Erstens ermöglichen Schemata eine bessere Data Governance und Datenminimierung, was besonders bei Datenschutzbestimmungen wichtig ist. Zweitens ermöglicht die Erstellung von Schemata mit den Standardkomponenten von Adobe vordefinierte Einblicke und die Verwendung von KI-/ML-Services mit minimalen Anpassungen. Schließlich bieten Schemata eine Infrastruktur für Einblicke in die gemeinsame Datennutzung und effiziente Orchestrierung.
Planen Ihres Schemas
Der erste Schritt beim Erstellen eines Schemas besteht darin, das Konzept oder das Objekt der realen Welt zu bestimmen, das Sie im Schema erfassen möchten. Sobald Sie das Konzept, das Sie zu beschreiben versuchen, identifiziert haben, beginnen Sie mit der Planung Ihres Schemas, indem Sie über Dinge wie den Datentyp, potenzielle Identitätsfelder und die zukünftige Entwicklung des Schemas nachdenken.
Datenverhalten in Experience Platform
Daten, die in Experience Platform verwendet werden sollen, sind in zwei Verhaltenstypen unterteilt:
- Aufzeichnen von Daten: Stellt Informationen zu den Attributen eines Subjekts bereit. Ein Subjekt könnte eine Organisation oder eine Einzelperson sein.
- Zeitreihendaten: Stellt eine Momentaufnahme des Systems zum Zeitpunkt bereit, zu dem eine Aktion entweder direkt oder indirekt von einem Datensatzsubjekt durchgeführt wurde.
Alle XDM-Schemata beschreiben Daten, die als Datensatz oder Zeitreihe kategorisiert werden können. Das Datenverhalten eines Schemas wird durch die Klasse des Schemas definiert, die einem Schema bei dessen Erstellung zugewiesen wird. XDM-Klassen werden nachstehend in diesem Dokument detailliert beschrieben.
Sowohl Schemata der Datensätze als auch der Zeitreihen enthalten eine Zuordnung der Identitäten (xdm:identityMap). Dieses Feld enthält die Identitätsdarstellung eines Subjekts, die aus den als „Identität“ markierten Feldern gezogen wird, wie im nächsten Abschnitt beschrieben.
Identität
Schemata definieren die Datenstruktur, die in Experience Platform aufgenommen werden. Diese Daten ermöglichen mehrere Services innerhalb der Plattform und tragen dazu bei, eine einheitliche Ansicht jedes Einzelnen zu erstellen. Überlegen Sie daher beim Entwerfen von Schemata sorgfältig, welche Felder als Identitäten markiert werden sollen. Diese steuern, wie Profile über Datensätze hinweg zugeordnet werden.
Um diesen Prozess zu unterstützen, können Schlüsselfelder in Ihren Schemata als Identitäten markiert werden. Bei der Datenaufnahme werden die Daten in diesen Feldern für diese Person in das Identitätsdiagramm eingefügt. Auf die Diagrammdaten können dann Real-Time Customer Profile und andere Experience Platform-Services zugreifen, um eine zusammengefügte Ansicht jedes einzelnen Kunden zu erhalten.
Zu den Feldern, die häufig als "Identität gekennzeichnet sind, gehören: E-Mail-Adresse, Telefonnummer, Experience Cloud ID (ECID), CRM-ID oder andere eindeutige ID-Felder. Erwägen Sie alle eindeutigen Kennungen, die für Ihr Unternehmen spezifisch sind, da sie auch gute ""- sein können.
Weitere Informationen dazu, wie Sie Ihren Kunden mit Identitätsinformationen digitale Erlebnisse bereitstellen können, finden Sie unter Identity Service - Übersicht. Tipps zur Verwendung von Identitäten beim Erstellen Schemas finden Sie im Dokument Best Practices für die Datenmodellierung.
Es gibt zwei Möglichkeiten, Identitätsdaten an Experience Platform zu senden:
- Hinzufügen von Identitätsdeskriptoren zu einzelnen Feldern, entweder über die Benutzeroberfläche des Schema-Editors oder mithilfe der Schema Registry-API
- Verwenden eines
identityMapFelds
identityMap
identityMap ist ein Feld vom Typ Zuordnung , das die verschiedenen Identitätswerte einer Person zusammen mit den zugehörigen Namespaces beschreibt. Dieses Feld kann verwendet werden, um Identitätsinformationen für Ihre Schemata bereitzustellen, anstatt Identitätswerte innerhalb der Struktur des Schemas selbst zu definieren.
Der Hauptnachteil der Verwendung von identityMap besteht darin, dass Identitätswerte verschachtelt sind und es schwieriger sein kann, mit ihnen in Tools zu arbeiten, die Identitätsfelder der obersten Ebene erwarten, z. B. Segment Builder oder einige Integrationen von Drittanbietern.
NOTEidentityMap verwendet, kann in einer Beziehung als Quellschema, aber nicht als Referenzschema verwendet werden. Dies liegt daran, dass alle Referenzschemata eine sichtbare Identität aufweisen müssen, die in einem Referenzfeld innerhalb des Quellschemas zugeordnet werden kann. Weitere Informationen zu den Anforderungen von Quell und Referenzschemas findenim Handbuch zur Benutzeroberfläche unter Beziehungen .Identitätszuordnungen können jedoch nützlich sein, wenn es eine variable Anzahl von Identitäten für ein Schema gibt oder Sie Daten aus Quellen einbringen, die Identitäten speichern (z. B. Airship oder Adobe Audience Manager). Darüber hinaus sind Identitätszuordnungen erforderlich, wenn Sie die Adobe Experience Platform Mobile SDK verwenden.
Ein Beispiel für eine einfache Identitätszuordnung würde wie folgt aussehen:
"identityMap": {
"email": [
{
"id": "jsmith@example.com",
"primary": true
}
],
"ECID": [
{
"id": "87098882279810196101440938110216748923",
"primary": false
},
{
"id": "55019962992006103186215643814973128178",
"primary": false
}
],
"CRMID": [
{
"id": "2e33192000007456-0365c00000000000",
"primary": false
}
]
}
Wie im obigen Beispiel gezeigt, stellt jeder Schlüssel im identityMap-Objekt einen Identity-Namespace dar. Der Wert für jeden Schlüssel ist ein Array von Objekten, das die Identitätswerte (id) für den jeweiligen Namespace darstellt. In der Identity Service finden Sie eine Liste der Standard-Identity-Namespaces die von Adobe-Programmen erkannt wird.
NOTEprimary) ist. Sie müssen nur primäre Identitäten für Schemata festlegen, die in Real-Time Customer Profile verwendet werden sollen. Weitere Informationen finden Sie im Abschnitt Vereinigungsschemata .Prinzipien der Schemaentwicklung
In dem Maße, wie sich die Art der digitalen Erfahrungen weiterentwickelt, müssen sich auch die Schemata, die zu ihrer Darstellung verwendet werden, weiterentwickeln. Ein gut entworfenes Schema ist daher in der Lage, sich bei Bedarf anzupassen und weiterzuentwickeln, ohne destruktive Änderungen an früheren Versionen des Schemas zu verursachen.
Da die Beibehaltung der Abwärtskompatibilität für die Schemaentwicklung von entscheidender Bedeutung ist, erzwingt Experience Platform ein rein additives Versionierungsprinzip. Dieses Prinzip stellt sicher, dass alle Änderungen am Schema nur zu zerstörungsfreien Aktualisierungen und Änderungen führen. Mit anderen Worten: brechende Änderungen werden nicht unterstützt.
NOTEIn der folgenden Tabelle ist aufgeführt, welche Änderungen beim Bearbeiten von Schemata, Feldergruppen und Datentypen unterstützt werden:
- Hinzufügen neuer Felder zur Ressource
- Optionales Festlegen eines erforderlichen Felds
- Einführung neuer Pflichtfelder*
- Anzeigename und Beschreibung der Ressource ändern
- Aktivieren des Schemas für die Profilteilnahme
- Entfernen zuvor definierter Felder
- Umbenennen oder Neudefinieren vorhandener Felder
- Entfernen oder Eingrenzen zuvor unterstützter Feldwerte
- Verschieben vorhandener Felder an eine andere Position im Baum
- Löschen des Schemas
- Deaktivieren des Schemas aus der Profilteilnahme
- Ändern des Felds für die primäre Identität in einem Schema, das für das Profil aktiviert ist und Daten aufgenommen hat
*Im folgenden Abschnitt finden Sie wichtige Überlegungen zum Festlegen neuer Pflichtfelder.
Erforderliche Felder
Einzelne Schemafelder können als erforderlich markiert) werden was bedeutet, dass alle aufgenommenen Datensätze Daten in diesen Feldern enthalten müssen, damit die Validierung erfolgreich ist. Wenn Sie beispielsweise das Feld für die primäre Identität eines Schemas nach Bedarf festlegen, kann sichergestellt werden, dass alle aufgenommenen Datensätze beim Echtzeit-Kundenprofil berücksichtigt werden. Ebenso wird durch die Festlegung eines Zeitstempelfelds nach Bedarf sichergestellt, dass alle Zeitreihenereignisse chronologisch beibehalten werden.
IMPORTANTnull oder leere Werte. Wenn in einem Datensatz oder Ereignis kein Wert für ein bestimmtes Feld vorhanden ist, sollte der Schlüssel für dieses Feld aus der Aufnahme-Payload ausgeschlossen werden.Festlegen von Feldern nach Bedarf nach der Aufnahme
Wenn ein Feld zur Aufnahme von Daten verwendet wurde und ursprünglich nicht wie erforderlich festgelegt wurde, kann dieses Feld für einige Datensätze einen Nullwert aufweisen. Wenn Sie dieses Feld nach der Aufnahme als erforderlich festlegen, müssen alle zukünftigen Datensätze einen Wert für dieses Feld enthalten, auch wenn historische Datensätze null sein können.
Beachten Sie beim Festlegen eines zuvor optionalen Felds nach Bedarf Folgendes:
- Wenn Sie historische Daten abfragen und die Ergebnisse in einen neuen Datensatz schreiben, schlagen einige Zeilen fehl, da sie Nullwerte für das erforderliche Feld enthalten.
- Wenn das Feld am Echtzeit-Kundenprofil beteiligt ist und Sie Daten exportieren, bevor Sie sie nach Bedarf festlegen, kann es für einige Profile null sein.
- Sie können die Schema Registry-API verwenden, um ein Änderungsprotokoll mit Zeitstempel für alle XDM-Ressourcen in Experience Platform anzuzeigen, einschließlich neuer erforderlicher Felder. Weitere Informationen finden Sie im Handbuch zum EndpunktAdministratorprotokoll“.
Schemata und Datenerfassung
Um Daten in die Experience Platform aufnehmen zu können, muss zunächst ein Datensatz erstellt werden. Datensätze sind die Bausteine für die Datenumwandlung und das Tracking für Catalog Service und stellen im Allgemeinen Tabellen oder Dateien dar, die aufgenommene Daten enthalten. Alle Datensätze basieren auf vorhandenen XDM-Schemata, die Einschränkungen dafür enthalten, was die aufgenommenen Daten enthalten und wie sie strukturiert sein sollten. Weitere Informationen hierzu finden Sie in der Übersicht über die Datenerfassung in Adobe Experience Platform.
Bausteine eines Schemas
Die Experience Platform verwendet einen Kompositionsansatz, bei dem Standardbausteine kombiniert werden, um Schemata zu erstellen. Dieser Ansatz fördert die Wiederverwendbarkeit vorhandener Komponenten und treibt die Standardisierung in der gesamten Branche voran, um Anbieterschemas und Komponenten in Experience Platform zu unterstützen.
Schemata werden nach folgender Formel zusammengestellt:
Klasse + Schemafeldgruppe* = XDM-Schema
↦ast;Ein Schema besteht aus einer Klasse und keiner oder mehreren Schemafeldgruppen. Dies bedeutet, dass Sie ein Datensatzschema erstellen können, ohne Feldergruppen zu verwenden.
Klasse
Das Erstellen eines Schemas beginnt mit dem Zuweisen einer Klasse. Klassen definieren die Verhaltensaspekte der Daten, die das Schema enthalten soll (Datensatz oder Zeitreihen). Darüber hinaus beschreiben Klassen die kleinste Anzahl gemeinsamer Eigenschaften, die alle Schemata, die auf dieser Klasse basieren, beinhalten müssen, und bieten eine Möglichkeit zum Zusammenführen mehrerer kompatibler Datensätze.
Die Klasse eines Schemas bestimmt, welche Feldergruppen für die Verwendung in diesem Schema geeignet sind. Weitere Informationen hierzu finden Sie im Abschnitt.
Adobe bietet mehrere standardmäßige XDM-Klassen („Kern„). Zwei dieser Klassen, XDM Individual Profile und XDM ExperienceEvent, sind für fast alle nachgelagerten Experience Platform-Prozesse erforderlich. Zusätzlich zu diesen Kernklassen können Sie auch eigene benutzerdefinierte Klassen erstellen, um spezifischere Anwendungsfälle für Ihre Organisation zu beschreiben. Benutzerdefinierte Klassen werden von einem Unternehmen definiert, wenn keine von Adobe definierten Kernklassen verfügbar sind, um einen eindeutigen Anwendungsfall zu beschreiben.
Der folgende Screenshot zeigt, wie Klassen in der Experience Platform-Benutzeroberfläche dargestellt werden. Da das angezeigte Beispielschema keine Feldergruppen enthält, werden alle angezeigten Felder von der Klasse des Schemas bereitgestellt (XDM Individual Profile).
Die aktuellste Liste der verfügbaren Standard-XDM-Klassen finden Sie im offiziellen XDM-Repository. Alternativ können Sie auch das Handbuch unter Erkunden von XDM-Komponenten“ lesen wenn Sie Ressourcen lieber in der Benutzeroberfläche anzeigen möchten.
Feldergruppe
Eine Feldergruppe ist eine wiederverwendbare Komponente, die ein oder mehrere Felder definiert, die bestimmte Funktionen wie persönliche Details, Hotelvoreinstellungen oder Adresse implementieren. Feldergruppen sind als Teil eines Schemas vorgesehen, das eine kompatible Klasse implementiert.
Feldergruppen definieren basierend auf dem Verhalten der Daten, die sie darstellen (Datensatz oder Zeitreihe), mit welcher Klasse oder welchen Klassen sie kompatibel sind. Das bedeutet, dass nicht alle Feldergruppen für die Verwendung mit allen Klassen verfügbar sind.
Experience Platform umfasst viele standardmäßige Adobe-Feldergruppen, ermöglicht es aber auch Anbietern, Feldergruppen für ihre Benutzenden und einzelnen Benutzenden, Feldergruppen für ihre eigenen spezifischen Konzepte zu definieren.
Um beispielsweise Details wie "Vorname und "Privatadresse für Ihr Schema "Mitglieder des Treueprogramms zu erfassen, können Sie Standardfeldgruppen verwenden, die diese allgemeinen Konzepte definieren. Konzepte, die spezifischer für Ihr Unternehmen sind (z. B. Details zu benutzerdefinierten Treueprogrammen oder Produktattributen) und möglicherweise nicht von Standardfeldgruppen abgedeckt werden. In diesem Fall müssen Sie Ihre eigene Feldergruppe definieren, um diese Informationen zu erfassen.
NOTEDenken Sie daran, dass Schemata aus „null oder mehr“ Feldergruppen bestehen. Dies bedeutet, dass Sie ein gültiges Schema erstellen können, ohne überhaupt Feldergruppen zu verwenden.
Der folgende Screenshot zeigt, wie Feldergruppen in der Experience Platform-Benutzeroberfläche dargestellt werden. Eine einzelne Feldergruppe (Demografische Details) wird in diesem Beispiel einem Schema hinzugefügt, das eine Gruppierung von Feldern zur Schemastruktur bereitstellt.
Die aktuellste Liste der verfügbaren Standard-XDM-Feldergruppen finden Sie im offiziellen XDM-Repository. Alternativ können Sie auch das Handbuch unter Erkunden von XDM-Komponenten“ lesen wenn Sie Ressourcen lieber in der Benutzeroberfläche anzeigen möchten.
NOTEDatentyp
Datentypen werden als Referenzfeldtypen in Klassen oder Schemata auf die gleiche Weise verwendet wie grundlegende literale Felder. Der Hauptunterschied besteht darin, dass Datentypen mehrere Unterfelder auf die gleiche Weise definieren können wie Feldergruppen. Der wesentliche Unterschied zwischen ihnen besteht darin, dass Datentypen überall in einem Schema enthalten sein können, indem sie als „Datentyp“ eines Felds hinzugefügt werden. Während Feldgruppen nur mit bestimmten Klassen kompatibel sind, können Datentypen in jeder übergeordneten Klasse oder Feldergruppe enthalten sein.
NOTEExperience Platform bietet eine Reihe allgemeiner Datentypen als Teil der Schema Registry, um die Verwendung von Standardmustern zur Beschreibung allgemeiner Datenstrukturen zu unterstützen. Dies wird in den Tutorials zur Schemaregistrierung ausführlicher erläutert und wird klarer, wenn Sie die Schritte zum Definieren von Datentypen durchlaufen.
Der folgende Screenshot zeigt, wie Datentypen in der Experience Platform-Benutzeroberfläche dargestellt werden. Eines der Felder, die von der Feldergruppe Demografische Details bereitgestellt werden, verwendet den Datentyp Objekt, wie durch den Text angegeben, der auf das Pipe-Zeichen (|) neben dem Feldnamen folgt. Dieser Datentyp bietet mehrere Unterfelder, die sich auf den Namen einer einzelnen Person beziehen - ein Konstrukt, das für andere Felder wiederverwendet werden kann, in denen der Name einer Person erfasst werden muss.
Die aktuellste Liste der verfügbaren Standard-XDM-Datentypen finden Sie im offiziellen XDM-Repository. Alternativ können Sie auch das Handbuch unter Erkunden von XDM-Komponenten“ lesen wenn Sie Ressourcen lieber in der Benutzeroberfläche anzeigen möchten.
NOTEFeld
Ein Feld ist der grundlegendste Baustein eines Schemas. Felder bieten Einschränkungen hinsichtlich des Datentyps, den sie enthalten können, indem sie einen bestimmten Datentyp definieren. Diese grundlegenden Datentypen definieren ein einzelnes Feld, während die Datentypen zuvor erwähnten es Ihnen ermöglichen, mehrere Unterfelder zu definieren und dieselbe Struktur mit mehreren Feldern in verschiedenen Schemata wiederzuverwenden. Zusätzlich zur Definition des „Datentyps“ eines Feldes als einen der in der Registrierung definierten Datentypen unterstützt die Experience Platform also grundlegende Skalartypen wie:
- Zeichenfolge
- Ganzzahl
- Double
- Boolesch
- Array
- Objekt
TIPDie gültigen Bereiche dieser Skalartypen können weiter auf bestimmte Muster, Formate, Minima/Maxima oder vordefinierte Werte eingeschränkt werden. Mithilfe dieser Einschränkungen kann eine breite Palette speziellerer Feldtypen dargestellt werden, darunter:
- Enum
- Lang
- Kurz
- Byte
- Datum
- Datum-Uhrzeit
- Karte
NOTEKompositionsbeispiel
Schemata werden mithilfe eines Kompositionsmodells erstellt und stellen das Format und die Struktur von Daten dar, die in Experience Platform aufgenommen werden sollen. Wie bereits erwähnt, bestehen diese Schemata aus einer Klasse und keiner oder mehreren Feldergruppen, die mit dieser Klasse kompatibel sind.
Ein Schema, das Käufe in einem Einzelhandelsgeschäft beschreibt, kann beispielsweise „StoreTransaktionen“ . Das Schema implementiert die XDM ExperienceEvent-Klasse in Kombination mit der standardmäßigen Commerce-Feldergruppe und einer benutzerdefinierten Feldergruppe Produktinfo.
Ein weiteres Schema, das den Website-Traffic verfolgt, wird möglicherweise als "" . Sie implementiert auch die XDM ExperienceEvent-Klasse, kombiniert aber dieses Mal die standardmäßige Web-Feldergruppe.
Das folgende Diagramm zeigt diese Schemata und die von den einzelnen Feldergruppen bereitgestellten Felder. Sie enthält außerdem zwei Schemata, die auf der XDM Individual Profile-Klasse basieren, einschließlich des Schemas Mitglieder des Treueprogramms, das zuvor in diesem Handbuch erwähnt wurde.
Union
Während Experience Platform es Ihnen ermöglicht, Schemata für bestimmte Anwendungsfälle zusammenzustellen, können Sie auch eine „Vereinigung“ von Schemata für einen bestimmten Klassentyp sehen. Das vorherige Diagramm zeigt zwei Schemas, die auf der XDM ExperienceEvent-Klasse basieren, und zwei Schemas, die auf XDM Individual Profile Klasse basieren. Die unten dargestellte Vereinigung aggregiert die Felder aller Schemata, die dieselbe Klasse aufweisen (XDM ExperienceEvent bzw. XDM Individual Profile).
Wenn Sie ein Schema für die Verwendung mit Real-Time Customer Profile aktivieren, wird es in die Vereinigung für diesen Klassentyp aufgenommen. Profile bietet zuverlässige, zentralisierte Profile von Kundenattributen und eine Darstellung jedes Ereignisses mit Zeitstempel, das ein Kunde über eines der in Experience Platform integrierten Systeme hatte. Profile verwendet die Vereinigungsansicht, um diese Daten darzustellen und eine ganzheitliche Ansicht jedes einzelnen Kunden bereitzustellen.
Weitere Informationen zum Arbeiten mit Profile finden Sie in der Übersicht über das Echtzeit-Kundenprofil.
Zuordnen von Datendateien zu XDM-Schemata
Alle Datendateien, die in Experience Platform aufgenommen werden, müssen der Struktur eines XDM-Schemas entsprechen. Weitere Informationen zum Formatieren von Datendateien mit XDM-Hierarchien (einschließlich Beispieldateien) finden Sie im Dokument zu Beispiel-ETL-Transformationen. Allgemeine Informationen zur Aufnahme von Datendateien in Experience Platform finden Sie unter Batch-Erfassung – Übersicht.
Schemata für externe Zielgruppen
Wenn Sie Zielgruppen aus externen Systemen in Experience Platform importieren möchten, müssen Sie die folgenden Komponenten verwenden, um sie in Ihren Schemata zu erfassen:
- Segmentdefinition Klasse: Verwenden Sie diese Standardklasse, um Schlüsselattribute einer externen Segmentdefinition zu erfassen.
- Details zur Segmentzugehörigkeit Feldergruppe: Fügen Sie diese Feldergruppe zu Ihrem Schema XDM Individual Profile hinzu, um Kundenprofile mit bestimmten Zielgruppen zu verknüpfen.
Nächste Schritte
Nachdem Sie nun die Grundlagen der Schemakomposition kennen, können Sie mit dem Erkunden und Erstellen von Schemas mit dem Schema Registry beginnen.
Die Struktur der beiden XDM-Kernklassen und ihrer häufig verwendeten kompatiblen Feldergruppen finden Sie in der folgenden Referenzdokumentation:
Die Schema Registry wird verwendet, um auf die Schema Library in Adobe Experience Platform zuzugreifen, und bietet eine Benutzeroberfläche und eine RESTful-API, über die alle verfügbaren Bibliotheksressourcen verfügbar sind. Die Schema Library enthält von Adobe definierte Branchenressourcen, von Experience Platform-Partnern definierte Anbieterressourcen sowie Klassen, Feldergruppen, Datentypen und Schemata, die von Mitgliedern Ihres Unternehmens erstellt wurden.
Um mit dem Erstellen von Schemas über die Benutzeroberfläche zu beginnen, folgen Sie dem Schema-Editor-Tutorial, um das Schema „Loyalty Members“ zu erstellen, das in diesem Dokument erwähnt wird.
Um mit der Verwendung der Schema Registry-API zu beginnen, lesen Sie zunächst das Entwicklerhandbuch zur Schema Registry-API. Nachdem Sie das Entwicklerhandbuch gelesen haben, führen Sie die Schritte aus, die im Tutorial zum Erstellen eines Schemas mit der Schema Registry-API beschrieben werden.
Anhang
Die folgenden Abschnitte enthalten zusätzliche Informationen zu den Prinzipien der Schemakomposition.
Relationale Tabellen versus eingebettete Objekte
Bei der Arbeit mit relationalen Datenbanken bestehen die Best Practices darin, Daten zu normalisieren oder eine Entität in diskrete Teile zu zerlegen, die dann in mehreren Tabellen angezeigt werden. Um die Daten als Ganzes zu lesen oder die Entität zu aktualisieren, müssen Lese- und Schreibvorgänge über viele einzelne Tabellen hinweg mithilfe von JOIN durchgeführt werden.
Durch die Verwendung eingebetteter Objekte können XDM-Schemata komplexe Daten direkt darstellen und in eigenständigen Dokumenten mit hierarchischer Struktur speichern. Einer der Hauptvorteile dieser Struktur besteht darin, dass Sie die Daten abfragen können, ohne die Entität durch teure Joins zu mehreren denormalisierten Tabellen rekonstruieren zu müssen. Es gibt keine harten Einschränkungen bezüglich der möglichen Anzahl von Ebenen Ihrer Schemahierarchie.
Schemata und Big Data
Moderne digitale Systeme generieren enorme Mengen von Verhaltenssignalen (Transaktionsdaten, Weblogs, Internet der Dinge, Anzeige usw.). Diese Big-Data-Daten bieten außergewöhnliche Möglichkeiten zur Optimierung von Erlebnissen, sind aber aufgrund der Größe und Vielfalt der Daten schwierig zu nutzen. Um Wert aus den Daten zu gewinnen, müssen ihre Struktur, ihr Format und ihre Definitionen standardisiert werden, damit sie konsistent und effizient verarbeitet werden können.
Schemata lösen dieses Problem, indem sie die Integration von Daten aus mehreren Quellen, die Standardisierung durch gemeinsame Strukturen und Definitionen und die lösungsübergreifende gemeinsame Nutzung ermöglichen. Auf diese Weise können nachfolgende Prozesse und Services alle Fragen beantworten, die in Bezug auf die Daten gestellt werden. Sie entfernt sich vom herkömmlichen Ansatz zur Datenmodellierung, bei dem alle Fragen, die im Zusammenhang mit den Daten gestellt werden müssen, im Voraus bekannt sind, und die Daten so modelliert werden, dass sie diesen Erwartungen entsprechen.
Objekte versus Freiformfelder
Beim Entwerfen Ihrer Schemata sind einige Schlüsselfaktoren zu berücksichtigen, wenn Sie Objekte anstelle von Freiformfeldern auswählen:
Objekte
Die Vor- und Nachteile der Verwendung von -Objekten über Freiformfeldern sind unten aufgeführt.
Vorteile:
- Objekte eignen sich am besten für die Erstellung einer logischen Gruppierung bestimmter Felder.
- Objekte organisieren das Schema strukturierter.
- Objekte helfen indirekt bei der Erstellung einer guten Menüstruktur in der Segment Builder-Benutzeroberfläche. Die gruppierten Felder innerhalb des Schemas werden direkt in der Ordnerstruktur angezeigt, die in der Benutzeroberfläche von Segment Builder bereitgestellt wird.
Nachteile:
- Die Felder werden verschachtelter.
- Bei Verwendung von Adobe Experience Platform Query Service müssen für die Abfragefelder, die in -Objekten verschachtelt sind, längere Referenzzeichenfolgen bereitgestellt werden.
Freiformfelder
Die Vor- und Nachteile der Verwendung von Freiformfeldern über Objekten sind unten aufgeführt.
Vorteile:
- Freiformfelder werden direkt unter dem Stammobjekt des Schemas (
_tenantId) erstellt, wodurch die Sichtbarkeit erhöht wird. - Referenzzeichenfolgen für Freiformfelder sind bei Verwendung des Abfrage-Service in der Regel kürzer.
Nachteile:
- Die Position von Freiformfeldern innerhalb des Schemas ist ad hoc, d. h. sie werden im Schema-Editor in alphabetischer Reihenfolge angezeigt. Dadurch können Schemata weniger strukturiert sein und ähnliche Freiformfelder können je nach ihrem Namen weit voneinander getrennt sein.