スキーマ構成の基本

エクスペリエンスデータモデル（XDM）スキーマと、Adobe Experience Platformでスキーマを構成するための構成要素、原則およびベストプラクティスについて説明します。 XDM の一般的な情報と Platform 内での使用方法については、XDM システムの概要を参照してください。

スキーマ 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でスキーマを使用する主なメリットはいくつかあります。 1 つ目は、スキーマを使用すると、データガバナンスの改善とデータの最小化を可能にすることです。これは、プライバシー規制で特に重要になります。 次に、Adobeの標準コンポーネントを使用してスキーマを構築すると、最小限のカスタマイズで、すぐに使用できるインサイトを提供し、AI/ML サービスを使用できます。 最後に、スキーマは、データ共有のインサイトと効率的なオーケストレーションのためのインフラストラクチャを提供します。

スキーマの計画 planning

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

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

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

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

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

ID identity

スキーマは、データを Experience Platform に取得するために使用されます。このデータは、複数のサービスで使用して、個々のエンティティの単一の統合表示を作成できます。したがって、顧客 ID のスキーマをデザインする際には、データの取得元に関係なく、サブジェクトの識別に使用できるフィールドを考慮することが重要です。

このプロセスに役立つように、スキーマ内のキーフィールドを ID としてマークできます。 データの取り込み時に、これらのフィールドのデータは、その個人の「ID グラフ ​」に挿入されます。 その後、Real-Time Customer Profile や他のExperience Platformサービスからグラフデータにアクセスして、個々の顧客の関連付けられたビューを提供できます。

一般的に「ID」とマークされるフィールドには、メールアドレス、電話番号、Experience Cloud ID (ECID)、CRM ID、その他の一意の ID フィールドなどがあります。 組織に固有の一意の ID も考慮してください。これらは「ID」フィールドとしても使用できる可能性があるからです。

可能な限り堅牢なプロファイルを構築するためにデータを確実に統合するために、スキーマ計画フェーズで顧客 ID について考えることが重要です。 ID 情報が顧客にデジタルエクスペリエンスを提供するのにどのように役立つかについては、ID サービスの概要を参照してください。 スキーマ作成時の ID の使用に関するヒントについては、データモデリングのベストプラクティスのドキュメントを参照してください。

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

identityMap identityMap

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

identityMap を使用することの主な欠点は、ID がデータに埋め込まれ、その結果、見えにくくなることです。 生データを取り込む場合は、代わりに実際のスキーマ構造内で個々の ID フィールドを定義する必要があります。

ただし、ID マップは、1 つのスキーマに対して ID の数が可変な場合や、ID を保存するソース（Airship やAdobe Audience Managerなど）からデータを取り込む場合に役立ちます。 さらに、Adobe Experience Platform Mobile 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 スキーマに基づいており、取得するデータの内容と構造の制約を提供します。詳しくは、「Adobe Experience Platform でのデータ取得の概要」を参照してください。

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

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

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

クラス + スキーマフィールドグループ* = XDM スキーマ

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

クラス class

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

スキーマのクラスは、そのスキーマで使用できるフィールドグループを決定します。 これについて詳しくは、 次の節で説明します。

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

次のスクリーンショットは、Platform UI でクラスがどのように表されるかを示しています。 表示されるサンプルスキーマにはフィールドグループが含まれていないので、表示されるすべてのフィールドはスキーマのクラス（XDM 個人プロファイル ​）によって提供されます。

スキーマエディター内の

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

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

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

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

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

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

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

次のスクリーンショットは、Platform UI でフィールドグループがどのように表されるかを示しています。 この例では、単一のフィールドグループ（​ デモグラフィックの詳細 ​）がスキーマに追加され、スキーマの構造に対するフィールドのグループ化が可能になります。

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

データタイプ data-type

データタイプは、基本リテラルフィールドと同様に、クラスやスキーマの参照フィールド型として使用されます。主な違いは、データタイプがフィールドグループと同じ方法で複数のサブフィールドを定義できることです。 これらの主な違いは、データタイプをフィールドの「データタイプ」として追加することで、スキーマ内の任意の場所に含めることができるということです。 フィールドグループは特定のクラスにのみ適合しますが、データタイプは任意の親クラスまたはフィールドグループに含めることができます。

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

次のスクリーンショットは、Platform UI でデータタイプがどのように表されるかを示しています。 ​ デモグラフィックの詳細 ​ フィールドグループが提供するフィールドの 1 つは、「​ オブジェクト ​」データタイプを使用します。これは、フィールド名の横にあるパイプ文字（|）に続くテキストで示されます。 この特定のデータタイプは、個々のユーザーの名前に関連する複数のサブフィールドを提供します。これは、ユーザーの名前を取り込む必要がある他のフィールドで再利用できる構造です。

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

フィールド field

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

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

合成の例 composition-example

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

例えば、小売店での購入を記述するスキーマは「ストアトランザクション ​ と呼ばれる場合があり ​ す。 スキーマは、標準の Commerce フィールドグループとユーザー定義の Product Info フィールドグループを組み合わせた XDM ExperienceEvent クラスを実装します。

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

次の図に、これらのスキーマと、各フィールドグループによって提供されるフィールドを示します。 また、このガイドで前述した「​ ロイヤルティメンバー ​」スキーマなど、XDM Individual Profile クラスに基づく 2 つのスキーマも含まれています。

和集合 union

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

スキーマを Real-Time Customer Profile で使用できるようにすると、そのクラスタイプの結合に含められます。 Profile は、顧客属性の堅牢な一元化されたプロファイルと、Platform と統合されたあらゆるシステムで顧客が行ってきたすべてのイベントのタイムスタンプ付きアカウントを提供します。 Profile は、和集合ビューを使用してこのデータを表し、各顧客の全体像を提供します。

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

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

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

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

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

次の手順

これでスキーマ構成の基本を理解したので、次は Schema Registry を使用したスキーマの調査と構築を開始します。

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

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

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

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

付録

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

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

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

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

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

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

スキーマは、複数のソースからのデータの統合、共通の構造や定義による標準化、複数のソリューション間での共有を可能にすることで、この問題を解決します。これにより、後続のプロセスやサービスは、データに関するあらゆる種類の質問に答えることができます。 従来のデータモデリングのアプローチから移行します。従来のデータモデリングでは、データに関する質問はすべて事前に把握され、その期待に応えるためにデータがモデル化されます。

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

スキーマをデザインする際に自由形式フィールドよりもオブジェクトを選択する場合は、いくつかの重要な要因を考慮する必要があります。

オブジェクト

フリーフォームフィールドでオブジェクトを使用する場合のメリットとデメリットを以下に示します。

長所:

短所:

自由形式フィールド

オブジェクト上でフリーフォームフィールドを使用するメリットとデメリットを以下に示します。

長所:

短所: