Adobe Experience Platformでのデータモデリングのベストプラクティス

Experience Data Model (XDM)は、下流のAdobe Experience Platformサービスで使用される共通の構造と定義を提供することで顧客体験データを標準化する中核的なフレームワークです。 XDM標準を守ることで、すべての顧客体験データを共通の表現に組み込むことができ、顧客の行動から貴重な洞察を得たり、セグメントを通じて顧客オーディエンスを定義したり、パーソナライズ目的で顧客属性を表したりできます。

XDMは非常に用途が広く、設計によってカスタマイズ可能なので、スキーマを設計する際は、データモデリングのベストプラクティスに従うことが重要です。 このドキュメントでは、顧客体験データをXDMにマッピングする際に必要な主な決定事項と考慮事項について説明します。

はじめに

このガイドを読む前に、XDMの概要 (XDMとExperience Platform内での役割の概要)を確認してください。

また、このガイドでは、スキーマデザインに関する重要な考慮事項にのみ焦点を当てます。 したがって、本ガイドで取り上げる個々のスキーマ要素の詳細については、スキーマ構成の 基本事項を参照し 、参照することを強くお勧めします。

ベストプラクティスのまとめ

Experience Platformで使用するデータモデルを設計する際に推奨されるアプローチは、次のとおりです。

1. データのビジネス使用例を把握する。
2. これらの使用例に対処するために取り込む必要がある主なデータソース Platform を特定します。
3. 関心を持つ可能性のあるセカンダリデータソースを特定します。 例えば、現在、組織内の1つの事業部門のみがそのデータのへの移植に関心を持っている場合、同様の事業部門 Platformも将来の同様のデータの移植に関心を持つ可能性があります。 これらのセカンダリソースを検討することで、組織全体でデータモデルを標準化するのに役立ちます。
4. 識別されたデータソースの高レベルエンティティ関係図(ERD)を作成します。
5. 高レベルのERDを Platform中心のERDに変換します(プロファイル、エクスペリエンスイベント、参照エンティティなど)。

ビジネス使用事例の実施に必要な該当するデータソースの特定に関する手順は、組織によって異なります。 このドキュメントの残りのセクションでは、データソースの特定後にERDを編成して構築する後の手順に重点を置いていますが、図の様々なコンポーネントの説明によって、データソースの移行先を決定できる場合があり Platformます。

高レベルERDを作成する

に取り込むデータソースを決定したら、高レベルのERDを作成し Platformて、データをXDMスキーマにマッピングするプロセスをガイドします。

次の例は、にデータを取り込む会社のシンプルなERDを示してい Platformます。 この図では、顧客アカウント、ホテル、住所、一般的なeコマースイベントを含む、XDMクラスに分類する必要のある基本的なエンティティに焦点を当てています。

エンティティをプロファイル、参照およびイベントのカテゴリに並べ替える

ERDを作成して、取り込む必要のある主要エンティティを識別したら、これらのエンティティをプロファイル、参照、イベントの各カテゴリに分類する Platform必要があります。

カテゴリ	説明
プロファイルエンティティ	プロファイルエンティティは、個人（通常は顧客）に関連する属性を表します。 このカテゴリに該当するエンティティは、クラスに基づくスキーマで表す必要があり XDM Individual Profileます。
参照エンティティ	ルックアップエンティティは、個々の人に関連付けることができるが、個々の人を識別するために直接使用することはできない概念を表します。 このカテゴリに該当するエンティティは、 カスタムクラスに基づくスキーマで表す必要があります。
イベントエンティティ	イベントエンティティは、顧客が行うことのできるアクション、システムイベント、または時間の経過とともに変化を追跡したい任意の概念に関する概念を表します。 このカテゴリに該当するエンティティは、クラスに基づくスキーマで表す必要があり XDM ExperienceEventます。

エンティティの並べ替えに関する考慮事項

以下の節では、エンティティを上記のカテゴリに分類する方法に関する詳細な手順を説明します。

顧客属性

エンティティに個々の顧客に関連する属性が含まれている場合、そのエンティティはプロファイルエンティティである可能性が高くなります。 顧客属性の例を次に示します。

• 名前、生年月日、性別、アカウントIDなどの個人情報。
• 住所やGPS情報などの位置情報。
• 電話番号や電子メールアドレスなどの連絡先情報。

経時的なデータの追跡

エンティティ内の特定の属性が時間の経過と共にどのように変化するかを分析する場合、イベントエンティティである可能性が最も高くなります。 例えば、商品を買い物かごに追加する場合は、次の場所で買い物かごに追加するイベントとして追跡でき Platformます。

顧客 ID	タイプ	製品ID	数量	タイムスタンプ
1234567	Add	275098	2	10月1日10:32 AM
1234567	削除	275098	1	10月1日10:33 AM
1234567	Add	486502	1	10月1日10:41 AM
1234567	Add	910482	5	10月3日2:15 PM

