スキーマ構成の基本

Experience Data Model （XDM）スキーマと、Adobe Experience Platformでスキーマを作成するための構成要素、原則、ベストプラクティスについて説明します。 XDMの概要とExperience Platformでの使用方法については、XDM System overviewを参照してください。

スキーマ understanding-schemas

スキーマは、データの構造と形式を表し、検証する一連のルールです。 スキーマは、高いレベルで、実世界のオブジェクト（人など）の抽象的な定義を提供し、そのオブジェクトの各インスタンスに含めるデータ（名、姓、誕生日など）の概要を示します。

スキーマは、データの構造を説明するだけでなく、制約や期待をデータに適用し、システム間の移動時に検証できるようにします。 これらの標準的な定義により、接触チャネルに関係なくデータを一貫して解釈でき、アプリケーション間での翻訳の必要性を排除できます。

Experience Platformでは、スキーマを使用してこのセマンティック正規化を維持します。 スキーマは Experience Platform での標準的なデータ記述方法で、スキーマに適合するすべてのデータを組織間で競合なく再利用可能にし、さらに複数の組織間で共有できるようになります。

XDM スキーマは、自己完結型の形式で膨大な量の複雑なデータを保存するのに適しています。 XDMがこれを実現する方法について詳しくは、このドキュメントの付録の埋め込みオブジェクト ​および​ ビッグデータ ​の節を参照してください。

Experience Platform でのスキーマベースのワークフロー schema-based-workflows

標準化は、Experience Platform の背後にある主要な概念です。 アドビが推進する XDM は、顧客エクスペリエンスデータを標準化し、顧客エクスペリエンス管理の標準スキーマを定義する取り組みです。

Experience Platformが構築されるインフラストラクチャ（XDM System）は、スキーマベースのワークフローを促進し、Schema Registry、Schema Editor、スキーマメタデータ、およびサービス利用パターンを含みます。 詳しくは、「XDM システムの概要」を参照してください。

Experience Platformでスキーマを使用する主な利点はいくつかあります。 まず、スキーマにより、データガバナンスとデータの最小化を改善できます。これは、プライバシー規制で特に重要です。 次に、Adobeの標準コンポーネントを使用してスキーマを構築することで、すぐに使えるインサイトを獲得し、最小限のカスタマイズでAI/マシンラーニングサービスを利用できます。 最後に、スキーマはデータ共有のインサイトと効率的なオーケストレーションのためのインフラストラクチャを提供します。

スキーマの計画 planning

スキーマを構築する最初の手順は、スキーマ内で捕捉しようとする概念、すなわち現実世界のオブジェクトを決定することです。 記述しようとしている概念を特定したら、データの種類、潜在的なID フィールド、スキーマの今後の発展などを考慮して、スキーマの計画を開始します。

Experience Platform でのデータ動作 data-behaviors

Experience Platform での使用を意図したデータの動作タイプは、次の 2 つに分類されます。

すべての XDM スキーマは、レコードまたは時系列として分類できるデータを記述します。 スキーマのデータ動作は、スキーマのクラスによって定義され、スキーマの作成時に割り当てられます。

レコードと時系列の両方のスキーマには、ID のマップ（xdm:identityMap）が含まれます。 このフィールドには、次の節で説明する「ID」とマークされたフィールドから作成された、主体の ID 表現が含まれます。

Identity identity

スキーマは、Experience Platformに取り込むデータの構造を定義します。 このデータは、Adobe Experience Platform内の複数のサービスを強化し、各個人を単一の統合された顧客像を構築するのに役立ちます。 スキーマを設計する際は、IDとしてマークするフィールドを慎重に検討します。これらのフィールドは、データセットをまたいでプロファイルをつなぎ合わせる方法を制御します。

このプロセスを支援するために、スキーマ内のキーフィールドをIDとしてマークすることができます。 データの取り込み時に、それらのフィールド内のデータがその個人の「Identity Graph」に挿入されます。 その後、グラフデータにReal-Time Customer Profileおよびその他のExperience Platform サービスからアクセスして、個々のお客様の結合されたビューを提供できます。

「Identity」として一般的にマークされるフィールドには、電子メールアドレス、電話番号、Experience Cloud ID (ECID)、CRM ID、またはその他の一意のID フィールドが含まれます。 組織に固有の一意のIDを検討します。これは、「Identity」フィールドでも適切な場合があります。

ID情報がデジタルエクスペリエンスを顧客に提供するのにどのように役立つかを詳しくは、ID サービスの概要を参照してください。 スキーマを作成する際のIDの使用に関する​ ヒント ​については、データモデリングのベストプラクティス ドキュメントを参照してください。

Experience PlatformにID データを送信するには、次の2つの方法があります。

identityMap identityMap

identityMapは、個人の様々なID値と関連する名前空間を説明するマップ タイプ フィールドです。 このフィールドは、スキーマ自体の構造内でID値を定義するのではなく、スキーマのID情報を提供するために使用できます。

identityMapを使用する主な欠点は、ID値がネストされており、セグメントビルダーや一部のサードパーティ統合など、トップレベルのID フィールドを期待するツールでは操作が困難な場合があることです。

ただし、ID マップは、スキーマのIDの数が可変である場合や、IDを格納するソース（AirshipやAdobe Audience Managerなど）からデータを取り込む場合に便利です。 また、Experience Platform モバイル SDKを使用している場合は、ID マップが必要です。

シンプルなID マップの例を次に示します。

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": true
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "CRMID": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": false
    }
  ]
}

上記の例が示すように、identityMap オブジェクトの各キーはID名前空間を表します。 各キーの値はオブジェクトの配列で、それぞれの名前空間のID値（id）を表します。 Adobe アプリケーションで認識される標準ID名前空間🔗の リストについては、Identity Service ドキュメントを参照してください。

スキーマ進化の原則 evolution

デジタルエクスペリエンスの本質が進化し続けるにつれ、デジタルエクスペリエンスを表すスキーマが必要になります。 したがって、適切に設計されたスキーマは、必要に応じて適応し、進化し、以前のバージョンのスキーマに破壊的な変更を加えることなく使用できます。

後方互換性を維持することはスキーマの進化にとって重要であるため、Experience Platformでは純粋に加法的なバージョン管理の原則が適用されます。 この原則により、スキーマに対する変更は、非破壊的な更新と変更のみを引き起こします。 つまり、後方互換性を壊すような変更​はサポートされません。

次の表は、スキーマ、フィールドグループ、データタイプの編集時にサポートされる変更を示しています。

*​新しい必須フィールドの設定に関する重要な考慮事項については、以下の節を参照してください。

必須フィールド

個々のスキーマフィールドは必須としてマークできます。つまり、取り込まれたレコードには、検証を渡すために、それらのフィールドにデータが含まれている必要があります。 例えば、スキーマのプライマリ ID フィールドを必要に応じて設定すると、取り込まれたすべてのレコードがリアルタイム顧客プロファイルに参加するようになります。 同様に、必要に応じてタイムスタンプフィールドを設定すると、すべての時系列イベントが時系列的に保持されます。

取り込み後に必要に応じてフィールドを設定 post-ingestion-required-fields

フィールドがデータの取り込みに使用されていて、最初に必須として設定されていない場合、そのフィールドには一部のレコードに対してnull値が設定されている場合があります。 このフィールドを取り込み後に必須として設定する場合、履歴レコードがnullの場合でも、今後のすべてのレコードにこのフィールドの値を含める必要があります。

以前にオプションのフィールドを必要に応じて設定する場合は、次の点に注意してください。

スキーマとデータの取得

データを Experience Platform で取得するには、まずデータセットを作成する必要があります。 データセットは、Catalog Serviceのデータ変換とトラッキングの構成要素であり、一般的には、取り込まれたデータを含むテーブルまたはファイルを表します。 すべてのデータセットは既存の XDM スキーマに基づいており、取得するデータの内容と構造の制約を提供します。 詳しくは、Experience Platform Data Ingestionの概要を参照してください。

