スキーマ構成の基本

このドキュメントでは、 Experience Data Model (XDM) スキーマと、Adobe Experience Platformで使用するスキーマを構成するための構成要素、原則およびベストプラクティス。 XDM と内での使用方法に関する一般情報 Platformを参照し、 XDM システムの概要.

スキーマ

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

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

Experience Platform は、スキーマを使用して、このセマンティックの正規化を維持します。スキーマは、 Experience Platformを使用すると、スキーマに準拠するすべてのデータを、競合のない組織全体で再利用したり、複数の組織間で共有したりできます。

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

でのスキーマベースのワークフロー Experience Platform

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

インフラストラクチャ Experience Platform は次のように構築されています。 XDM Systemは、スキーマベースのワークフローを容易にし、次を含みます。 Schema Registry, Schema Editor、スキーマメタデータ、サービス消費パターンについて説明します。詳しくは、「XDM システムの概要」を参照してください。

でスキーマを活用する主なメリットはいくつかあります。 Experience Platform. 第 1 に、スキーマは、より優れたデータガバナンスとデータ最小化を可能にします。これは、プライバシー規制で特に重要です。第 2 に、Adobeの標準コンポーネントを使用してスキーマを構築すると、標準のインサイトと、最小限のカスタマイズを加えて AI/ML サービスを使用できます。最後に、スキーマは、データ共有のインサイトと効率的なオーケストレーションのためのインフラストラクチャを提供します。

スキーマの計画

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

でのデータ動作 Experience Platform

での使用を意図したデータ Experience Platform は 2 つの動作タイプにグループ化されています。

レコードデータ：主体の属性に関する情報を提供します。主体は、組織または個人にすることができます。
時系列データ：レコードの主体によって直接または間接的にアクションが実行された時点のシステムのスナップショットを提供します。

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

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

ID

スキーマは、データをに取り込むために使用されます Experience Platform. このデータは、複数のサービスで使用して、個々のエンティティの単一の統合表示を作成できます。したがって、スキーマについて考える際には、顧客の ID と、データの送信元に関係なく、対象を識別するために使用できるフィールドについて考えることが重要です。

この処理を支援するために、スキーマ内のキーフィールドを ID としてマークできます。データの取り込み時に、これらのフィールドのデータがID グラフ」その後、グラフデータには、 Real-Time Customer Profile その他 Experience Platform 各顧客の関連付けられたビューを提供するサービス。

一般的に「ID"インクルード：メールアドレス、電話番号、 Experience Cloud ID (ECID)、CRM ID またはその他の一意の ID フィールド。また、「ID」フィールドも同様です。

スキーマ計画段階で顧客の ID を考慮し、可能な限り堅牢なプロファイルを構築するためにデータを統合できるようにすることが重要です。概要については、 Adobe Experience Platform Identity Service id 情報が、顧客にデジタルエクスペリエンスを提供するのに役立つ方法について詳しくは、こちらを参照してください。

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

を使用して、ID 記述子を個々のフィールドに追加するスキーマエディター UI またはスキーマレジストリ API
の使用 identityMap フィールド

`identityMap`

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

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

メモ

