Konfiguration des Partnerschemas
Schemata dienen in Experience Platform zur konsistenten und wiederverwendbaren Beschreibung der Struktur von Daten. Wenn Daten in Platform aufgenommen werden, werden sie nach einem XDM-Schema strukturiert. Weitere Informationen zum Schemaaufbaumodell, einschließlich Planungsgrundsätzen und Best Practices, finden Sie in den Grundlagen des Schemaaufbaus.
Beim Erstellen eines Ziels mit Destination SDK können Sie Ihr eigenes Partnerschema definieren, das von Ihrer Zielplattform verwendet werden soll. Dadurch können Benutzerinnen und Benutzer Profilattribute von Platform bestimmten Feldern zuordnen, die von Ihrer Zielplattform erkannt werden, und zwar alles in der Platform-Benutzeroberfläche.
Beim Konfigurieren des Partnerschemas für Ihr Ziel können Sie die von Ihrer Zielplattform unterstützte Feldzuordnung anpassen, z. B.:
- Benutzerinnen und Benutzern erlauben, ein XDM-Attribut
phoneNumber
einem Attributphone
zuzuordnen, das von Ihrer Zielplattform unterstützt wird. - Dynamische Partnerschemata erstellen, die von Experience Platform dynamisch aufgerufen werden können, um eine Liste aller unterstützten Attribute in Ihrem Ziel abzurufen.
- Erforderliche Feldzuordnungen definieren, die für Ihre Zielplattform erforderlich sind.
Informationen dazu, wo diese Komponente in eine mit Destination SDK erstellte Integration passt, finden Sie im Diagramm in der Dokumentation zu Konfigurationsoptionen oder im Handbuch dazu, wie Sie mit der Destination SDK ein dateibasiertes Ziel konfigurieren.
Die Schemaeinstellungen können über den Endpunkt /authoring/destinations
konfiguriert werden. Detaillierte Beispiele für API-Aufrufe, in denen Sie die auf dieser Seite angezeigten Komponenten konfigurieren können, finden Sie auf den folgenden API-Referenzseiten.
In diesem Artikel werden alle unterstützten Schemakonfigurationsoptionen beschrieben, die Sie für Ihr Ziel verwenden können, und es wird gezeigt, was Kundinnen und Kunden in der Platform-Benutzeroberfläche sehen werden…
Unterstützte Integrationstypen supported-integration-types
Die nachstehende Tabelle beschreibt ausführlich, welche Integrationstypen die auf dieser Seite beschriebenen Funktionen unterstützen.
Unterstützte Schemakonfiguration supported-schema-types
Destination SDK unterstützt mehrere Schemakonfigurationen:
- Statische Schemata werden durch das Array
profileFields
im AbschnittschemaConfig
definiert. In einem statischen Schema definieren Sie jedes Zielattribut, das in der Experience Platform-Benutzeroberfläche angezeigt werden sollte, im ArrayprofileFields
. Wenn Sie Ihr Schema aktualisieren müssen, müssen Sie die Zielkonfiguration aktualisieren. - Dynamische Schemata verwenden einen zusätzlichen Typ von Ziel-Server, den sogenannten dynamischen Schema-Server, um basierend auf Ihrer eigenen API dynamisch die unterstützten Zielattribute abzurufen und Schemata zu genieren. Dynamische Schemata verwenden nicht das Array
profileFields
. Wenn Sie Ihr Schema aktualisieren müssen, müssen Sie die Zielkonfiguration aktualisieren. Stattdessen ruft der dynamische Schema-Server das aktualisierte Schema von Ihrer API ab. - Innerhalb der Schemakonfiguration haben Sie die Möglichkeit, erforderliche (oder vordefinierte) Zuordnungen hinzuzufügen. Hierbei handelt es sich um Zuordnungen, die Benutzerinnen und Benutzer in der Platform-Benutzeroberfläche anzeigen können. Sie können sie jedoch beim Einrichten einer Verbindung zu Ihrem Ziel nicht ändern. Beispielsweise können Sie erzwingen, dass das Feld für die E-Mail-Adresse immer an das Ziel gesendet wird.
Der Abschnitt schemaConfig
verwendet mehrere Konfigurationsparameter, je nach dem benötigten Schematyp, wie in den folgenden Abschnitten dargestellt.
Erstellen eines statischen Schemas attributes-schema
Um ein statisches Schema mit Profilattributen zu erstellen, definieren Sie die Zielattribute im Array profileFields
wie unten dargestellt.
"schemaConfig":{
"profileFields":[
{
"name":"phoneNo",
"title":"phoneNo",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the mobilePhone.number value in Experience Platform could be phoneNo on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
},
{
"name":"firstName",
"title":"firstName",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the person.name.firstName value in Experience Platform could be firstName on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
},
{
"name":"lastName",
"title":"lastName",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the person.name.lastName value in Experience Platform could be phoneNo on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
}
],
"useCustomerSchemaForAttributeMapping":false,
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true,
"segmentNamespaceAllowList": ["someNamespace"],
"segmentNamespaceDenyList": ["someOtherNamespace"]
}
profileFields
profileFields
können Sie den Parameter useCustomerSchemaForAttributeMapping
ganz weglassen.useCustomerSchemaForAttributeMapping
Aktiviert oder deaktiviert die Zuordnung von Attributen aus dem Kundenschema zu den Attributen, die Sie im Array profileFields
definieren.
- Wenn auf
true
festgelegt, sehen Benutzerinnen und Benutzer nur die Quellspalte im Zuordnungsfeld.profileFields
sind in diesem Fall nicht anwendbar. - Wenn auf
false
festgelegt, können Benutzerinnen und Benutzer Quellattribute aus ihrem Schema den Attributen zuordnen, die Sie in derprofileFields
Array.
Der Standardwert lautet false
.
profileRequired
true
, wenn Benutzerinnen und Benutzer in der Lage sein sollen, Profilattribute von Experience Platform benutzerdefinierten Attributen auf Ihrer Zielplattform zuzuordnen.segmentRequired
true
festgelegt werden.identityRequired
true
fest, wenn Benutzerinnen und Benutzer in der Lage sein sollen, Identitätstypen von Experience Platform den Attributen zuzuordnen, die Sie im Array profileFields
definiert haben.segmentNamespaceAllowList
segmentNamespaceDenyList
verwendet werden.Beispiel:
"segmentNamespaceAllowList": ["AudienceManager"]
ermöglicht es Benutzenden, nur Zielgruppen aus dem AudienceManager
-Namespace an dieses Ziel zuzuordnen.Damit Benutzende alle Zielgruppen in das Ziel exportieren können, müssen diese Parameter ignoriert werden.
Wenn
segmentNamespaceAllowList
und segmentNamespaceDenyList
in der Konfiguration fehlen, können Benutzende nur Zielgruppen exportieren, die aus dem Segmentierungs-Service stammen.segmentNamespaceDenyList
segmentNamespaceAllowed
verwendet werden.Beispiel:
"segmentNamespaceDenyList": ["AudienceManager"]
blockiert Benutzende bei der Zuordnung von Zielgruppen aus dem AudienceManager
-Namespace an dieses Ziel.Damit Benutzende alle Zielgruppen in das Ziel exportieren können, müssen diese Parameter ignoriert werden.
Wenn sowohl
segmentNamespaceAllowed
als auch segmentNamespaceDenyList
in der Konfiguration fehlen, können Benutzende nur Zielgruppen exportieren, die aus dem Segmentierungs-Service stammen.Um den Export aller Zielgruppen unabhängig von ihrer Herkunft zu ermöglichen, muss
"segmentNamespaceDenyList":[]
festgelegt werden.Das daraus resultierende Benutzeroberflächenerlebnis wird in den unten stehenden Bildern gezeigt.
Wenn Benutzerinnen und Benutzer die Zielgruppenzuordnung auswählen, können sie die im Array profileFields
definierten Felder sehen.
Nach Auswahl der Attribute werden sie in der Spalte mit den Zielfeldern angezeigt.
Erstellen eines dynamischen Schemas dynamic-schema-configuration
Destination SDK unterstützt die Erstellung von dynamischen Partnerschemata. Im Gegensatz zu statischen Schemata verwendet ein dynamisches Schema kein Array profileFields
. Stattdessen verwenden dynamische Schemata einen dynamischen Schema-Server, der eine Verbindung zu Ihrer eigenen API herstellt, von der aus die Schemakonfiguration abgerufen wird.
In einer dynamischen Schemakonfiguration wird das Array profileFields
durch den Abschnitt dynamicSchemaConfig
ersetzt, wie unten dargestellt.
"schemaConfig":{
"dynamicSchemaConfig":{
"dynamicEnum": {
"authenticationRule":"CUSTOMER_AUTHENTICATION",
"destinationServerId":"DYNAMIC_SCHEMA_SERVER_ID",
"value": "Schema Name",
"responseFormat": "SCHEMA"
}
},
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true
}
dynamicEnum.authenticationRule
Gibt an, wie Platform-Kundinnen und -Kunden eine Verbindung zu Ihrem Ziel herstellen. Akzeptierte Werte sind CUSTOMER_AUTHENTICATION
, PLATFORM_AUTHENTICATION
, NONE
.
- Verwenden Sie die
CUSTOMER_AUTHENTICATION
, wenn sich Platform-Kundinnen und -Kunden über eine der hier beschriebenen Authentifizierungsmethoden bei Ihrem System anmelden. - Verwenden Sie
PLATFORM_AUTHENTICATION
, wenn ein globales Authentifizierungssystem zwischen Adobe und Ihrem Ziel existiert und der Platform-Kunde keine Authentifizierungsdaten bereitstellen muss, um eine Verbindung zu Ihrem Ziel herzustellen. In diesem Fall müssen Sie ein Anmeldeinformationen-Objektmithilfe der Anmeldeinformationen-API erstellen. - Verwenden Sie
NONE
, wenn keine Authentifizierung erforderlich ist, um Daten an Ihre Zielplattform zu senden.
dynamicEnum.destinationServerId
instanceId
des dynamischen Schema-Servers. Dieser Ziel-Server enthält den API-Endpunkt, den Experience Platform aufruft, um das dynamische Schema abzurufen.dynamicEnum.value
dynamicEnum.responseFormat
SCHEMA
, wenn ein dynamisches Schema definiert wird.profileRequired
true
, wenn Benutzerinnen und Benutzer in der Lage sein sollen, Profilattribute von Experience Platform benutzerdefinierten Attributen auf Ihrer Zielplattform zuzuordnen.segmentRequired
true
festgelegt werden.identityRequired
true
fest, wenn Benutzerinnen und Benutzer in der Lage sein sollen, Identitätstypen von Experience Platform den Attributen zuzuordnen, die Sie im Array profileFields
definiert haben.Erforderliche Zuordnungen required-mappings
Innerhalb der Schemakonfiguration haben Sie neben Ihrem statischen oder dynamischen Schema die Möglichkeit, erforderliche (oder vordefinierte) Zuordnungen hinzuzufügen. Hierbei handelt es sich um Zuordnungen, die Benutzerinnen und Benutzer in der Platform-Benutzeroberfläche anzeigen können. Sie können sie jedoch beim Einrichten einer Verbindung zu Ihrem Ziel nicht ändern.
Beispielsweise können Sie erzwingen, dass das Feld für die E-Mail-Adresse immer an das Ziel gesendet wird.
- Sie können ein erforderliches Quellfeld und ein erforderliches Zielfeld konfigurieren. In diesem Fall können Benutzerinnen und Benutzer keines der beiden Felder bearbeiten oder auswählen und nur die Auswahl anzeigen.
- Sie können auch nur ein erforderliches Zielfeld konfigurieren. In diesem Fall können Benutzerinnen und Benutzer ein Quellfeld auswählen, das dem Ziel zugeordnet werden soll.
Nachfolgend finden Sie zwei Beispiele für eine Schemakonfiguration mit erforderlichen Zuordnungen und dafür, wie diese im Zuordnungsschritt des Workflows „Daten für Batch-Ziele aktivieren“ aussehen.
Das folgende Beispiel zeigt die erforderlichen Quell- und Zielzuordnungen. Wenn sowohl Quell- als auch Zielfelder als erforderliche Zuordnungen angegeben sind, können Benutzerinnen und Benutzer keines der beiden Felder auswählen oder bearbeiten und nur die vordefinierte Auswahl anzeigen.
code language-json |
---|
|
table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
---|---|---|---|
Parameter | Typ | Erforderlich/Optional | Beschreibung |
requiredMappingsOnly |
Boolesch | Optional | Wenn dies auf „true“ festgelegt ist, können Benutzerinnen und Benutzer keine anderen Attribute und Identitäten im Aktivierungsfluss zuordnen, abgesehen von den erforderlichen Zuordnungen, die Sie im Array requiredMappings definieren. |
requiredMappings.sourceType |
Zeichenfolge | Erforderlich |
Gibt den Typ des Felds
|
requiredMappings.source |
Zeichenfolge | Erforderlich |
Gibt den Wert des Quellfelds an. Unterstützte Werttypen:
|
requiredMappings.destination |
Zeichenfolge | Erforderlich | Gibt den Wert des Zielfelds an. Wenn sowohl Quell- als auch Zielfelder als erforderliche Zuordnungen angegeben sind, können Benutzerinnen und Benutzer keines der beiden Felder auswählen oder bearbeiten und nur die Auswahl anzeigen. |
Daher werden die Abschnitte Quellfeld und Zielfeld in der Platform-Benutzeroberfläche ausgegraut.
Das folgende Beispiel zeigt eine erforderliche Zielzuordnung. Wenn nur das Zielfeld als erforderlich angegeben wird, können Benutzerinnen und Benutzer auswählen, welches Quellfeld ihm zugeordnet werden soll.
code language-json |
---|
|
table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
---|---|---|---|
Parameter | Typ | Erforderlich/Optional | Beschreibung |
requiredMappingsOnly |
Boolesch | Optional | Wenn dies auf „true“ festgelegt ist, können Benutzerinnen und Benutzer keine anderen Attribute und Identitäten im Aktivierungsfluss zuordnen, abgesehen von den erforderlichen Zuordnungen, die Sie im Array requiredMappings definieren. |
requiredMappings.destination |
Zeichenfolge | Erforderlich | Gibt den Wert des Zielfelds an. Wenn nur das Zielfeld angegeben ist, können Benutzerinnen und Benutzer ein Quellfeld auswählen, das dem Ziel zugeordnet werden soll. |
mandatoryRequired |
Boolesch | Optional | Gibt an, ob die Zuordnung als obligatorisches Attribut markiert werden soll. |
primaryKeyRequired |
Boolesch | Optional | Gibt an, ob die Zuordnung als Deduplizierungsschlüssel markiert werden soll. |
Daher wird das Zielfeld in der Platform-Benutzeroberfläche ausgegraut, während der Abschnitt Quellfeld aktiv ist und Benutzende damit interagieren können. Die Optionen Obligatorischer Schlüssel und Deduplizierungsschlüssel sind aktiviert und können von Benutzenden geändert werden.
Konfigurieren der Unterstützung für externe Zielgruppen external-audiences
Um Ihr Ziel so zu konfigurieren, dass die Aktivierung von extern generierten Zielgruppen unterstützt wird, fügen Sie das unten stehende Codefragment in den Abschnitt schemaConfig
ein.
"schemaConfig": {
"segmentNamespaceDenyList": [],
...
}
Weitere Informationen zur Funktion segmentNamespaceDenyList
finden Sie in den Eigenschaftsbeschreibungen in der weiter oben stehenden Tabelle 1} auf dieser Seite.
Nächste Schritte next-steps
Nach dem Lesen dieses Artikels sollten Sie besser verstehen, welche Schematypen von Destination SDK unterstützt werden und wie Sie Ihr Schema konfigurieren können.
Weitere Informationen zu den anderen Zielkomponenten finden Sie in den folgenden Artikeln:
- Kundenauthentifizierung
- OAuth2-Autorisierung
- Benutzeroberflächenattribute
- Benutzerdefinierte Datenfelder
- Konfiguration von Identity-Namespaces
- Unterstützte Zuordnungskonfigurationen
- Zielbereitstellung
- Konfiguration von Zielgruppen-Metadaten
- Aggregationsrichtlinie
- Batch-Konfiguration
- Historische Profilqualifikationen