セグメントの使用例

エンティティを分類する際は、貴社の特定のビジネス用途に対応するために構築したいオーディエンスセグメントについて考えることが重要です。

例えば、ある会社は、忠誠度の高いプログラムで昨年5回以上買い物をした「ゴールド」や「プラチナ」のメンバー全員を知りたいと考えています。 このセグメントロジックに基づいて、関連エンティティの表現方法に関して、次の結論を下すことができます。

• 「ゴールド」と「プラチナ」は、個々の顧客に適用される忠誠度のステータスを表します。 セグメントロジックは、顧客の現在の忠誠度のステータスにのみ関係するので、このデータはプロファイルスキーマの一部としてモデル化できます。 忠誠度ステータスの変化を経時的に追跡する場合は、忠誠度ステータスの変化に対して追加のイベントスキーマを作成することもできます。
• 購入とは、特定の時間に発生するイベントのことで、セグメントロジックは、指定された時間枠内の購入イベントに関係します。 したがって、このデータはイベントスキーマとしてモデル化する必要があります。

アクティベーションの使用例

セグメントの使用例に関する考慮事項に加えて、関連するその他の属性を識別するために、これらのセグメントのアクティベーションの使用例も確認する必要があります。

例えば、ある会社が、そのルールに基づいてオーディエンスセグメントを作成したとし country = USます。 次に、そのセグメントを特定の下流ターゲットに対してアクティブ化する場合、会社は、ホーム状態に基づいて、書き出されたすべてのプロファイルをフィルタリングする必要があります。 したがって、 state 属性は、該当するプロファイルエンティティでも取り込む必要があります。

集計された値

データの使用事例と精度に基づいて、プロファイルまたはイベントエンティティに含める前に特定の値を事前に集計する必要があるかどうかを判断する必要があります。

例えば、会社が買い物かごの購入数に基づいてセグメントを作成したいとします。 各タイムスタンプ付き購入イベントを独自のエンティティとして含めることで、最も低い精度でこのデータを組み込むことを選択できます。 ただし、これにより、記録イベントの数が指数関数的に増加する場合があります。 取り込むイベントの数を減らすために、1週間または1ヶ月の間に集計値 numberOfPurchases を作成するように選択できます。 MINやMAXなどの他の集計関数も、このような状況に当てはまります。

基数

ERDで確立された基数は、エンティティの分類方法に関するヒントを提供することもできます。 2つのエンティティ間に1対多の関係がある場合、「多」を表すエンティティは、おそらくイベントのエンティティです。 ただし、「多」とは、プロファイルエンティティ内の配列として提供される参照エンティティのセットである場合もあります。

次の表に、一般的なエンティティの関係と、それらから派生できるカテゴリの概要を示します。

Relationship	基数	エンティティカテゴリ
顧客と買い物かごのチェックアウト	1対多	1人の顧客に多数の買い物かごのチェックアウトがある場合もあります。これは時間の経過とともに追跡できるイベントです。 したがって、顧客はプロファイルのエンティティになり、買い物かごのチェックアウトはイベントのエンティティになります。
顧客と忠誠度アカウント	1対1	1人の顧客に1つの忠誠度アカウントしか割り当てられない場合と、その逆の場合です。 この関係は1対1なので、顧客と忠誠度のアカウントの両方がプロファイルエンティティを表します。
顧客と購読	1対多	1人の顧客には多くの購読が存在する場合があります。 会社は、顧客の現在の購読にのみ関わるので、顧客はプロファイルエンティティで、購読は参照エンティティです。

異なるエンティティクラスの長所と短所

前の節では、エンティティの分類方法を決定する一般的なガイドラインをいくつか示しましたが、エンティティのカテゴリを別のエンティティよりも選択する場合、長所や短所が多いことを理解することが重要です。 以下のケーススタディでは、このような状況で、どのようにオプションを考慮するかを説明します。

会社は、1人の顧客が多数の購読を持つことのできる、顧客のアクティブな購読を追跡します。 また、会社は、アクティブな購読を持つすべてのユーザーを検索するなど、分類の使用例に関する購読を含めたいと考えています。

このシナリオでは、会社のデータモデルに顧客の購読を表す2つの選択肢が考えられます。

1. プロファイル属性の使用
2. イベントエンティティの使用

アプローチ1:プロファイル属性の使用

第1のアプローチは、一連の購読をCustomersのプロファイルエンティティ内に属性として含めることです。 この配列内のオブジェクトには、 category、、、、、およびのフィールドが含まれ statusま planName startDate endDateす。

長所

• 意図した使用事例に対してセグメント化を実行できます。
• スキーマは、顧客の最新の購読レコードのみを保持します。

短所

• アレイ内のフィールドが変更されるたびに、アレイ全体を再記述する必要があります。
• 異なるデータソースや事業部門がアレイにデータを送り込む場合、最新のアレイをすべてのチャネルで同期し続けるのは困難です。

