スキーマ構成の基本

Experience Data Model(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 に、スキーマは、より優れたデータガバナンスとデータ最小化を可能にします。これは、プライバシー規制で特に重要です。 第 2 に、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 に送信する方法は 2 つあります。

identityMap identityMap

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

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

ただし、スキーマの ID の数が可変の場合や、ID を一緒に保存するソースからデータを取り込む場合 ( 例えば、 Airship またはAdobe Audience Manager)。 また、 Adobe Experience Platform Mobile SDK.

単純な 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) を使用します。 詳しくは、 Identity Service のドキュメント 標準 id 名前空間のリスト は、Adobe・アプリケーションで認識される。

スキーマ進化の原則 evolution

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

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

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

*以下の節で、 新しい必須フィールドの設定.

必須フィールド

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

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

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

以前に任意のフィールドを必要に応じて設定した場合は、次の点に注意してください。

スキーマとデータの取得

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

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

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

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

Class + Schema Field Group* = XDM Schema

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

クラス class

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

スキーマのクラスは、そのスキーマで使用する資格のあるフィールドグループを決定します。 これについて詳しくは、 次のセクション.

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

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

使用可能な標準 XDM クラスの最新のリストについては、 公式 XDM リポジトリ. または、 XDM コンポーネントの詳細 （UI でリソースを表示する場合）。

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

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

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

Experience Platformには多くの標準Adobeフィールドグループが含まれていますが、ベンダーはユーザーのフィールドグループを定義し、個々のユーザーは独自の概念のフィールドグループを定義できます。

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

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

次のスクリーンショットは、Platform UI でフィールドグループがどのように表されるかを示しています。 単一のフィールドグループ (人口統計の詳細) がこの例のスキーマに追加され、スキーマの構造にフィールドのグループを提供します。

使用可能な標準 XDM フィールドグループの最新のリストについては、 公式 XDM リポジトリ. または、 XDM コンポーネントの詳細 （UI でリソースを表示する場合）。

データタイプ data-type

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

Experience Platformは、 Schema Registry 共通のデータ構造を記述するための標準パターンの使用を支援する。 詳しくは、 スキーマレジストリのチュートリアル データタイプを定義する手順を実行すると、より明確になります。

次のスクリーンショットは、Platform UI でデータタイプがどのように表されるかを示しています。 が提供するフィールドの 1 つ 人口統計の詳細 フィールドグループは、「オブジェクト"データタイプ。パイプ文字 (|) をクリックします。 この特定のデータ型は、個人の名前に関連するいくつかのサブフィールドを提供します。これは、人の名前を取り込む必要がある他のフィールドで再利用できる構成体です。

使用可能な標準 XDM データタイプの最新のリストについては、 公式 XDM リポジトリ. または、 XDM コンポーネントの詳細 （UI でリソースを表示する場合）。

フィールド field

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

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

合成の例 composition-example

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

例えば、小売店で行われた購入を記述するスキーマを、「ストアトランザクション". スキーマがを実装します。 XDM ExperienceEvent 標準と組み合わされたクラス コマース フィールドグループとユーザー定義 製品情報 フィールドグループを使用します。

Web サイトトラフィックを追跡する別のスキーマは、「ウェブ訪問数". また、 XDM ExperienceEvent クラスは、今回は標準の Web フィールドグループを使用します。

次の図に、これらのスキーマと各フィールドグループが提供するフィールドを示します。 また、に基づく 2 つのスキーマが含まれます XDM Individual Profile クラス (「ロイヤルティメンバー」スキーマに関する情報は、このガイドで前述しました。

和集合 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 クラスと、よく使用される互換性のあるフィールドグループの構造を確認するには、次の参照ドキュメントを参照してください。

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

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

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

付録

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

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

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

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

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

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

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

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

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

オブジェクト

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

長所:

短所:

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

オブジェクトに対してフリーフォームフィールドを使用する場合の長所と短所を次に示します。

長所:

短所: