宛先アクティブ化ワークフローでの ID の処理

このページでは、ID を様々な宛先タイプに書き出す方法の詳細について説明し、宛先に応じて書き出すことができる ID を見つける方法についても説明します。

カタログ内の宛先はそれぞれ微妙に異なり、すべての宛先に万能の設定はありません。ただし、以下の節で説明するように、宛先の設定とそのID要件を導くパターンがいくつかあります。

ファイルベースの宛先 file-based

ファイルベースの宛先（例えば、Amazon S3、SFTP、Adobe Campaign、Oracle Eloqua、Salesforce Marketing Cloud などのほとんどのメールマーケティングの宛先）の場合、これらの宛先のほとんどでの ID 設定はオープンです。つまり、バッチアクティベーションワークフローの属性を選択手順で ID を選択する必要はありません。

ファイルの書き出しに ID を追加することを選択した場合、書き出しでは ID 名前空間から 1 つの ID しか選択できません。書き出す ID を選択すると、必須属性および重複排除キーとして自動的に選択されます。

回避策として、ID が属性として Experience Platform に取り込まれている場合は、さらに ID を書き出しに追加できます。ID 名前空間 Phone_E.164 に加えて、XDM 属性メールアドレスが書き出し用に選択された例を以下に示します。

ID マップからの ID の書き出しと XDM 属性としての ID の書き出し - 相違点 identity-map-or-attribute

書き出されるレコードの数は、ID マップから書き出す ID を選択するか、Experience Platform に属性として取り込まれた ID を選択するかによって異なる場合があります。結合ポリシーは、ID マップから ID を選択する際に書き出されるレコードの数にも重要な役割を果たします。

例えば、2 つの異なるデータセットから、1 つの顧客プロファイルに結合される次のプロファイルフラグメントがあるとします。

プロファイルフラグメント 1

プロファイルフラグメント 2

結合されたプロファイルは次のようになります。

書き出しの動作は、書き出しに IdentityMap: Email または xdm: personalEmail.address のどちらを選択するかによって異なります。

顧客が IdentityMap: Email をアクティブ化すると、書き出されたファイルには、email1 用と email2 用の 2 つのレコードが含まれます。

ただし、顧客が xdm: personalEmail.address をアクティブ化すると、email 属性フィールドには email2 のみが含まれるので、email2 のみがレコードに表示されます。これらの状況は、顧客のファイルにあるすべてのメールアドレスや、顧客のファイルにある最新のメールアドレスに対してアクティブ化する必要がある様々なユースケースに対応できます。

書き出すレコードの数は、選択した結合ポリシーと、書き出しで ID または属性を選択したかどうかによって決まります。

API ベースのストリーミング宛先 streaming-destinations

Destination SDK で作成した API ベースのストリーミングの宛先（Facebook、Google Customer Match、Pinterest、Braze など）は、書き出し用に特定の ID のみをサポートします。各宛先に書き出し可能な特定の ID について詳しくは、各宛先のドキュメントページの​サポートされている ID 節（例えば、Pinterest の宛先のページのサポートされている ID に関する節）を参照してください。

ただし、プライベートグラフまたは属性のどちらのデータも ID として柔軟に使用できることに注意してください。つまり、XDM 属性を、宛先で必要な ID フィールドにマッピングできます。 Pinterest の宛先の例を以下に示します。この例では、XDM 属性 personalEmail.address が必須の Pinterest ID pinterest_audience にマッピングされています。

サードパーティ Cookie の統合に基づく広告宛先 third-party-cookie-destinations

サードパーティ Cookie に基づく広告の宛先（例えば Google Ads、Google Ad Manager、Google DV360、Bing、The Trade Desk など）を使用する場合は、アクティブ化ワークフローで顧客が ID を選択する必要はありません。 これらの宛先では、アクティベーションワークフローを設定する際に、Experience PlatformがExperience Cloud ID serviceによって構築されたID照合テーブルを自動的に検索し、プロファイルで使用可能であり、宛先でサポートされているすべてのIDを書き出します。

これらの宛先では、Experience Cloud ID serviceまたはExperience Platform Web SDKを通じてID同期を行う必要があります。

Experience Platform Web SDKを使用しており、従来のExperience Cloud ID serviceがページに実装されていない場合は、​ データストリームの設定ドキュメント ​に記載されているように、問題のweb サイトのデータストリームがサードパーティ IDの同期を許可するように有効になっていることを確認する必要があります。

上記のドキュメントで説明されているようにデータストリームを設定する場合は、Third Party ID Sync スライダーが有効になっていることを確認する必要があります。 ほとんどのお客様は、container_id フィールドを空白のまま残すでしょう（デフォルトは 0）。 従来の Audience Manager 実装で特定のコンテナ ID を使用していた場合にのみ、この値を変更する必要があります（ただし、それはごく少数のお客様の場合です）。

エンタープライズの宛先 enterprise-destinations

エンタープライズの宛先（Amazon Kinesis、Azure Event Hubs、HTTP API）の場合は、データの書き出しに特定の ID は必要ありません。これらは、エンタープライズ統合のユースケース向けに設計されているからです。 ただし、必要に応じて、ID を XDM 属性として、または ID マップから書き出すことができます。 HTTP の宛先に書き出されたデータの例を示します。この例では、personalEmail.address XDM 属性と ID ECID および email_lc_sha256（ハッシュ化されたメールアドレス）をどちらも含んでいます。

パーソナライゼーションの宛先 personalization-destinations

統合はプロファイル ルックアップであるため、Personalization（またはエッジ）の宛先 （例：Adobe Target、Custom Personalization）では、アクティブ化ワークフローでIDを選択する必要はありません。 クライアント （Target、Web SDKなど）はEdgeに対してクエリを実行し、オンサイトのパーソナライゼーションに必要なプロファイル情報を取得します。

次の手順 next-steps

このドキュメントを通して、個々の宛先でサポートされている ID や必要な ID を見つける方法がわかりました。 また、宛先タイプごとの ID 選択の仕組みも理解できました。

次は、宛先の書き出し設定について、様々な宛先タイプ間で共通なものはどれか、開発者が個々の宛先レベルで設定できるものはどれか、アクティブ化ワークフローでユーザーが編集できるものはどれかを学びます。

また、カタログに登録されているすべての宛先も確認できます。