アプローチ2:イベントエンティティの使用

2つ目のアプローチは、購読を表すためにイベントスキーマを使用することです。 最初のアプローチと同じ購読フィールドに加え、購読ID、顧客ID、購読イベントが発生した日時のタイムスタンプを追加します。

長所

• セグメントルールは、より柔軟に設定できます(例えば、過去30日間に購読を変更したすべての顧客を探す場合など)。
• お客様の購読・ステータスが変更された場合、お客様のプロファイル属性内の複雑で長いアレイを更新する必要はなくなりました。 これは、お客様の購読リストに対する同時変更が複数のソースから発生している場合に特に便利です。

短所

• セグメント化は、元の使用例に対してより複雑になります(顧客の最新購読のステータスを特定する)。 セグメントのステータスを確認するために、顧客の最後の購読イベントにフラグを付ける追加のロジックが必要になりました。

分類されたエンティティに基づいてスキーマを作成する

エンティティをプロファイル、参照、イベントのカテゴリにソートしたら、データモデルをXDMスキーマに開始変換できます。 前述の例のデータモデルは、デモ目的で、次の図で適切なカテゴリに分類されています。

エンティティのソートが行われたカテゴリによって、スキーマの基となるXDMクラスが決まります。 繰り返すには：

• プロファイルエンティティでは、 XDM Individual Profile クラスを使用する必要があります。
• イベントエンティティでは、 XDM ExperienceEvent クラスを使用する必要があります。
• ルックアップエンティティでは、組織で定義されたカスタムXDMクラスを使用する必要があります。

以下のセクションでは、ERDに基づくスキーマの構築に関する一般的なガイダンスを示します。

反復的なモデリングアプローチを採用

スキーマ進化の 規則は 、スキーマが実装された後は、非破壊的な変更のみが行えることを示しています。 つまり、スキーマにフィールドを追加し、そのフィールドに対してデータを取り込むと、そのフィールドを削除できなくなります。 したがって、スキーマを最初に作成する場合は、インタラクティブなモデリングアプローチを採用する必要があります。最初は、時間の経過と共に段階的に複雑になるシンプルな実装から始めます。

特定のフィールドをスキーマに含める必要があるかどうかが不明な場合は、そのフィールドを省略することをお勧めします。 後でこのフィールドが必要と判断された場合は、スキーマの次のイテレーションでそのフィールドを追加できます。

IDフィールド

Experience Platformでは、IDとしてマークされたXDMフィールドは、複数のデータソースから来た個々の顧客に関する情報を結合するために使用されます。 スキーマは、IDとしてマークされた複数のフィールドを持つことができますが、でスキーマを使用するには、1つのプライマリIDを定義する必要があり Real-time Customer Profileます。 これらのフィールドの使用例について詳しくは、 スキーマ構成の基本原則の「 IDフィールド」の節を参照してください。

スキーマを設計する際、リレーショナル・データベース表の主キーは、主IDの候補と見なされる場合があります。 該当するIDフィールドのその他の例としては、顧客の電子メールアドレス、電話番号、アカウントID、 ECIDなどがあります。

Adobeアプリケーションミックスイン

Experience Platformは、次のAdobeアプリケーションに関連するデータを取り込むための、標準搭載されたXDMミックスインをいくつか提供しています。

• Adobe Analytics
• Adobe Audience Manager
• Adobe Campaign
• Adobe Target

例えば、 Adobe AnalyticsExperienceEventテンプレートMixinを使用すると 、 Analytics特定のフィールドをXDMスキーマにマッピングできます。 使用しているAdobeアプリケーションに応じて、スキーマでこれらのAdobe提供ミックスインを使用する必要があります。

Adobeアプリケーションミックスインは、 identityMap フィールドを使用して、デフォルトのプライマリIDを自動的に割り当てます。このフィールドは、個々の顧客の標準ID値をマップする、システム生成の読み取り専用オブジェクトです。

Adobe Analyticsの場合、ECIDはデフォルトのプライマリIDです。 ECID値が顧客によって提供されない場合、プライマリIDはデフォルトでAIDに設定されます。

次の手順

このドキュメントでは、Experience Platform用のデータモデルを設計する際の一般的なガイドラインとベストプラクティスについて説明します。 まとめると、

• スキーマを作成する前に、データテーブルをプロファイル、参照およびイベントのカテゴリに並べ替えて、トップダウンアプローチを使用します。
• 様々な目的でスキーマをデザインする場合、多くの場合、複数の方法とオプションがあります。
• データモデルは、分類やカスタマージャーニー分析などのビジネスの使用例をサポートする必要があります。
• スキーマをできるだけ簡単にし、必要に応じて新しいフィールドを追加します。

準備が整ったら、UIでのスキーマの 作成に関するチュートリアルを参照し、スキーマの作成方法、エンティティに適切なクラスの割り当て、データのマッピング先のフィールドの追加手順を確認してください。