Experience Data Model (XDM) は、ダウンストリームAdobe Experience Platformサービスで使用する共通の構造と定義を提供することで、顧客体験データを標準化するコアフレームワークです。 XDM 標準に準拠することで、すべての顧客体験データを共通の表現に組み込むことで、顧客の行動から有益なインサイトを得たり、セグメントを通じて顧客オーディエンスを定義したり、パーソナライズ目的で顧客属性を表したりできます。
XDM は非常に汎用性が高く、デザインによってカスタマイズ可能なので、スキーマを設計する際には、データモデリングのベストプラクティスに従うことが重要です。 このドキュメントでは、顧客体験データを XDM にマッピングする際におこなう必要がある主な決定と考慮事項について説明します。
このガイドを読む前に、 XDM システムの概要 XDM とその役割の概要を説明します。Experience Platform
さらに、このガイドでは、スキーマデザインに関する主な考慮事項にのみ焦点を当てています。 したがって、 スキーマ構成の基本 このガイドで取り上げる個々のスキーマ要素の詳細については、を参照してください。
Experience Platformで使用するデータモデルを設計するための推奨されるアプローチを、次のように要約できます。
ビジネスユースケースの実施に必要な適切なデータソースの特定に関する手順は、組織によって異なります。 このドキュメントの残りの節では、データソースを特定した後に ERD を整理および構築する後の手順に焦点を当てますが、図の様々なコンポーネントに関する説明によって、データソースの移行先の決定が示されます Platform.
に取り込むデータソースを決定したら、 Platformでは、高レベルの ERD を作成して、データを XDM スキーマにマッピングするプロセスをガイドします。
次の例は、にデータを取り込む会社の簡易 ERD を示しています。 Platform. 次の図は、顧客アカウント、ホテル、住所、一般的な e コマースイベントなど、XDM クラスに分類する必要がある基本的なエンティティを示しています。
ERD を作成して、に取り込む必須エンティティを識別します。 Platformに値を指定する場合、これらのエンティティはプロファイル、参照、イベントの各カテゴリに分類される必要があります。
カテゴリ | 説明 |
---|---|
プロファイルエンティティ | プロファイルエンティティは、個人(通常は顧客)に関する属性を表します。 このカテゴリに該当するエンティティは、 XDM Individual Profileクラス. |
参照エンティティ | ルックアップエンティティは、個々の人物に関連付けることができる概念を表しますが、個人を識別するために直接使用することはできません。 このカテゴリに該当するエンティティは、 カスタムクラス、およびは、 スキーマの関係. |
イベントエンティティ | イベントエンティティは、顧客が実行できるアクション、システムイベント、または時間の経過と共に変更を追跡する必要があるその他の概念に関する概念を表します。 このカテゴリに該当するエンティティは、 XDM ExperienceEventクラス. |
以下の節では、上記のカテゴリにエンティティを分類する方法について詳しく説明します。
エンティティカテゴリ間での並べ替えの主な方法は、取り込まれるデータが可変かどうかです。
通常、プロファイルまたは参照エンティティに属する属性は可変です。 例えば、顧客の環境設定が時間の経過と共に変化し、サブスクリプションプランのパラメーターは市場のトレンドに応じて更新される場合があります。
これに対し、イベントデータは通常不変です。 イベントは特定のタイムスタンプに添付されるので、イベントが提供する「システムスナップショット」は変更されません。 例えば、イベントは、買い物かごのチェックアウト時に顧客の環境設定を取り込み、後で顧客の環境設定が変更されても変更しません。 イベントデータは、記録後は変更できません。
要約すると、プロファイルとルックアップエンティティには可変属性が含まれ、取得する主体に関する最新の情報を表します。一方、イベントは特定の時点でのシステムの不変レコードです。
エンティティに個々の顧客に関連する属性が含まれている場合、そのエンティティはおそらくプロファイルエンティティです。 顧客属性の例を次に示します。
エンティティ内の特定の属性が時間の経過と共にどのように変化するかを分析する場合は、おそらくイベントエンティティです。 例えば、買い物かごへの製品項目の追加は、 Platform:
顧客 ID | タイプ | 製品 ID | 数量 | タイムスタンプ |
---|---|---|---|---|
1234567 | Add | 275098 | 2 | 10 月 1 日午前 10 時 32 分 |
1234567 | 削除 | 275098 | 1 | 10 月 1 日午前 10 時 33 分 |
1234567 | Add | 486502 | 1 | 10 月 1 日 10:41 AM |
1234567 | Add | 910482 | 5 | 10 月 3 日午後 2 時 15 分 |
エンティティを分類する場合は、特定のビジネスユースケースに対処するために構築したいオーディエンスセグメントについて検討することが重要です。
例えば、ある会社は、昨年 5 回以上購入したロイヤルティプログラムの「ゴールド」または「プラチナ」のメンバー全員を知りたがっています。 このセグメントロジックに基づいて、関連エンティティをどのように表すかに関して、次の結論を出すことができます。
セグメント化の使用例に関する考慮事項に加えて、関連する追加の属性を識別するために、これらのセグメントに対するアクティブ化の使用例も確認する必要があります。
例えば、会社が country = US
. 次に、特定のダウンストリームターゲットに対してそのセグメントをアクティブ化する際に、書き出されたすべてのプロファイルを自宅の状態に基づいてフィルタリングしたいと考えます。 したがって、 state
属性は、該当するプロファイルエンティティでも取り込む必要があります。
データの使用例と精度に基づいて、特定の値を事前に集計してからプロファイルまたはイベントエンティティに含める必要があるかどうかを判断する必要があります。
例えば、ある会社は、買い物かごの購入数に基づいてセグメントを作成したいと考えています。 各タイムスタンプ付き購入イベントを独自のエンティティとして含めることで、最も低い精度でこのデータを組み込むよう選択できます。 ただし、これにより、記録されたイベントの数が急激に増える場合があります。 取り込まれるイベントの数を減らすために、集計値を作成することもできます numberOfPurchases
1 週間か 1 ヶ月の間に MIN やMAXなどの他の集計関数も、このような状況に適用できます。
Experience Platformは現在、自動値集計を実行していませんが、将来のリリースで予定されています。 集計値を使用する場合は、外部で計算を実行してから、にデータを送信する必要があります。 Platform.
ERD で確立された基数は、エンティティの分類方法に関するヒントを提供することもできます。 2 つのエンティティ間に 1 対多の関係がある場合、「多数」を表すエンティティはイベントエンティティである可能性が高くなります。 ただし、「多数」とは、プロファイルエンティティ内の配列として提供されるルックアップエンティティのセットのことです。
すべての使用例に適合するユニバーサルアプローチがないので、基数に基づいてエンティティを分類する際には、各状況の長所と短所を考慮することが重要です。 詳しくは、 次のセクション を参照してください。
次の表に、一般的なエンティティの関係と、それらから派生できるカテゴリを示します。
関係 | カーディナリティ | エンティティのカテゴリ |
---|---|---|
顧客と買い物かごのチェックアウト | 1 対多 | 1 人の顧客に多数の買い物かごのチェックアウトがある場合があります。これは、時間の経過と共に追跡できるイベントです。 したがって、顧客はプロファイルエンティティになり、買い物かごのチェックアウトはイベントエンティティになります。 |
顧客およびロイヤリティアカウント | 1 対 1 | 1 人の顧客が持つことのできるロイヤルティアカウントは 1 つだけで、その逆も同様です。 関係は 1 対 1 なので、顧客とロイヤルティアカウントの両方がプロファイルエンティティを表します。 |
顧客と購読 | 1 対多 | 1 人の顧客が多数のサブスクリプションを持っている場合があります。 この会社は顧客の現在の購読のみを扱うので、 Customers はプロファイルエンティティ、 Subscriptions はルックアップエンティティです。 |
前の節では、エンティティの分類方法を決定するための一般的なガイドラインをいくつか示しましたが、1 つのエンティティカテゴリを別のエンティティカテゴリよりも選択する場合に長所と短所が多いことがあることを理解することが重要です。 次のケーススタディでは、このような状況でオプションをどのように考慮するかを説明します。
ある会社は、顧客のアクティブな購読を追跡し、1 人の顧客が多数の購読を持つことができます。 また、アクティブな購読を持つすべてのユーザーを検索するなど、セグメント化の使用例の購読を含めたいと考えています。
このシナリオでは、データモデルで顧客のサブスクリプションを表す 2 つの選択肢が考えられます。
第 1 のアプローチは、購読の配列を Customers のプロファイルエンティティ内に属性として含めることです。 この配列内のオブジェクトには、次のフィールドが含まれます: category
, status
, planName
, startDate
、および endDate
.
長所
短所
2 つ目のアプローチは、イベントスキーマを使用して購読を表すことです。 これには、最初の方法と同じ購読フィールドと、購読 ID、顧客 ID、購読イベントが発生した日時のタイムスタンプが追加されます。
長所
短所
エンティティをプロファイル、参照、イベントカテゴリに並べ替えたら、データモデルの XDM スキーマへの変換を開始できます。 デモ用に、前述の例のデータモデルは、次の図で適切なカテゴリに並べ替えられています。
エンティティの並べ替えの基になるカテゴリは、スキーマの基になる XDM クラスを決定する必要があります。 繰り返し実行する手順は、次のとおりです。
イベントエンティティはほとんどの場合、別々のスキーマで表されますが、プロファイルまたは参照カテゴリ内のエンティティは、その基数に応じて、1 つの XDM スキーマに組み合わせることができます。
例えば、 Customers エンティティは LoyaltyAccounts エンティティと 1 対 1 の関係を持つので、 Customers エンティティのスキーマには LoyaltyAccount
オブジェクトに含め、各顧客に適したロイヤルティフィールドを格納します。 ただし、関係が 1 対多の場合、「多く」を表すエンティティは、複雑さに応じて、別のスキーマまたはプロファイル属性の配列で表すことができます。
以下の節では、ERD に基づいてスキーマを構築する際の一般的なガイダンスを示します。
この スキーマ進化のルール 実装後は、スキーマに対して非破壊的な変更のみを加えることができます。 つまり、スキーマにフィールドを追加し、そのフィールドに対してデータを取り込むと、そのフィールドを削除できなくなります。 したがって、スキーマを最初に作成するときに、反復モデリングのアプローチを採用することが不可欠です。最初はシンプルな実装から始め、時間の経過と共に複雑さが徐々に増します。
特定のフィールドをスキーマに含める必要があるかどうかが不明な場合は、除外することをお勧めします。 後でフィールドが必要と判断された場合は、スキーマの次の反復でいつでも追加できます。
Experience Platformでは、ID としてマークされた XDM フィールドを使用して、複数のデータソースから取得した個々の顧客に関する情報を組み合わせます。 1 つのスキーマに複数のフィールドを ID としてマークすることはできますが、でスキーマを使用するためには、1 つのプライマリ ID を定義する必要があります Real-Time Customer Profile. 詳しくは、 id フィールド 「スキーマ構成の基本」で、これらのフィールドの使用例に関する詳細を参照してください。
スキーマを設計する際、リレーショナルデータベーステーブル内のプライマリキーは、おそらくプライマリ ID の候補となります。 該当する ID フィールドの他の例としては、顧客の電子メールアドレス、電話番号、アカウント ID などがあります。 ECID.
Experience Platformには、次のスキーマアプリケーションに関連するデータを取得するための、あらかじめ用意されているいくつかの XDMAdobeフィールドグループが用意されています。
例えば、 Adobe Analytics ExperienceEvent テンプレート フィールドグループ を使用して、 AnalyticsXDM スキーマに固有のフィールドです。 使用しているAdobeアプリケーションに応じて、スキーマでこれらのAdobeが提供するフィールドグループを使用する必要があります。
Adobeアプリケーションフィールドグループは、 identityMap
フィールド:個々の顧客の標準 id 値をマッピングする、システム生成の読み取り専用オブジェクトです。
Adobe Analyticsの場合、ECID はデフォルトのプライマリ ID です。 ECID 値が顧客によって指定されない場合、プライマリ ID は代わりにデフォルトで AAID に設定されます。
Adobeアプリケーションフィールドグループを使用する場合、他のフィールドをプライマリ ID としてマークする必要はありません。 ID としてマークする必要がある追加のプロパティがある場合、これらのフィールドをセカンダリ ID として代わりに割り当てる必要があります。
このドキュメントでは、Experience Platformのためのデータモデルを設計する際の一般的なガイドラインとベストプラクティスを説明しました。 要約する手順は次のとおりです。
準備が整ったら、 UI でのスキーマの作成 スキーマの作成手順、エンティティに適切なクラスの割り当て、データのマッピング先のフィールドの追加手順を説明します。