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

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（プロファイル、Experience Event、参照エンティティを含む）

ビジネスの使用例を実行するのに必要な適切なデータソースの特定に関する手順は、組織によって異なります。 このドキュメントの残りの節では、データソースを特定した後に ERD を整理して構築する後の手順に焦点を当てますが、図の様々なコンポーネントの説明によって、どのデータソースに移行するかを判断できます Platform.

高レベルの ERD を作成する

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

次の例は、にデータを取り込む企業の簡易 ERD を示しています。 Platform. 次の図は、XDM クラスに分類する必要がある基本エンティティ（顧客アカウント、ホテル、住所、一般的な e コマースイベントなど）を示しています。

エンティティをプロファイル、ルックアップ、イベントカテゴリに並べ替える

ERD を作成し、に取り込む必要のあるエンティティを特定します。 Platformに値を指定しない場合、これらのエンティティはプロファイル、ルックアップ、イベントのカテゴリに分類される必要があります。

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

以下の節では、エンティティを上記のカテゴリに分類する方法について詳しく説明します。

可変データと不変データ

エンティティカテゴリ間の並べ替えの主な方法は、取り込まれるデータが可変かどうかです。

通常、プロファイルまたは参照エンティティに属する属性は可変です。 例えば、顧客の環境設定は時間の経過と共に変化し、サブスクリプションプランのパラメーターは市場の傾向に応じて更新できます。

これに対して、イベントデータは通常不変です。 イベントは特定のタイムスタンプに添付されるので、イベントが提供する「システムスナップショット」は変更されません。 例えば、イベントは、買い物かごのチェックアウト時に顧客の環境設定を取り込み、後で顧客の環境設定が変更されても変更されない場合があります。 イベントデータは記録後は変更できません。

要約すると、プロファイルと参照エンティティには可変属性が含まれ、取得する主体に関する最新の情報を表します。一方、イベントは特定の時間にシステムの不変レコードです。

顧客属性

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

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

経時的なデータの追跡

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

セグメント化の使用例

エンティティを分類する場合は、特定のビジネスユースケースに対応するために、作成するオーディエンスセグメントについて検討する必要があります。

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

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

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

セグメント化の使用例に関する考慮事項に加えて、これらのセグメントのアクティブ化の使用例を確認して、関連する属性をさらに特定する必要があります。

例えば、会社が country = US. 次に、特定のダウンストリームターゲットに対してそのセグメントをアクティブ化する際に、書き出されたすべてのプロファイルを自宅の状態に基づいてフィルタリングします。 したがって、 state 属性は、該当するプロファイルエンティティでもキャプチャする必要があります。

集計値

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

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

カーディナリティ

ERD で確立された基準は、エンティティの分類方法に関する手がかりを提供することもできます。 2 つのエンティティ間に 1 対多の関係がある場合、「多」を表すエンティティはイベントエンティティである可能性が高くなります。 ただし、「多」とは、プロファイルエンティティ内の配列として提供されるルックアップエンティティのセットのことです。

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

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

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

会社は、1 人の顧客が多数のサブスクリプションを持つことができる、顧客のアクティブなサブスクリプションを追跡します。 また、アクティブな購読を持つすべてのユーザーを検索するなど、セグメント化の使用例の購読を含めたいと考えています。

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

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

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

1 つ目のアプローチは、購読の配列を属性として顧客のプロファイルエンティティに含めることです。 この配列内のオブジェクトには、 category, status, planName, startDateおよび endDate.

長所

• セグメント化は、意図した使用例で可能です。
• スキーマは、顧客の最新のサブスクリプションレコードのみを保持します。

短所

• 配列内のフィールドが変更されるたびに、配列全体を再記述する必要があります。
• 異なるデータソースやビジネスユニットがアレイにデータを送る場合、最新の更新済みアレイをすべてのチャネルで同期し続けるのは困難になります。

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

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

長所

• セグメント化ルールは、より柔軟に設定できます（過去 30 日間に購読を変更したすべての顧客を検索するなど）。
• 顧客のサブスクリプションステータスが変更された場合、顧客のプロファイル属性内の長く複雑な可能性のあるアレイを更新する必要がなくなりました。 これは、顧客のサブスクリプションリストに対する同時変更が複数のソースから発生する場合に特に便利です。

短所

• セグメント化は、元の意図されたユースケース（顧客の最新のサブスクリプションのステータスを識別する）でより複雑になります。 セグメントのステータスを確認するために、顧客の最後のサブスクリプションイベントにフラグを設定する追加のロジックが必要になりました。
• イベントは、自動的に期限が切れ、プロファイルストアからパージされるリスクが高くなります。 詳しくは、 プロファイル TTL を参照してください。

分類されたエンティティに基づくスキーマの作成

エンティティをプロファイル、ルックアップ、イベントカテゴリに並べ替えたら、データモデルの XDM スキーマへの変換を開始できます。 デモ用に、前述の例のデータモデルは、次の図で適切なカテゴリに分類されています。

エンティティが並べ替えられたカテゴリは、スキーマの基にする XDM クラスを決定します。 繰り返し実行する手順は、次のとおりです。

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

以下の節では、ERD に基づいてスキーマを作成する際の一般的なガイダンスを示します。

反復モデリングアプローチの採用

​10. スキーマ進化のルール 実装後は、スキーマに対して非破壊的な変更のみをおこなえるように指示します。 つまり、スキーマにフィールドを追加し、そのフィールドに対してデータを取り込むと、そのフィールドは削除できなくなります。 したがって、スキーマを最初に作成するときに、反復的なモデリングアプローチを採用する必要があります。最初はシンプルな実装を使用し、時間の経過と共に徐々に複雑さを増します。

特定のフィールドをスキーマに含める必要があるかどうかが不明な場合は、除外することをお勧めします。 後でフィールドが必要と判断された場合は、常にスキーマの次の反復で追加できます。

ID フィールド

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

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

Adobeアプリケーションスキーマフィールドグループ

Experience Platformには、次のスキーマアプリケーションに関連するデータを取り込むための、あらかじめ用意されているいくつかの XDMAdobeフィールドグループが用意されています。

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

例えば、 Adobe Analytics ExperienceEvent テンプレート フィールドグループ を使用して、 AnalyticsXDM スキーマに固有のフィールド。 使用しているAdobeアプリケーションに応じて、スキーマでこれらのAdobe提供のフィールドグループを使用する必要があります。

Adobeアプリケーションフィールドグループは、 identityMap フィールド：システム生成の読み取り専用オブジェクトで、個々の顧客の標準 id 値をマッピングします。

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

次の手順

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

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

準備が整ったら、 UI でのスキーマの作成 スキーマの作成方法、エンティティに適したクラスの割り当て、データのマッピング先のフィールドの追加手順を説明します。