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