スキーマの構成要素 schema-building-blocks

Experience Platform では、標準の構築要素を組み合わせてスキーマを作成する構成アプローチを使用します。 このアプローチは、既存のコンポーネントの再利用性を促進し、Experience Platformのベンダースキーマとコンポーネントをサポートするために、業界全体の標準化を促進します。

スキーマは、次の式を使用して構成されます。

クラス + スキーマフィールドグループ（&A） = XDM スキーマ

&ast；スキーマは、クラスと0個以上のスキーマフィールドグループで構成されます。 つまり、フィールドグループをまったく使用せずにデータセットスキーマを構成できます。

クラス class

クラスを割り当てることで、スキーマの構成が開始されます。 クラスは、スキーマに含まれるデータ（レコードまたは時系列）の行動的側面を定義します。 これに加えて、クラスは、そのクラスに基づくすべてのスキーマに含める必要のある共通のプロパティの最小数を記述し、複数の互換性のあるデータセットを結合する方法を提供します。

スキーマのクラスは、そのスキーマで使用できるフィールドグループを決定します。

Adobeには、いくつかの標準（「コア」） XDM クラスが用意されています。 これらのクラス XDM Individual ProfileとXDM ExperienceEventの2つは、ほぼすべてのダウンストリーム Experience Platform プロセスに必要です。 これらのコアクラスに加えて、独自のカスタムクラスを作成して、組織のより具体的なユースケースを説明することもできます。 カスタムクラスは、固有のユースケースを記述するために使用できるAdobe定義のコアクラスがない場合に、組織によって定義されます。

次のスクリーンショットは、Experience Platform UIでのクラスの表現方法を示しています。 表示されるスキーマの例にはフィールドグループが含まれていないため、表示されるすべてのフィールドはスキーマのクラス （XDM Individual Profile）によって提供されます。

使用可能な標準XDM クラスの最新のリストについては、公式XDM リポジトリ ​を参照してください。 または、UIでリソースを表示したい場合は、XDM コンポーネントの探索に関するガイドを参照できます。

フィールドグループ field-group

フィールドグループは、個人情報、ホテルの好み、住所などの特定の機能を実装する1つ以上のフィールドを定義する、再利用可能なコンポーネントです。 フィールドグループは、互換性のあるクラスを実装するスキーマの一部として含まれることを意図しています。

フィールドグループは、表すデータの動作（レコードまたは時系列）に基づいて、互換性のあるクラスを定義します。 つまり、すべてのフィールドグループがすべてのクラスで使用できるわけではありません。

Experience Platformには、多くの標準的なAdobe フィールドグループが含まれています。また、ベンダーがユーザーのフィールドグループを定義したり、個々のユーザーが独自のコンセプトのフィールドグループを定義したりすることもできます。

例えば、「Loyalty Members」スキーマの「First Name」や「Home Address」などの詳細をキャプチャするには、これらの一般的な概念を定義する標準フィールドグループを使用できます。 ただし、組織に固有の概念（カスタムロイヤルティプログラムの詳細や製品属性など）は、標準のフィールドグループでカバーされない場合があります。 この場合、この情報を取得するには、独自のフィールドグループを定義する必要があります。

スキーマは「0個以上の」フィールドグループで構成されていることに注意してください。つまり、フィールドグループをまったく使用せずに有効なスキーマを構成できます。

次のスクリーンショットは、Experience Platform UIでのフィールドグループの表現方法を示しています。 この例では、1つのフィールドグループ （Demographic Details）がスキーマに追加され、スキーマの構造にフィールドのグループが提供されます。

使用可能な標準XDM フィールドグループの最新のリストについては、公式XDM リポジトリ ​を参照してください。 または、UIでリソースを表示したい場合は、XDM コンポーネントの探索に関するガイドを参照できます。

データタイプ data-type

