Identity Graph Linking Rulesの実装ガイド
Adobe Experience Platform Identity Serviceを利用してデータを導入する際に守るべき、ステップバイステップガイドをご確認ください。
ステップバイステップ形式の概要:
導入の前提条件 prerequisites-for-implementation
この節では、Identity Graph Linking Rulesをデータに実装する前に完了する必要がある前提条件の手順の概要を説明します。
一意の名前空間
単一ユーザーの名前空間要件 single-person-namespace-requirement
優先度が最も高い一意の名前空間が、すべての既知のプロファイルに常に存在することを確認する必要があります。 これにより、ID サービスは、特定のグラフ内の適切な人物IDを検出できます。
個人のIDを表す一意の名前空間がなければ、異なる個人のIDにリンクするグラフが同じECIDに表示される場合があります。 この例では、B2BCRMとB2CCRMの両方が同時に同じECIDにリンクされています。 このグラフは、TomがB2C ログインアカウントを使用して、Summerとデバイスを共有し、B2B ログインアカウントを使用していることを示しています。 ただし、システムは、これが1つのプロファイル(グラフの折りたたみ)であることを認識します。
一意の名前空間(この場合は、異なる2つの名前空間ではなくCRMID)を指定すると、ID サービスは、ECIDに最後に関連付けられた人物IDを識別できます。 この例では、一意のCRMIDが存在するため、ID サービスは、2つのエンティティが同じデバイスを共有している「共有デバイス」シナリオを認識できます。
名前空間優先度設定
Adobe Analytics ソースコネクタ を使用してデータを取り込む場合は、ID サービスがAAIDをブロックするため、ECIDにAdobe Analytics ID (AAID)よりも高い優先度を付与する必要があります。 ECIDを優先することで、Real-Time Customer Profileに対して、未認証のイベントをAAIDではなくECIDに保存するように指示できます。
XDM エクスペリエンスイベント xdm-experience-events
実装前のプロセス中に、Experience Platform に送信される認証済みイベントに、CRMID などの 単一 のユーザー識別子が常に含まれていることを確認する必要があります。
- (推奨) 1つの一意の人物IDを持つ認証イベント。
- (推奨されない) 2つの一意の人物IDを持つ認証イベント。 複数の一意の個人IDがある場合、不要なグラフの折りたたみが発生することがあります。
- (推奨されない)一意の人物IDを持たない認証イベント。 一意の人物IDがない場合、未認証イベントと認証済みイベントの両方がECIDに対して保存されます。
| code language-json |
|---|
|
システムが2人のユーザーIDを送信する場合、1人の名前空間要件の実装が失敗する可能性があります。 例えば、webSDK実装のidentityMapにCRMID、customerID、ECID名前空間が含まれている場合、すべてのイベントにCRMIDとcustomerIDの両方が含まれるという保証はありません。
次のようなペイロードを not 送信する必要があります:
| code language-json |
|---|
|
ただし、2つの個人IDを送信することはできますが、実装やデータエラーのために不要なグラフの折りたたみが防止される保証はありません。 次のシナリオについて検討してください。
timestamp1= Johnがログイン -> システムがCRMID: John, ECID: 111をキャプチャします。 ただし、このイベントペイロードにはcustomerID: Johnが存在しません。timestamp2= Janeがログイン -> システムがcustomerID: Jane, ECID: 111をキャプチャします。 ただし、このイベントペイロードにはCRMID: Janeが存在しません。
したがって、認証されたイベントを使用して、1つの個人IDのみを送信することをお勧めします。
グラフシミュレーションでは、この取り込みは次のようになります。
この例では、John (エンドユーザー)が認証中にweb サイトを閲覧していた間に、次のイベントがExperience Platformに送信されたと仮定できます。 しかし、Experience Platformは認証されているにもかかわらず、イベントに個人IDが不足しているため、Johnを識別できません。 したがって、このイベントは、Johnに特に関連付けられたオンラインアクティビティとして認識するのではなく、Adobe Business web サイトを閲覧する匿名ユーザーとして解釈されます。
| code language-json |
|---|
|
権限の設定 set-permissions
Identity Serviceの実装プロセスの最初の手順は、必要な権限を持つプロビジョニングされたロールにExperience Platform アカウントが追加されていることを確認することです。 管理者は、Adobe Experience Cloudの権限UIに移動して、アカウントの権限を設定できます。 そこから、アカウントを次の権限を持つ役割に追加する必要があります。
- View Identity Settings:この権限を適用して、ID名前空間参照ページで一意の名前空間と名前空間の優先度を表示できるようにします。
- Edit Identity Settings:この権限を適用して、ID設定を編集および保存できるようにします。
権限について詳しくは、権限ガイド を参照してください。
ID名前空間の作成 namespace
データに必要な場合は、まず組織に適切な名前空間を作成する必要があります。 カスタム名前空間を作成する手順については、UIでのカスタム名前空間の作成に関するガイドを参照してください。
グラフシミュレーションツールの使用 graph-simulation
次に、Identity Service UI ワークスペースの グラフシミュレーションツール に移動します。 グラフシミュレーションツールを使用すると、様々な一意の名前空間と名前空間の優先度設定で構築されたID グラフをシミュレートできます。
様々な設定を作成することで、グラフシミュレーションツールを使用して、ID最適化アルゴリズムと特定の設定がグラフの動作にどのような影響を与えるかを学習し、より深く理解できます。
ID設定の設定 identity-settings
グラフの動作について理解できたら、Identity Service UI ワークスペースのID設定UIに移動します。 ID設定UIにアクセスするには、左側のナビゲーションから「Identities」を選択し、「Settings」を選択します。
ID設定UIを使用して、一意の名前空間を指定し、優先度の順に名前空間を設定します。
詳しくは、ID設定UI ガイド を参照してください。
XDM スキーマの作成 schema
独自の名前空間と名前空間の優先順位が確立されたら、データを取り込むために必要な設定に進むことができます。 まず、XDM スキーマを作成する必要があります。 データによっては、XDM Individual ProfileとXDM ExperienceEventの両方のスキーマを作成する必要がある場合があります。
データをリアルタイム顧客プロファイルに取り込むには、スキーマにプライマリ IDとして指定されたフィールドが少なくとも1つ含まれていることを確認する必要があります。 プライマリ IDを設定することで、プロファイルの取り込みに対して特定のスキーマを有効にできます。
スキーマの作成方法については、UIでのXDM スキーマの作成に関するガイドを参照してください。
データセットの作成 dataset
次に、取り込むデータの構造を提供するデータセットを作成します。 データセットは、スキーマ(列)とフィールド(行)で構成されるデータコレクション(通常はテーブル)を格納し管理するための構造です。 データセットはスキーマと並行して動作し、データをリアルタイム顧客プロファイルに取り込むには、プロファイル取り込み用にデータセットを有効にする必要があります。 データセットをプロファイルに対して有効にするには、プロファイルの取り込みに対して有効になっているスキーマを参照する必要があります。
データセットの作成方法については、 データセット UI ガイド を参照してください。
データの収集 ingest
ここでは、次の要素を取り入れる必要があります。
- ID サービス機能にアクセスするために必要な権限。
- データの名前空間。
- 一意の名前空間を指定し、名前空間の優先順位を設定します。
- 1つ以上のXDM スキーマ。 (データや特定のユースケースによっては、プロファイルスキーマとエクスペリエンスイベントスキーマの両方を作成する必要がある場合があります)。
- スキーマにもとづいたデータセットです。
上記のすべての項目を完了したら、Experience Platformへのデータの取り込みを開始できます。 データ収集は、さまざまな方法で実行できます。 次のサービスを使用して、データをExperience Platformに取り込むことができます。
フィードバックについては、Identity Service UI ワークスペースのBeta feedback オプションを使用してください。
グラフの検証 validate
ID ダッシュボードを使用して、ID グラフの全体的な数やグラフ数の傾向、名前空間ごとのID数、グラフサイズごとのグラフ数など、ID グラフの状態に関するインサイトを得ることができます。 ID ダッシュボードを使用して、名前空間別に整理された、2つ以上のIDを持つグラフのトレンドを表示することもできます。
省略記号(...)を選択し、View moreを選択して詳細を確認し、折りたたまれたグラフがないことを検証します。
表示されるウィンドウを使用して、折りたたまれたグラフの情報を表示します。 この例では、電子メールと電話の両方が一意の名前空間としてマークされているので、サンドボックスに折りたたまれたグラフはありません。
付録 appendix
ID設定と一意の名前空間を実装する際に参照できる追加情報については、この節を参照してください。
Dangling loginID シナリオ dangling-loginid-scenario
次のグラフは、「ぶら下がっている」 loginID シナリオをシミュレートしています。 この例では、2つの異なるログイン IDが同じECIDにバインドされています。 ただし、{loginID: ID_C}はCRMIDにリンクされていません。 したがって、これらの2つのログイン IDが2つの異なるエンティティを表していることをID サービスが検出する方法はありません。
この例では、{loginID: ID_C}は未接続のままになり、CRMIDにリンクされていません。 したがって、このloginIDを関連付ける個人エンティティは曖昧なままになります。
この例では、{loginID: ID_C}は{CRMID: Tom}にリンクされています。 したがって、システムはこのloginIDがTomに関連付けられていることを識別できます。
この例では、{loginID: ID_C}は{CRMID: Summer}にリンクされています。 したがって、システムはこのloginIDが別の人物エンティティ(この場合はSummer)に関連付けられていることを識別できます。
また、この例では、TomとSummerがデバイスを共有している異なる人物エンティティ({ECID: 111}で表される)に対して使用されていることも示されています。
次の手順
Identity Graph Linking Rulesについて詳しくは、次のドキュメントを参照してください。