データモデリングのベストプラクティス
Experience Data Model（XDM）は、ダウンストリーム Adobe Experience Platform サービスで使用する共通の構造と定義を提供することで、顧客体験データを標準化するコアフレームワークです。 XDM標準を順守することで、あらゆる顧客体験データを共通の表現に組み込み、顧客の行動から貴重なインサイトを得たり、顧客オーディエンスを定義したり、パーソナライゼーションのために顧客属性を表現したりするために利用することができます。
XDMは非常に汎用性が高く、設計によってカスタマイズ可能であるため、スキーマを設計する際には、データモデリングのベストプラクティスに従うことが重要です。 このドキュメントでは、顧客体験データをXDMにマッピングする際に行う必要がある主な意思決定と考慮事項について説明します。
はじめに
このガイドを読む前に、XDM システムの概要で、XDMの概要とExperience Platform内での役割を確認してください。
このガイドでは、スキーマ設計に関する重要な考慮事項のみに焦点を当てているため、このガイド全体で言及されている個々のスキーマ要素の詳細な説明については、 スキーマ構成の基本を参照することを強くお勧めします。
ベストプラクティスのまとめ summary
Experience Platform で使用するデータモデルを設計するための推奨されるアプローチは、次のように要約できます。
- データのビジネスユースケースを理解します。
- これらのユースケースに対処するために、Experience Platformに取り込む必要がある主要なデータソースを特定します。
- 興味の対象となる可能性のあるセカンダリデータソースを特定します。 たとえば、現在、組織内のひとつの事業部門のみがデータをExperience Platformに移植することに関心がある場合、類似の事業部門も将来的に同様のデータを移植することに関心を持つ可能性があります。 これらのセカンダリソースを考慮すると、組織全体でデータモデルを標準化するのに役立ちます。
- 識別されたデータソースの高レベルのエンティティ関係図（ERD）を作成します。
- 高レベル ERDをExperience Platform中心のERD （プロファイル、エクスペリエンスイベント、ルックアップエンティティを含む）に変換します。
ビジネスのユースケースを実行するために必要な該当するデータソースを特定する手順は、組織によって異なります。 このドキュメントの残りのセクションでは、データソースを特定した後にERDを整理および作成する後の手順に焦点を当てていますが、図の様々なコンポーネントの説明は、どのデータソースをExperience Platformに移行する必要があるかについての意思決定に役立つ可能性があります。
高レベル ERD の作成 create-an-erd
Experience Platformに取り込むデータソースを決定したら、データをXDM スキーマにマッピングするプロセスをガイドする上位レベルのERDを作成します。
以下の例は、Experience Platformにデータを取り込む企業の簡略化されたERDを表しています。 この図では、顧客アカウント、ホテル、いくつかの一般的なe コマースイベントなど、XDM クラスに分類すべき重要なエンティティを示しています。
プロファイル、ルックアップ、イベントのカテゴリへのエンティティの並べ替え sort-entities
Experience Platformに取り込む必要なエンティティを特定するERDを作成したら、これらのエンティティをプロファイル、ルックアップ、イベントカテゴリに並べ替える必要があります。
エンティティの並べ替えに関する考慮事項 considerations
以下の節では、上記のカテゴリにエンティティを並べ替える方法について詳しく説明します。
可変データと不変データ mutable-and-immutable-data
エンティティカテゴリ間で並べ替える主な方法は、キャプチャされるデータが可変かどうかです。
プロファイルまたはルックアップエンティティに属する属性は、通常、可変です。 例えば、顧客の好みは時間の経過に伴い変化する可能性があり、サブスクリプションプランのパラメーターは市場のトレンドに応じて更新される可能性があります。
これに対し、イベントデータは通常不変です。 イベントは特定のタイムスタンプに添付されるので、イベントが提供する「システムスナップショット」は変更されません。 例えば、イベントは、買い物かごのチェックアウト時に顧客の好みを把握でき、顧客の好みが後で変化しても変更されません。 イベントデータは、記録した後に変更することはできません。
要約すると、プロファイルとルックアップエンティティは可変属性を含んでおり、取得したサブジェクトに関する最新の情報を表しています。一方、イベントは特定の時点でのシステムの不変レコードです。
顧客属性 customer-attributes
エンティティに個々の顧客に関連する属性が含まれている場合、それはプロファイルエンティティである可能性が最も高くなります。 顧客属性の例を次に示します。
- 個人の詳細（氏名、生年月日、性別、アカウント ID など）。
- 位置情報（住所や GPS 情報など）。
- 連絡先情報（電話番号やメールアドレスなど）。
時系列データの追跡 track-data
エンティティ内の特定の属性が時間的にどのように変化するかを分析する場合、エンティティはイベントエンティティである可能性が高いでしょう。 例えば、商品アイテムをカートに追加すると、Experience Platformでカートに追加イベントとして追跡できます。
セグメント化のユースケース segmentation-use-cases
エンティティを分類する場合は、特定のビジネスユースケースに対処するために、作成対象のオーディエンスについて検討することが重要です。
例えば、昨年 6 回以上購入したロイヤルティプログラムの「ゴールド」メンバーまたは「プラチナ」メンバー全員を企業が把握したいとします。 このセグメントのロジックに基づいて、関連するエンティティの表現方法に関して、次の結論を下すことができます。
- 「ゴールド」と「プラチナ」は、個々の顧客に適用されるロイヤルティステータスを表します。 セグメントのロジックは顧客の現在のロイヤルティステータスにのみ関係するので、このデータをプロファイルスキーマの一部としてモデル化できます。 ロイヤルティステータスの時間的変化を追跡する場合は、ロイヤルティステータスの変化に関する追加のイベントスキーマを作成することもできます。
- 購入は特定の時刻に発生するイベントで、セグメント化ロジックは指定した時間枠内の購入イベントに関係します。 したがって、このデータはイベントスキーマとしてモデル化する必要があります。
アクティブ化のユースケース activation-use-cases
セグメンテーションのユースケースに関する考慮事項に加えて、これらのオーディエンスのアクティベーションのユースケースを確認して、関連する追加の属性を特定する必要があります。
例えば、country = US というルールに基づいて、企業がオーディエンスを作成したとします。 次に、そのオーディエンスを特定のダウンストリームターゲットに対してアクティベートする際に、企業は、書き出されたすべてのプロファイルを居住地に基づいてフィルタリングしようとします。 したがって、該当するプロファイルエンティティに state 属性も取り込む必要があります。
集計値 aggregated-values
データのユースケースと精度に基づいて、プロファイルまたはイベントエンティティに含める前に、特定の値を事前に集計する必要があるかどうかを判断してください。
例えば、企業が買い物かごの商品購入数に基づいてオーディエンスを作成するとします。 タイムスタンプ付きの各購入イベントを独自のエンティティとして含めることで、最も低い精度でこのデータを取り込むことができます。 ただし、これにより、記録されるイベントの数が急激に増える可能性があります。 取り込むイベントの数を減らすには、1週間または1か月の期間にわたって集計値numberOfPurchasesを作成するように選択できます。 このような状況には、MIN や MAX などの他の集計関数も適用できます。
基数 cardinality
ERD で確立された基数は、エンティティの分類方法に関するヒントも提供してくれます。 2つのエンティティ間に1対多の関係がある場合、「many」を表すエンティティはイベントエンティティである可能性が高くなります。 ただし、「多」側が、プロファイルエンティティ内の配列として提供される一連のルックアップエンティティである場合もあります。
エンティティの一般的な関係と、それらから導き出せるカテゴリの概要を次の表に示します。
様々なエンティティクラスの長所と短所 pros-and-cons
前の節では、エンティティを分類する方法を決定するための一般的なガイドラインをいくつか示しましたが、一方のエンティティカテゴリより他方を選ぶ場合はメリットとデメリットがあることが多いということを理解しておくことが重要です。 ここでは、以下のユーザー事例を取り上げ、このような状況でオプションをどのように検討するかを説明します。
ある企業が、1 人の顧客が多数のサブスクリプションを持てる状況で、顧客向けのアクティブなサブスクリプションを追跡しているとします。 また、同社は、アクティブなサブスクリプションを利用しているすべてのユーザーを検索するなど、セグメント化のユースケースにサブスクリプションを含めることも望んでいます。
このシナリオでは、同社には、顧客のサブスクリプションをデータモデルで表すために取り得る選択肢が 2 つあります。
アプローチ 1：プロファイル属性の使用 profile-approach
最初のアプローチは、顧客のプロファイルエンティティ内にsubscriptionIDの配列を含めることです。
長所
- セグメント化が、意図したユースケースに適しています。
- スキーマは、顧客の最新のサブスクリプションレコードのみを保持します。
短所
- 配列内のフィールドが変更されるたびに、配列全体を再記述する必要があります。
- 異なるデータソースや事業部門がアレイにデータを入力している場合、最新のアレイをすべてのチャネルで同期しておくことは困難になります。
アプローチ 2：イベントエンティティの使用 event-approach
2つ目のアプローチは、イベントスキーマを使用してサブスクリプションイベントを表すことです。 これには、サブスクリプション IDと、サブスクリプションイベントが発生した際の顧客IDおよびタイムスタンプが含まれます。
長所
- セグメント化ルールは、より柔軟に設定できます（過去 30 日間にサブスクリプションを変更したすべての顧客を検索するなど）。
- 顧客のサブスクリプションステータスが変更された場合、顧客のプロファイル属性内の長くて複雑になる可能性のある配列を更新する必要がなくなりました。 これは、複数のソースから顧客のサブスクリプションリストが同時に変更されている場合に特に便利です。
短所
- 最初に意図したユースケース（顧客の最新のサブスクリプションのステータスを識別する）では、セグメント化がより複雑になります。 オーディエンスは、顧客の最後のサブスクリプションイベントにフラグを付けて、そのステータスを確認するための追加のロジックを必要とします。
- イベントは、自動的に有効期限切れになり、プロファイルストアから消去されるリスクが高くなります。 詳しくは、エクスペリエンスイベントの有効期限に関するガイドを参照してください。
分類されたエンティティに基づいてスキーマを作成する schemas-for-categorized-entities
エンティティをプロファイル、ルックアップ、イベントのカテゴリに並べ替えたら、データモデルを XDM スキーマへの変換を開始できます。 次の図では、デモンストレーションの目的で、前に示したデータモデルの例を適切なカテゴリに並べ替えています。
エンティティが並べ替えられたカテゴリによって、そのスキーマのベースとなる XDM クラスが決定されます。 繰り返し実行する手順は、次のとおりです。
- プロファイルエンティティには、XDM Individual Profile クラスを使用する必要があります。
- イベントエンティティには、XDM ExperienceEvent クラスを使用する必要があります。
- ルックアップエンティティには、組織で定義したカスタム XDM クラスを使用する必要があります。 その後、プロファイルおよびイベントのエンティティでは、スキーマ関係を通じて、これらのルックアップエンティティを参照できます。
LoyaltyAccount オブジェクトも含めることができます。 ただし、関係が 1 対多の場合、「多」の側のエンティティは、その複雑さに応じて、別のスキーマまたはプロファイル属性の配列で表すことができます。以下の節では、ERD に基づいてスキーマを構築するための一般的なガイダンスを示します。
反復モデリングアプローチの採用 iterative-modeling
スキーマ進化のルールでは、スキーマが実装された後は、非破壊的な変更のみをスキーマに加えることができると規定されています。 つまり、スキーマにフィールドを追加し、そのフィールドに対してデータが取り込まれると、そのフィールドは削除できなくなります。 したがって、最初にスキーマを作成するときは、単純化された実装から始めて、時間の経過と共に徐々に複雑になる、反復モデリングアプローチを採用することが不可欠です。
特定のフィールドをスキーマに含める必要があるかどうかわからない場合は、除外することをお勧めします。 後でフィールドが必要であると判断した場合は、スキーマの次の反復でいつでも追加できます。
ID フィールド identity-fields
Experience Platform では、ID としてマークされた XDM フィールドを使用して、複数のデータソースからの個々の顧客に関する情報を結合します。 スキーマにはIDとしてマークされた複数のフィールドを含めることができますが、Real-Time Customer Profileでスキーマを使用できるようにするには、1つのプライマリ IDを定義する必要があります。 これらのフィールドのユースケースについて詳しくは、スキーマ構成の基本の ID フィールドに関する節を参照してください。
スキーマを設計する場合、リレーショナルデータベーステーブル内のプライマリキーは、プライマリ IDの候補となる可能性があります。 該当する ID フィールドの他の例としては、顧客の電子メールアドレス、電話番号、アカウント ID、ECID などがあります。
Adobeアプリケーションスキーマフィールドグループ adobe-application-schema-field-groups
Experience Platform には、次のアドビアプリケーションに関連するデータを取得するための、すぐに使用できる XDM スキーマフィールドグループがいくつか用意されています。
- Adobe Analytics
- Adobe Audience Manager
- Adobe Campaign
- Adobe Target
例えば、Adobe Analytics ExperienceEvent Template フィールドグループ を使用して、Analytics固有のフィールドをXDM スキーマにマッピングできます。 使用しているアドビアプリケーションに応じて、これらのアドビが提供するフィールドグループをスキーマで使用する必要があります。
アドビアプリケーションフィールドグループは、identityMap フィールドを使用してデフォルトのプライマリ ID を自動的に割り当てます。このフィールドは、個々の顧客の標準 ID 値をマッピングする、システム生成の読み取り専用オブジェクトです。
Adobe Analytics の場合、ECID はデフォルトのプライマリ ID です。 ECID値が顧客によって提供されない場合、プライマリ IDは代わりにAAIDにデフォルト設定されます。
データ検証フィールド data-validation-fields
データをデータレイクに取り込む場合、データ検証は制約のあるフィールドにのみ適用されます。 バッチ取り込み中に特定のフィールドを検証するには、XDM スキーマでフィールドを制約としてマークする必要があります。 Experience Platformに不正なデータが入力されないようにするには、スキーマを作成するときに検証要件を定義します。
フィールドに制約を設定するには、スキーマエディターでフィールドを選択して、Field properties サイドバーを開きます。 使用可能なフィールドの正確な説明については、 タイプ固有のフィールドプロパティ に関するドキュメントを参照してください。
データの整合性を維持するためのヒント data-integrity-tips
次の提案は、スキーマを作成する際にデータの整合性を維持するのに役立ちます。
- プライマリ IDを検討: web SDK、モバイル SDK、Adobe Analytics、Adobe Journey OptimizerなどのAdobe製品の場合、
identityMapフィールドがプライマリ IDとして機能することがよくあります。 そのスキーマのプライマリ IDとして追加のフィールドを指定することは避けてください。 _idがIDとして使用されていないことを確認してください: Experience Event スキーマの_idフィールドは、レコードの一意性を目的としているため、IDとして使用できません。- 長さの制約を設定:IDとしてマークされたフィールドの最小長と最大長を設定することをお勧めします。 カスタム名前空間をID フィールドに割り当てようとすると、最小および最大の長さの制約を満たさずに警告トリガーが表示されます。 こうした制限により、一貫性とデータ品質を維持できます。
- 一貫した値にパターンを適用する: ID値が特定のパターンに従う場合は、Pattern設定を使用して制約を適用します。 この設定には、数字のみ、大文字または小文字、または特定の文字の組み合わせなどのルールを含めることができます。 正規表現を使用して、文字列内のパターンを一致させます。
- Analytics スキーマのeVarを制限：通常、Analytics スキーマには、IDとして指定されたeVarを1つだけ含める必要があります。 複数のeVarをIDとして使用する場合は、データ構造を最適化できるかどうかを再確認する必要があります。
- 選択したフィールドの一意性を確認：選択したフィールドは、スキーマ内のプライマリ IDと一意である必要があります。 そうでない場合は、IDとしてマークしないでください。 例えば、複数の顧客が同じメールアドレスを提供できる場合、その名前空間は適切なIDではありません。 この原則は、電話番号などの他のID名前空間にも適用されます。 一意でないフィールドをIDとしてマークすると、不要なプロファイルの折りたたみが発生する可能性があります。
- 文字列長の最小値を確認：文字列値は空にしないため、すべての文字列フィールドの長さは1文字以上にする必要があります。 ただし、必須フィールド以外のフィールドのNull値は使用できます。 新しい文字列フィールドには、デフォルトで最小長1が指定されます。
プロファイル対応スキーマの管理 managing-profile-enabled-schemas
この節では、リアルタイム顧客プロファイルに対して既に有効になっているスキーマを管理する方法について説明します。 スキーマを有効にした後、そのスキーマを無効にしたり削除したりすることはできません。 これ以上使用されないようにする方法と、削除できないデータセットを管理する方法を決定する必要があります。
プロファイルに対してスキーマを有効にすると、設定を元に戻すことはできません。 スキーマを使用しなくなった場合は、スキーマの名前を変更してステータスを明確にし、正しい構造とID設定を使用して置換スキーマを作成します。 これにより、ユーザーが新しいデータセットを作成したり、取り込みワークフローを設定したりする際に、非推奨のスキーマを誤って再利用するのを防ぐことができます。
システムデータセットが、リアルタイム顧客プロファイル対応のスキーマとともに表示されることがあります。 関連するスキーマが非推奨（廃止予定）の場合でも、システムデータセットを削除することはできません。 意図しない使用を防ぐには、非推奨のプロファイル対応スキーマの名前を変更し、取り込みワークフローが残っているシステムデータセットを指していないことを確認します。
非推奨のプロファイル対応スキーマの誤った再利用を防ぐには、次のベストプラクティスを使用します。
- スキーマを非推奨（廃止予定）にする場合は、明確な命名規則を使用します。 「非推奨」、「使用しない」、またはバージョンタグなどのラベルを含めます。
- 廃止したいスキーマにもとづいて、データセットにデータを取り込むのを停止します。
- 正しい構造、ID設定、命名パターンを使用して、新しいスキーマを作成します。
- 削除できないシステムデータセットを確認し、取り込みワークフローが参照していないことを確認します。
- スキーマが非推奨になる理由を他のユーザーが理解できるように、内部で変更を文書化します。
次の手順
このドキュメントでは、Experience Platformのデータモデルを設計するための一般的なガイドラインとベストプラクティスについて説明します。 以下に要約を示します。
- スキーマを作成する前に、データテーブルをプロファイル、ルックアップ、イベントカテゴリに並べ替えます。
- 異なるユースケースのスキーマを設計する際に、複数のアプローチを評価します。
- データモデルがセグメンテーションやカスタマージャーニーの目標をサポートしていることを確認しましょう。
- スキーマはできるだけシンプルにする： 必要な場合にのみ新しいフィールドを追加します。
準備ができたら、UIでのスキーマの作成に関するチュートリアルを参照して、スキーマの作成、クラスの割り当て、フィールドマッピングに関する手順を説明します。