パートナースキーマ設定
Experience Platform では、スキーマを使用して、一貫性のある再利用可能な方法でデータの構造を記述します。 データが Experience Platform に取り込まれると、XDM スキーマに応じて構造化されます。 デザインの原則やベストプラクティスなど、スキーマ構成モデルについて詳しくは、スキーマ構成の基本を参照してください。
Destination SDK で宛先を作成する場合、宛先プラットフォームによって使用される独自のパートナースキーマを定義できます。 これにより、Experience Platform UI内で、Experience Platformのプロファイル属性を、宛先プラットフォームが認識する特定のフィールドにマッピングできます。
宛先用にパートナースキーマを設定する場合、宛先プラットフォームでサポートされているフィールドマッピングを微調整できます。以下に例を示します。
- ユーザーは、
phoneNumberXDM 属性を宛先プラットフォームでサポートされているphone属性にマッピングできます。 - 宛先内のサポートされるすべての属性のリストを取得するために Experience Platform が動的に呼び出す、動的パートナースキーマを作成します。
- 宛先プラットフォームが必要とする必須のフィールドマッピングを定義します。
このコンポーネントがDestination SDKで作成された統合にどの程度適合するかを理解するには、configuration options ドキュメントの図を参照するか、Destination 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では、
"segmentNamespaceDenyList":[]を設定して、ソースに関係なく、すべてのオーディエンスの書き出しを許可することをお勧めします。重要：
schemaConfigでsegmentNamespaceDenyListを指定せず、segmentNamespaceAllowListを使用しない場合、システムは自動的にsegmentNamespaceDenyListを[]に設定します。 これにより、今後カスタムオーディエンスが失われるのを防ぐことができます。 安全性を確保するために、Adobeでは、設定で"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を使用して資格情報オブジェクト を作成し、宛先配信設定のauthenticationIdパラメーターに資格情報オブジェクトのIDを渡す必要があります。 - 宛先プラットフォームにデータを送信するために認証が必要ない場合は、
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の Source フィールド と ターゲットフィールド の両方のセクションがグレー表示されます。
以下に、必須の宛先マッピングの例を示します。 宛先フィールドのみが必須として指定されている場合、ユーザーは、マッピングするソースフィールドを選択できます。
| 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のターゲットフィールド セクションはグレー表示になり、Source フィールド セクションはアクティブになり、ユーザーは操作できます。 必須キーおよび 重複排除キー のオプションは有効であり、ユーザーは変更できません。
外部オーディエンスのサポートの設定 external-audiences
外部で生成されたオーディエンス のアクティブ化をサポートするように宛先を設定するには、schemaConfig セクションに以下のスニペットを含めます。
"schemaConfig": {
"segmentNamespaceDenyList": [],
...
}
segmentNamespaceDenyList機能について詳しくは、このページの上の表のプロパティの説明を参照してください。
次の手順 next-steps
この記事を読むことで、Destination SDK でサポートされるスキーマタイプと、どのようにスキーマを設定できるかについて、理解を深めることができました。
その他の宛先コンポーネントについて詳しくは、以下の記事を参照してください。