データタイプは、基本リテラルフィールドと同様に、クラスやスキーマの参照フィールド型として使用されます。 重要な違いは、データタイプは、フィールドグループと同じ方法で複数のサブフィールドを定義できることです。 両者の重要な違いは、データタイプをフィールドの「データタイプ」として追加することで、スキーマのどこにでもデータタイプを含めることができることです。 フィールドグループは特定のクラスとのみ互換性がありますが、データタイプは任意の親クラスまたはフィールドグループに含めることができます。

Experience Platformでは、共通のデータ構造を記述するための標準パターンの使用をサポートするために、Schema Registryの一部として、いくつかの共通のデータ型を提供しています。 この点については、​ スキーマレジストリ チュートリアル ​で詳しく説明しており、データタイプを定義する手順を説明すると、より明確になります。

次のスクリーンショットは、Experience Platform UIでのデータタイプの表現方法を示しています。 Demographic Details フィールドグループによって提供されるフィールドの1つは、フィールド名の横にあるパイプ文字（|）の後のテキストに示されているように、「Object」データタイプを使用します。 この特定のデータタイプは、個人の名前に関連するいくつかのサブフィールドを提供します。このサブフィールドは、人物の名前をキャプチャする必要がある他のフィールドに再利用できます。

使用可能な標準XDM データタイプの最新のリストについては、公式XDM リポジトリ ​を参照してください。 または、UIでリソースを表示したい場合は、XDM コンポーネントの探索に関するガイドを参照できます。

フィールド field

フィールドは、スキーマの最も基本的な構成要素です。 フィールドは、特定のデータタイプを定義することで、格納できるデータのタイプに関する制約を提供します。 これらの基本的なデータタイプは1つのフィールドを定義しますが、前述のデータタイプでは、複数のサブフィールドを定義し、さまざまなスキーマ全体で同じマルチフィールド構造を再利用できます。 したがって、フィールドの「データタイプ」をレジストリで定義されたデータタイプの 1 つとして定義する以外に、Experience Platform は、次のような基本的なスカラー型をサポートしています。

これらのスカラー型の有効な範囲は、特定のパターン、形式、最小値や最大値、事前定義値にさらに制限できます。 これらの制約を使用すると、以下のような、より詳細なフィールドタイプを幅広く表すことができます。

構成の例 composition-example

スキーマは、コンポジションモデルを使用して構築され、Experience Platformに取り込むデータのフォーマットと構造を表します。 前述したように、これらのスキーマは、クラスと、そのクラスと互換性のある0個以上のフィールドグループで構成されます。

例えば、小売店で行われた購入を説明するスキーマは、「Store Transactions」と呼ばれることがあります。 スキーマは、XDM ExperienceEvent クラスを、標準のCommerce フィールドグループおよびユーザー定義のProduct Info フィールドグループと組み合わせて実装します。

Web サイトのトラフィックを追跡する別のスキーマは「Web Visits」と呼ばれることがあります。 また、XDM ExperienceEvent クラスも実装されますが、今回は標準のWeb フィールドグループを組み合わせます。

以下の図は、これらのスキーマと各フィールドグループによって提供されるフィールドを示しています。 また、このガイドで前述した「Loyalty Members」スキーマを含む、XDM Individual Profile クラスに基づく2つのスキーマも含まれています。

和集合 union

Experience Platform では特定の使用事例のスキーマを作成できますが、特定のクラスタイプのスキーマの「和集合」を確認することもできます。 前の図は、XDM ExperienceEvent クラスに基づく2つのスキーマとXDM Individual Profile クラスに基づく2つのスキーマを示しています。 以下に示す和集合は、同じクラスを共有するすべてのスキーマのフィールドを集計します（XDM ExperienceEventとXDM Individual Profile、それぞれ）。

Real-Time Customer Profileで使用するスキーマを有効にすると、そのクラスの種類の和集合に含まれます。 Profileは、お客様の属性に関する堅牢な一元化されたプロファイルと、お客様がExperience Platformと統合された任意のシステムで発生したすべてのイベントのタイムスタンプ付きアカウントを提供します。 Profileは、結合ビューを使用して、このデータを表し、個々の顧客の全体像を提供します。