を使用するスキーマ identityMap は、関係内でソーススキーマとして使用できますが、参照スキーマとして使用することはできません。これは、すべての参照スキーマは、ソーススキーマ内の参照フィールドにマッピングできる、表示可能な ID を持つ必要があるからです。 UI ガイド ( 関係を参照してください。

ただし、ID を保存するソースからデータを取り込む場合 ( 例えば、 Airship またはAdobe Audience Manager)、またはスキーマの ID 数が可変の場合。また、 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・アプリケーションで認識される。

メモ

値がプライマリ ID(primary) は、id 値ごとに指定することもできます。プライマリID は、 Real-Time Customer Profile. 詳しくは、和集合スキーマを参照してください。

スキーマ進化の原理

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

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

メモ

スキーマがまだデータの取り込みに使用されていない場合 Experience Platform リアルタイム顧客プロファイルでの使用が有効になっていない場合は、そのスキーマに後方互換性のない変更を導入できます。ただし、 Platformの場合は、追加のバージョン管理ポリシーに従う必要があります。

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

サポートされる変更	後方互換性のない変更（サポートなし）
リソースへの新しいフィールドの追加必須フィールドのオプション化新しい必須フィールドの紹介* リソースの表示名と説明の変更プロファイルへのスキーマの参加を有効にする	以前に定義したフィールドの削除既存のフィールドの名前の変更または再定義以前にサポートされていたフィールド値の削除または制限ツリー内の別の場所への既存のフィールドの移動スキーマの削除プロファイルへのスキーマの参加の無効化

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

必須フィールド

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

重要

スキーマフィールドが必須かどうかに関係なく、Platform は受け入れません null 取り込まれたフィールドの空の値レコードまたはイベントの特定のフィールドに値がない場合、そのフィールドのキーを取り込みペイロードから除外する必要があります。

取り込み後に必要に応じてフィールドを設定

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

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

履歴データに対してクエリを実行し、その結果を新しいデータセットに書き込むと、一部の行が失敗します。これは、必須フィールドに null 値が含まれているからです。
フィールドがリアルタイム顧客プロファイルまた、必要に応じて設定する前にデータをエクスポートする場合は、一部のプロファイルで null になる場合があります。
スキーマレジストリ API を使用して、Platform 内のすべての XDM リソース（新しい必須フィールドを含む）のタイムスタンプ付きの変更ログを表示できます。詳しくは、監査ログエンドポイントを参照してください。

スキーマとデータの取得

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

スキーマの構成要素

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

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

Class + Schema Field Group*= XDM スキーマ

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

クラス

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

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

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

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

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

フィールドグループ

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

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

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

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

メモ

標準フィールドグループは、で暗黙的に理解されるので、スキーマで可能な限り標準フィールドグループを使用することを強くお勧めします。 Experience Platform サービスを介して使用する場合は、 Platform コンポーネント。

標準コンポーネント（「名」や「電子メールアドレス」など）で提供されるフィールドには、基本的なスカラーフィールドタイプ以外にも、 Platform 同じデータタイプを共有するフィールドは、同じように動作します。この動作は、データの送信元や送信先に関係なく、一貫性を保つために信頼できます Platform サービスは、データが使用されている場合に使用します。

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

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

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

データタイプ

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

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

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

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

フィールド

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

文字列
整数
Double
Boolean
配列
オブジェクト

ヒント

詳しくは、付録を参照してください。

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

Enum
Long
Short
Byte
Date
Date-time
Map

メモ

「マップ」フィールドタイプでは、1 つのキーの複数の値を含む、キーと値のペアのデータを使用できます。マップは、標準の XDM クラスとフィールドグループで見つけることができますが、スキーマレジストリ API を使用してカスタムマップを定義することもできます。に関するチュートリアルを参照してください。カスタムフィールドの定義を参照してください。

合成の例

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

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

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

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

結合

While Experience Platform では、特定の使用例に関するスキーマを作成でき、特定のクラスタイプのスキーマの「和集合」を確認することもできます。上の図は、XDM ExperienceEvent クラスに基づく 2 つのスキーマと、に基づく 2 つのスキーマを示しています XDM Individual Profile クラス。次に示す和集合は、同じクラス (XDM ExperienceEvent および XDM Individual Profile、それぞれ )。

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

の使用に関する詳細 Profileを参照し、リアルタイム顧客プロファイルの概要.

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

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

外部セグメントのスキーマ

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

セグメント定義クラス:この標準クラスを使用して、外部セグメント定義のキー属性をキャプチャします。
セグメントメンバーシップの詳細フィールドグループ:このフィールドグループを XDM 個人プロファイルスキーマを使用して、顧客プロファイルを特定のセグメントに関連付けます。

次の手順

これで、スキーマ構成の基本を理解したので、 Schema Registry.

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

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

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

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

付録

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

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

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

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

スキーマとビッグデータ

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

スキーマは、複数のソースからのデータの統合、共通の構造や定義による標準化、複数のソリューション間での共有を可能にすることで、この問題を解決します。これにより、後続のプロセスとサービスは、データについて尋ねられるあらゆるタイプの質問に答えることができます。これは、データについて尋ねられるすべての質問が事前にわかっていて、データがそれらの期待に準拠するようにモデル化される従来のデータモデリングアプローチとは異なります。

オブジェクトとフリーフォームフィールド

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

オブジェクト	フリーフォームフィールド
ネストが増加	ネストが少ない、またはない
論理フィールドのグループ化を作成します	フィールドはアドホックの場所に配置されます

オブジェクト

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

長所:

オブジェクトは、特定のフィールドの論理的なグループを作成する場合に最適です。
オブジェクトは、より構造化された方法でスキーマを整理します。
オブジェクトは、セグメントビルダー UI で適切なメニュー構造を作成する際に間接的に役立ちます。スキーマ内のグループ化されたフィールドは、セグメントビルダー UI で提供されるフォルダー構造に直接反映されます。

短所:

フィールドがよりネストされます。
を使用する場合 Adobe Experience Platform Query Serviceの場合、オブジェクトにネストされるクエリフィールドには、より長い参照文字列を指定する必要があります。

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

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

長所:

フリーフォームフィールドは、スキーマのルートオブジェクト (_tenantId) をクリックし、可視性を高めます。
クエリサービスを使用すると、フリーフォームフィールドの参照文字列が短くなる傾向があります。

短所:

スキーマ内の自由形式のフィールドの場所はアドホックです。つまり、スキーマエディター内では、アルファベット順に表示されます。これにより、スキーマの構造が狭くなり、類似したフリーフォームフィールドが名前に応じて大きく区切られる場合があります。

Business.Adobe.com リソース

Mobile Forms Theme Editor Audience Segmentation Mobile Marketing Audience Insights Tv Advertising