スキーマ合成の基本

このドキュメントでは、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 でスキーマを活用する主なメリットはいくつかあります。 まず、スキーマはより優れたデータガバナンスとデータ最小化を可能にします。これは、プライバシー規制で特に重要です。 第 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 を考慮し、可能な限り堅牢なプロファイルを構築するためにデータを統合できるようにすることが重要です。 ID 情報で顧客にデジタルエクスペリエンスを提供する方法について詳しくは、Adobe Experience Platform ID サービス の概要を参照してください。

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

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

identityMap

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

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

メモ

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

ただし、ID をまとめるソース (Airship やAdobe Audience Managerなど ) からデータを取り込む場合や、スキーマの ID 数が可変の場合は、ID マップが特に役立ちます。 また、Adobe Experience Platform Mobile SDK を使用する場合は、ID マップが必要です。

単純な ID マップの例を次に示します。

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

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

メモ

値がプライマリ ID(primary) であるかどうかを表す boolean 値も、ID 値ごとに指定できます。 プライマリID は、Real-time Customer Profile で使用するスキーマに対してのみ設定する必要があります。 詳しくは、 和集合スキーマ の節を参照してください。

スキーマ進化の原理

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

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

メモ

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

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

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

スキーマとデータの取得

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

スキーマの構成要素

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

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

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

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

クラス

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

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

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

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

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

フィールドグループ

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

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

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

例えば、「ロイヤルティメンバー」スキーマの「名」や「自宅住所」などの詳細を取り込むには、これらの共通概念を定義する標準フィールドグループを使用できます。 ただし、一般的でない使用例に固有の概念(「ロイヤルティプログラムレベル」など)には、多くの場合、定義済みのフィールドグループはありません。 この場合、この情報を取り込むには、独自のフィールドグループを定義する必要があります。

メモ

標準のフィールドグループは、スキーマで可能な限り使用することを強くお勧めします。これらのフィールドは Experience Platform サービスで暗黙的に認識され、Platform コンポーネント間で使用する場合は一貫性が高まるからです。

標準コンポーネント(「名」や「電子メールアドレス」など)が提供するフィールドには、基本的なスカラーフィールド型以外にも、同じデータ型を共有するすべてのフィールドが同じように動作することを Platform に伝える追加の記述が含まれます。 この動作は、データの送信元や、データがどの Platform サービスで使用されているかに関係なく、一貫性を保つために信頼できます。

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

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

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

データタイプ

データタイプは、基本リテラルフィールドと同様に、クラスやスキーマの参照フィールド型として使用されます。主な違いは、データタイプが複数のサブフィールドを定義できる点です。フィールドグループと同様、データ型を使用すると、複数フィールド構造を一貫して使用できますが、フィールドの「データ型」として追加することで、スキーマの任意の場所にデータ型を含めることができるので、フィールドグループよりも柔軟性が高くなります。

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

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

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

フィールド

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

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

オブジェクトタイプのフィールドに対する自由形式のフィールドの使用に関する長所と短所については、 付録 を参照してください。

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

  • Enum
  • Long
  • Short
  • Byte
  • Date
  • Date-time
  • Map
メモ

「マップ」フィールドタイプでは、1 つのキーの複数の値を含む、キーと値のペアのデータを使用できます。マップは、システムレベルでのみ定義できます。つまり、業界またはベンダー定義のスキーマでマップが見つかる場合がありますが、定義したフィールドでは使用できません。フィールドの種類の定義について詳しくは、『スキーマレジストリ API 開発者ガイド』を参照してください。

合成の例

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

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

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

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

結合

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

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

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

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

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 を使用したスキーマの作成に関するチュートリアルで説明されている手順に従います。

付録

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

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

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

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

スキーマとビッグデータ

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

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

オブジェクトと自由形式のフィールド

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

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

オブジェクト

自由形式のフィールドに対するオブジェクトの使用に関する長所と短所を次に示します。

長所:

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

短所:

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

自由形式のフィールド

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

長所:

  • 自由形式のフィールドは、スキーマのルートオブジェクト (_tenantId) の直下に作成され、可視性が向上します。
  • クエリサービスを使用すると、フリーフォームフィールドの参照文字列が短くなる傾向があります。

短所:

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

このページ