Profileの操作について詳しくは、​ リアルタイム顧客プロファイルの概要を参照してください。

XDM スキーマへのデータファイルのマッピング mapping-datafiles

Experience Platform に取得されるすべてのデータファイルは、XDM スキーマの構造に従う必要があります。 XDM 階層（サンプルファイルを含む）に準拠するようにデータファイルをフォーマットする方法の詳細は、ETL 変換のサンプルに関するドキュメントを参照してください。 データファイルの Experience Platform への取り込みに関する一般的な情報については、バッチ取り込みの概要を参照してください。

外部オーディエンスのスキーマ

外部システムからExperience Platformにオーディエンスを取り込む場合は、次のコンポーネントを使用してスキーマに取り込む必要があります。

次の手順

スキーマ構成の基本を理解したので、Schema Registryを使用してスキーマを探索および構築する準備が整いました。

2つのコア XDM クラスとそれらの一般的に使用される互換性のあるフィールドグループの構造を確認するには、次のリファレンスドキュメントを参照してください。

Schema Registryは、Experience Platform内のSchema Libraryへのアクセスに使用され、利用可能なすべてのライブラリリソースにアクセスできるユーザーインターフェイスとRESTful APIを提供します。 Schema Libraryには、Adobeによって定義された業界リソース、Experience Platform パートナーによって定義されたベンダーリソース、および組織のメンバーによって構成されたクラス、フィールドグループ、データタイプ、スキーマが含まれています。

UI を使用してスキーマの構成を開始するには、スキーマエディターのチュートリアルを参照しながら、このドキュメントで取り上げる「ロイヤルティメンバー」スキーマを作成します。

Schema Registry APIの使用を開始するには、まず、Schema Registry API開発者ガイド ​を読んでください。 開発者ガイドを読んだ後、スキーマレジストリ API を使用したスキーマの作成に関するチュートリアルで説明されている手順に従います。

付録

以下の節では、スキーマ構成の原則に関する追加情報を示します。

リレーショナルテーブルと埋め込みオブジェクト embedded

リレーショナルデータベースを使用する場合のベストプラクティスには、データの正規化、またはエンティティを取得してそれを個別のピースに分割し、複数のテーブルに表示することが含まれます。 データ全体を読み取るか、エンティティを更新するには、JOINを使用して、多数の個々のテーブルで読み取りと書き込みの操作を行う必要があります。

XDM スキーマは、埋め込みオブジェクトを使用することで、複雑なデータを直接表現し、階層構造を持つ自己完結型ドキュメントに格納できます。 この構造の主な利点の1つは、複数の非正規化テーブルへの高価な結合によってエンティティを再構築することなくデータをクエリできることです。 スキーマ階層のレベル数に制限はありません。

スキーマとビッグデータ big-data

現代のデジタルシステムは、大量の行動信号（トランザクションデータ、Web ログ、物のインターネット、ディスプレイなど）を生成します。 このビッグデータは、エクスペリエンスを最適化する非常に大きな機会を生み出しますが、データの規模と多様性が原因で、使用が困難です。 データから価値を引き出すには、データの構造、形式、定義を標準化し、一貫性のある方法で効率的に処理する必要があります。

スキーマは、複数のソースからのデータの統合、共通の構造や定義による標準化、複数のソリューション間での共有を可能にすることで、この問題を解決します。 これにより、データに対するあらゆる種類の質問に答えることができます。 データに対するあらゆる疑問を事前に把握し、それらの期待に応えるためにデータをモデル化する従来のデータモデリング手法から脱却します。

オブジェクトとフリーフォームフィールド objects-v-freeform

スキーマを設計する際に、自由形式フィールドよりもオブジェクトを選択する際に考慮すべき重要な要素がいくつかあります。

オブジェクト

自由形式フィールドでオブジェクトを使用する場合の長所と短所を以下に示します。

プロ:

短所:

フリーフォームフィールド

オブジェクトにフリーフォームフィールドを使用する長所と短所を以下に示します。

プロ:

短所: