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

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を作成する

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

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

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

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

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

以下の節では、エンティティを上記のカテゴリに分類する方法に関する詳細なガイダンスを示します。

顧客属性

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

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

経時的なデータの追跡

エンティティ内の特定の属性が時間の経過と共にどのように変化するかを分析する場合、おそらくイベントエンティティです。 例えば、買い物かごへの製品項目の追加は、Platformでの買い物かごへの追加イベントとして追跡できます。

セグメント化の使用例

エンティティを分類する際は、特定のビジネスユースケースに対処するために構築したいオーディエンスセグメントについて検討することが重要です。

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

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

Activationの使用例

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

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

集計値

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

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

カーディナリティ

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

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

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

前の節では、エンティティの分類方法を決定するための一般的なガイドラインをいくつか示しましたが、1つのエンティティカテゴリを別のエンティティのカテゴリに置き換える場合に長所と短所が生じる場合が多いことを理解することが重要です。 次のケーススタディでは、このような状況での選択肢の検討方法を説明します。

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

このシナリオでは、データモデルで顧客のサブスクリプションを表す2つの選択肢が考えられます。

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

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

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

長所

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

短所

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

アプローチ2:イベントエンティティを使用します。

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

長所

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

短所

• セグメント化は、元の意図されたユースケースでより複雑になります（顧客の最新のサブスクリプションのステータスを識別）。 セグメントのステータスを確認するために、顧客の最後のサブスクリプションイベントにフラグを設定する追加のロジックが必要になりました。

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

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

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

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

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

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

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

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

IDフィールド

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

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

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

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

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

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

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

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

次の手順

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

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

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