ID 名前空間設定

Experience Platform は、ID 名前空間を使用して、特定の ID のタイプを記述します。例えば、Email と呼ばれる ID 名前空間は、name@email.com のような値をメールアドレスとして識別します。

に加えて、Destination SDKを通じてリアルタイム（ストリーミング）の宛先を作成する場合 パートナースキーマの設定 ユーザーがプロファイル属性と id をにマッピングできるように、宛先プラットフォームでサポートされる id 名前空間も定義する必要があります。 例えば、宛先プラットフォームがハッシュ化された電子メールを受け入れ、 IDFAの場合、これら 2 つの ID を このドキュメントでさらに詳しく説明する.

ストリーミング宛先に対してオーディエンスをアクティブ化する場合、ユーザーは、ターゲットプロファイル属性に加えて、ターゲット ID をマッピングする必要があります。 そうしないと、オーディエンスは宛先プラットフォームに対してアクティブ化されません。

Destination SDKを使用してファイルベースの宛先を作成する場合、ID 名前空間の設定はオプションです。

Experience Platform の ID 名前空間について詳しくは、ID 名前空間ドキュメントを参照してください。

宛先用に ID 名前空間を設定する場合、宛先でサポートされているターゲット ID マッピングを微調整できます。以下に例を示します。

Destination SDKを使用して作成された統合で、このコンポーネントがどこに適合するかを把握するには、 設定オプション ドキュメントを参照するか、 Destination SDKを使用したファイルベースの宛先の設定.

/authoring/destinations エンドポイントを介して、サポートされる ID 名前空間を設定できます。このページに表示されるコンポーネントを設定できる、詳細な API 呼び出しの例については、以下の API リファレンスページを参照してください。

この記事では、宛先に使用できる、サポートされるすべての ID 名前空間設定オプションを説明し、Platform UI で顧客に何が表示されるかを示します。

サポートされる統合タイプ supported-integration-types

このページで説明される機能をサポートする統合のタイプについて詳しくは、以下の表を参照してください。

サポートされるパラメーター supported-parameters

宛先がサポートするターゲット ID を定義する際に、以下の表で説明されているパラメーターを使用して、その動作を設定できます。

"identityNamespaces":{
      "external_id":{
         "acceptsAttributes":true,
         "acceptsCustomNamespaces":true,
         "acceptedGlobalNamespaces":{
            "Email":{
            }
         }
      },
      "another_id":{
         "acceptsAttributes":true,
         "acceptsCustomNamespaces":true
      }
   }

どの Platform ID の顧客が宛先に書き出すことができるかを示す必要があります。例として、Experience Cloud ID、ハッシュ化されたメール、デバイス ID（IDFA、GAID）などがあります。これらの値は、Platform ID 名前空間であり、顧客が宛先から ID 名前空間にマッピングできます。

ID 名前空間は、Platform と宛先が 1 対 1 で対応している必要はありません。
例えば、顧客は Platform IDFA 名前空間を宛先からの IDFA 名前空間にマッピングすることができ、また顧客は同じ Platform IDFA 名前空間を宛先の Customer ID 名前空間にマッピングすることもできます。

ID について詳しくは、ID 名前空間の概要を参照してください。

マッピングに関する考慮事項

顧客がソース ID 名前空間を選択して、ターゲットマッピングを選択しない場合、Platform は、自動的に同じ名前の属性でターゲットマッピングを設定します。

オプションのソースフィールドハッシュの設定

Experience Platform 顧客は、ハッシュ化された形式またはプレーンテキストでデータを Platform に取り込むことを選択できます。宛先プラットフォームがハッシュ化されたデータとハッシュ化されていないデータの両方を受け入れる場合、宛先に書き出される際に、Platform がソースフィールド値をハッシュ化する必要があるかどうかを顧客が選択できるようにすることができます。

以下の設定は、Platform UI のマッピング手順でオプションの「変換を適用」オプションを有効にします。

"identityNamespaces":{
      "Customer_contact":{
         "acceptsAttributes":true,
         "acceptsCustomNamespaces":true,
         "transformation": "sha256(lower($))",
         "acceptedGlobalNamespaces":{
            "Email":{
            },
            "Phone":{
            }
         }
      }
   }

ハッシュ化されていないソースフィールドを使用している場合に、このオプションを有効にすると、Adobe Experience Platform でアクティベーション時に自動的にハッシュ化されます。

ハッシュ化されていないソース属性を、宛先によってハッシュ化されることが期待されているターゲット属性（例：email_lc_sha256 や phone_sha256）にマッピングしている場合、アクティベーション時に Adobe Experience Platform にソース属性を自動的にハッシュ化させるために、「変換を適用」オプションをオンにします。

必須のソースフィールドハッシュの設定

宛先がハッシュ化されたデータのみを受け入れる場合、書き出された属性が Platform によって自動的にハッシュ化されるように設定できます。以下の設定は、Email および Phone ID がマッピングされると、「変換を適用」オプションを自動的にオンにします。

"identityNamespaces":{
      "Customer_contact":{
         "acceptsAttributes":true,
         "acceptsCustomNamespaces":true,
         "transformation": "sha256(lower($))",
         "acceptedGlobalNamespaces":{
            "Email":{
               "requiredTransformation": "sha256(lower($))"
            },
            "Phone":{
               "requiredTransformation": "sha256(lower($))"
            }
         }
      }
   }

次の手順 next-steps

この記事を読むことで、Destination SDK で作成された宛先に対する ID 名前空間の設定方法ついて、理解を深めることができました。

その他の宛先コンポーネントについて詳しくは、以下の記事を参照してください。