パートナースキーマ設定
Experience Platform では、スキーマを使用して、一貫性のある再利用可能な方法でデータの構造を記述します。Experience Platformに取り込まれたデータは、XDMスキーマに従って構造化されます。 デザインの原則やベストプラクティスなど、スキーマ構成モデルについて詳しくは、スキーマ構成の基本を参照してください。
Destination SDK で宛先を作成する場合、宛先プラットフォームによって使用される独自のパートナースキーマを定義できます。これにより、ユーザーはExperience Platformのプロファイル属性をすべてExperience Platform UI内で宛先プラットフォームで認識される特定のフィールドにマッピングできます。
宛先用にパートナースキーマを設定する場合、宛先プラットフォームでサポートされているフィールドマッピングを微調整できます。以下に例を示します。
- ユーザーは、
phoneNumberXDM 属性を宛先プラットフォームでサポートされているphone属性にマッピングできます。 - 宛先内のサポートされるすべての属性のリストを取得するために Experience Platform が動的に呼び出す、動的パートナースキーマを作成します。
- 宛先プラットフォームが必要とする必須のフィールドマッピングを定義します。
このコンポーネントが出力先 SDK で作成された統合のどこに当てはまるかを理解するには、 構成オプション ドキュメントの図を参照するか、出力先 SDK を 使用してファイルベースの宛先を構成する方法に関するガイドを参照してください。
/authoring/destinations エンドポイントを介してスキーマ設定を設定できます。このページに表示されるコンポーネントを設定できる、詳細な API 呼び出しの例については、以下の API リファレンスページを参照してください。
この記事では、宛先に使用できるサポートされているすべての スキーマ 構成オプションについて説明し、Experience Platform UIで顧客に表示される内容を示します。
サポートされる統合タイプ supported-integration-types
このページで説明される機能をサポートする統合のタイプについて詳しくは、以下の表を参照してください。
サポートされるスキーマ設定 supported-schema-types
Destination SDK は、以下の複数のスキーマ設定をサポートします。
- 静的スキーマは、
schemaConfigセクションのprofileFields配列を通じて定義されます。静的スキーマでは、profileFields配列で Experience Platform UI に表示される必要がある各ターゲット属性を定義します。スキーマを更新する必要がある場合、宛先設定を更新する必要があります。 - 動的スキーマは、動的スキーマサーバーと呼ばれる、追加の宛先サーバータイプを使用して、サポートされているターゲット属性を動的に取得し、独自の API に基づいて動的にスキーマを生成します。動的スキーマは、
profileFields配列を使用しません。スキーマを更新する必要がある場合、宛先設定を更新する必要はありません。代わりに、動的スキーマサーバーは、更新されたスキーマを API から取得します。 - スキーマ設定内では、必須の（または事前定義済みの）マッピングを追加するオプションがあります。これらは、ユーザーが Experience Platform UIで表示できるマッピングですが、宛先への接続を設定するときに変更することはできません。 例えば、常に宛先に送信されるように、メールアドレスフィールドを強制できます。
schemaConfig セクションは、以下の節で示すように、必要とするスキーマのタイプに応じて、複数の設定パラメーターを使用できます。
静的スキーマの作成 attributes-schema
プロファイル属性を使用して静的スキーマを作成するには、以下に示すように、profileFields 配列でターゲット属性を定義します。
"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"]
}
profileFieldsprofileFields 配列を使用する場合、useCustomerSchemaForAttributeMapping パラメーター全体を省略できます。useCustomerSchemaForAttributeMapping顧客スキーマから profileFields 配列で定義する属性への属性のマッピングを有効または無効にします。
trueに設定すると、ユーザーには、マッピングフィールドのソース列のみが表示されます。この場合、profileFieldsは適用されません。falseに設定すると、ユーザーは、ユーザーのスキーマからprofileFields配列で定義した属性にソース属性をマッピングできます。
デフォルト値は false です。
profileRequiredtrue を使用します。segmentRequiredtrue に設定される必要があります。identityRequiredsegmentNamespaceAllowListほとんどの場合、このパラメーターの使用は推奨されません。 代わりに、
"segmentNamespaceDenyList":[] を使用して、すべてのタイプのオーディエンスを宛先にエクスポートできるようにします。設定に
segmentNamespaceAllowList と segmentNamespaceDenyList の両方がない場合、ユーザーは セグメント化 サービス からのオーディエンスのみをエクスポートできます。segmentNamespaceAllowList segmentNamespaceDenyListは相互に排他的です。segmentNamespaceDenyListAdobe Systems では、
"segmentNamespaceDenyList":[]を設定して、接触チャネルに関係なく、すべてのオーディエンスのエクスポートを許可することを推奨します。設定に
segmentNamespaceAllowed と segmentNamespaceDenyList の両方がない場合、ユーザーは セグメント化 サービス からのオーディエンスのみをエクスポートできます。segmentNamespaceAllowList segmentNamespaceDenyListは相互に排他的です。以下の画像に、結果の UI エクスペリエンスを示します。
ユーザーがターゲットマッピングを選択する場合、profileFields 配列で定義されたフィールドを確認できます。
属性を選択すると、ターゲットフィールド列で確認できます。
動的スキーマの作成 dynamic-schema-configuration
Destination SDK は、動的パートナースキーマの作成をサポートしています。静的スキーマとは対照的に、動的スキーマは、profileFields 配列を使用しません。代わりに、動的スキーマは、スキーマ設定を取得する独自の API に接続する、動的スキーマサーバーを使用します。
動的スキーマ設定では、以下に示すように、profileFields 配列が dynamicSchemaConfig セクションによって置き換えられます。
"schemaConfig":{
"dynamicSchemaConfig":{
"dynamicEnum": {
"authenticationRule":"CUSTOMER_AUTHENTICATION",
"destinationServerId":"DYNAMIC_SCHEMA_SERVER_ID",
"value": "Schema Name",
"responseFormat": "SCHEMA"
}
},
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true
}
dynamicEnum.authenticationRuleExperience Platform の顧客が宛先に接続する方法を示します。使用できる値は CUSTOMER_AUTHENTICATION、PLATFORM_AUTHENTICATION、NONE、
です。
- Experience Platform顧客がここで説明されている認証方法のいずれかを使用してシステムにログインする場合は、
CUSTOMER_AUTHENTICATIONを使用します。 - アドビと宛先との間にグローバル認証システムがあり、Experience Platform の顧客が宛先への接続に認証資格情報を提供する必要がない場合は、
PLATFORM_AUTHENTICATIONを使用します。この場合、資格情報 API を使用して、資格情報オブジェクトを作成する必要があります。 - 宛先プラットフォームにデータを送信するために認証が必要ない場合は、
NONEを使用します。
dynamicEnum.destinationServerIdinstanceId。この宛先サーバーには、動的スキーマを取得するために Experience Platform が呼び出す API エンドポイントが含まれます。dynamicEnum.valuedynamicEnum.responseFormatSCHEMA に設定します。profileRequiredtrue を使用します。segmentRequiredtrue に設定される必要があります。identityRequired必須のマッピング required-mappings
スキーマ設定内では、静的または動的スキーマに加えて、必須の（または事前定義済みの）マッピングを追加するオプションがあります。これらは、ユーザーが Experience Platform UIで表示できるマッピングですが、宛先への接続を設定するときに変更することはできません。
例えば、常に宛先に送信されるように、メールアドレスフィールドを強制できます。
- 必須のソースフィールドと必須の宛先フィールドを設定できます。この場合、ユーザーは、2 つのうちどちらかのフィールドを編集または選択できず、選択した方のみを表示できます。
- 必須の宛先フィールドのみを設定できます。この場合、ユーザーは、宛先にマッピングするためのソースフィールドを選択できます。
必須のマッピングを含むスキーマ設定と、これらがバッチ宛先に対するデータの有効化ワークフローのマッピング手順でどのように見えるかについて、以下の 2 つ例を参照してください。
以下に、必須のソースと宛先の両方のマッピングの例を示します。ソースと宛先の両方のフィールドが必須のマッピングとして指定されている場合、ユーザーは、2 つのうちどちらかのフィールドを選択または編集できず、事前定義済みの選択のみを表示できます。
| code language-json |
|---|
|
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
|---|---|---|---|
| パラメーター | タイプ | 必須／オプション | 説明 |
requiredMappingsOnly |
ブール値 | オプション | これが true に設定されている場合、ユーザーは、requiredMappings 配列で定義する必須のマッピング以外に、アクティベーションフローで他の属性および ID をマッピングできません。 |
requiredMappings.sourceType |
文字列 | 必須 |
|
requiredMappings.source |
文字列 | 必須 |
ソースフィールドの値を示します。サポートされる値タイプを以下に示します。
|
requiredMappings.destination |
文字列 | 必須 | ターゲットフィールドの値を示します。ソースと宛先の両方のフィールドが必須のマッピングとして指定されている場合、ユーザーは、2 つのうちどちらかのフィールドを選択または編集できず、選択した方のみを表示できます。 |
その結果、Experience Platform UIの「 出力元フィールド および Targetフィールド の両方のセクションがグレー表示されます。
以下に、必須の宛先マッピングの例を示します。宛先フィールドのみが必須として指定されている場合、ユーザーは、マッピングするソースフィールドを選択できます。
| code language-json |
|---|
|
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
|---|---|---|---|
| パラメーター | タイプ | 必須／オプション | 説明 |
requiredMappingsOnly |
ブール値 | オプション | これが true に設定されている場合、ユーザーは、requiredMappings 配列で定義する必須のマッピング以外に、アクティベーションフローで他の属性および ID をマッピングできません。 |
requiredMappings.destination |
文字列 | 必須 | ターゲットフィールドの値を示します。宛先フィールドのみが指定されている場合、ユーザーは、宛先にマッピングするソースフィールドを選択できます。 |
mandatoryRequired |
ブール値 | オプション | マッピングが必須の属性としてマークされる必要があるかどうかを示します。 |
primaryKeyRequired |
ブール値 | オプション | マッピングが重複排除キーとしてマークされる必要があるかどうかを示します 。 |
その結果、Experience Platform UIの [ Target ] セクションはグレー表示され、[ 出力元 フィールド] セクションはアクティブになり、ユーザーは操作できます。 必須キー および 重複排除キー オプションがアクティブになり、ユーザーは変更できません。
外部オーディエンスのサポートの設定 external-audiences
外部で生成されたオーディエンスのアクティベーションをサポートするようにリンク先を設定するには、以下のスニペットをschemaConfigセクションに含めます。
"schemaConfig": {
"segmentNamespaceDenyList": [],
...
}
segmentNamespaceDenyList機能の詳細については、このページの上記の 表のプロパティ説明を参照してください。
次の手順 next-steps
この記事を読むことで、Destination SDK でサポートされるスキーマタイプと、どのようにスキーマを設定できるかについて、理解を深めることができました。
その他の宛先コンポーネントについて詳しくは、以下の記事を参照してください。