スキーマ合成の基本

このドキュメントでは、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を考慮し、可能な限り堅牢なプロファイルを構築するためにデータを統合できるようにすることが重要です。 ID情報で顧客にデジタルエクスペリエンスを提供する方法について詳しくは、Adobe Experience Platform IDサービスの概要を参照してください。

identityMap

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

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

ただし、IDを格納するソース(AirshipやAdobe Audience Managerなど)からデータを取り込む場合は、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クラスを提供します。 これらのクラスのうち、XDM Individual ProfileとXDM ExperienceEventの2つは、ほぼすべてのダウンストリームPlatformプロセスに必要です。 これらのコアクラスに加えて、独自のカスタムクラスを作成して、組織の具体的な使用例を説明することもできます。 カスタムクラスは、一意の使用例を説明するAdobe定義のコアクラスがない場合に、組織によって定義されます。

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

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

フィールドグループ

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

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

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

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

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

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

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

データタイプ

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

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

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

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

フィールド

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

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

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

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

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

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

ダウンストリームサービスやアプリケーションで使用される一部のデータ操作では、特定のフィールドタイプに制約が適用されます。影響を受けるサービスには、次のものが含まれます。

ダウンストリームサービスで使用するスキーマを作成する前に、スキーマが意図するデータ操作のフィールド要件と制約をより深く理解するために、これらのサービスに関する適切なドキュメントを確認してください。

XDM フィールド

XDMは、基本的なフィールドと独自のデータ型を定義する機能に加えて、Experience Platformサービスで暗黙的に認識されるフィールドとデータ型の標準セットを提供し、Platformコンポーネント間で使用する場合に一貫性を高めます。

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

使用可能な XDM フィールドの完全なリストについては XDM フィールドディクショナリを参照してください。Experience Platform全体での一貫性と標準化をサポートするために、可能な限りXDMフィールドとデータ型を使用することをお勧めします。

合成の例

スキーマは、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)の直下に作成され、表示が向上します。
  • クエリサービスを使用すると、フリーフォームフィールドの参照文字列が短くなる傾向があります。

短所:

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

このページ