スキーマ合成の基本

このドキュメントでは、Experience Data Model (XDM)スキーマと、Adobe Experience Platformで使用されるスキーマを構成するための構成要素、原則、ベストプラクティスを紹介します。 XDMとPlatform内でのXDMの使い方に関する一般的な情報については、XDMシステムの概要を参照してください。

スキーマ

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

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

Experience Platform は、スキーマの使用を通して、このセマンティックの正規化を使用して維持します。スキーマはExperience Platformのデータを記述する標準的な方法で、スキーマに準拠するすべてのデータを組織間で競合なく再利用可能にし、複数の組織間で共有することも可能です。

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

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

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

スキーマとビッグデータ

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

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

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 PlatformIDサービスの概要を参照してください。

xdm:identityMap

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

単純な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)を表します。 Identity Serviceドキュメントを参照し、Adobeアプリケーションで認識される標準ID名前空間](…/…/identity-service/troubleshooting-guide.md#standard-namespaces)の[リストを確認してください。

メモ

値がプライマリ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 + Mixin* = XDM スキーマ

*スキーマは、クラスと 0 個以上の Mixin で構成されます。つまり、Mixin を使用せずにデータセットスキーマを作成できます。

クラス

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

スキーマのクラスは、そのスキーマで使用できるミックスインを決定します。 これについては、次のセクションで詳しく説明します。

Adobeは、2つの標準(「コア」)XDMクラスを提供します。XDM Individual ProfileとXDM ExperienceEvent。 これらのコアクラスに加えて、独自のカスタムクラスを作成して、貴社の具体的な使用例を説明することもできます。 カスタムクラスは、一意の使用例を説明するためのAdobe定義のコアクラスがない場合、組織によって定義されます。

Mixin

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

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

Experience Platform には多くの標準Adobeミックスインが含まれていますが、ベンダーはユーザーのミックスインを定義でき、個々のユーザーは独自の概念のミックスインを定義できます。

例えば、"名"や"ホームアドレス"などの詳細を"ロイヤルティメンバー"スキーマに取り込むには、これらの共通概念を定義する標準ミックスインを使用できます。 ただし、あまり一般的でない使用例に固有の概念(「忠誠度プログラムレベル」など)は、多くの場合、事前に定義されたミックスインを持っていません。 この場合、この情報を取り込むには、独自の Mixin を定義する必要があります。

スキーマは「0 個以上」の Mixin で構成されているので、Mixin を一切使用しないでも有効なスキーマを作成できます。

現在の標準ミックスインのリストについては、正式なXDMリポジトリを参照してください。

データタイプ

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

メモ

ミックスインとデータ型の違い、および類似の使用例での長所と短所については、付録を参照してください。

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

フィールド

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

  • 文字列
  • 整数
  • 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 個以上の Mixin で構成されます。

例えば、小売店で行われた購入を説明するスキーマは、「店舗トランザクション」と呼ばれる場合があります。 このスキーマは、標準のコマースミックスインとユーザ定義の製品情報ミックスインを組み合わせたXDM ExperienceEventクラスを実装します。

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

次の図に、これらのスキーマと各 Mixin が寄与するフィールドを示します。また、このガイドで前述した「忠誠度メンバー」スキーマを含む、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への取り込みに関する一般的な情報については、バッチインジェストの概要を参照してください。

次の手順

スキーマ構成の基本を理解したら、Schema Registryを使ってスキーマの調査や構築を始める準備が整いました。

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

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

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

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

付録

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

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

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

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

オブジェクト

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

長所:

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

短所:

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

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

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

長所:

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

短所:

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

このページ

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free