Schema Editor

Adobe Experience Platformのユーザーインターフェイスを使用すると、Schema Editor と呼ばれるインタラクティブなビジュアルキャンバスで Experience Data Model (XDM) スキーマを作成および管理できます。 このチュートリアルでは、Schema Editor を使用してスキーマを作成する方法について説明します。

代わりに Schema Registry API を使用してスキーマを作成する場合は、まず API を使用したスキーマの作成に関するチュートリアルを読む前に、『Schema Registry 開発者ガイド 』を読んでください。

はじめに

このチュートリアルでは、スキーマの作成に関わるAdobe Experience Platformの様々な側面に関する十分な知識が必要です。 このチュートリアルを始める前に、次の概念に関するドキュメントを確認してください。

• Experience Data Model (XDM)：顧客体験データを編成する際に Platform に使用される標準化されたフレームワーク。
  • スキーマ構成の基本:XDM スキーマとその構成要素（クラス、スキーマフィールドグループ、データタイプ、個々のフィールドを含む）の概要です。
• Real-time Customer Profile：複数のソースからの集計データに基づいて、統合されたリアルタイムの顧客プロファイルを提供します。

スキーマ ワークスペースを開きます。

Platform UI の スキーマ ワークスペースでは、Schema Library が視覚化され、組織で使用可能なスキーマを表示できます。 ワークスペースには、このチュートリアル全体でスキーマを作成できるキャンバス Schema Editor も含まれています。

Experience Platform にログインした後、左のナビゲーションで「スキーマ」を選択して、「スキーマ」ワークスペースを開きます。 「参照」タブには、スキーマのリスト（Schema Library の表現）が表示され、表示やカスタマイズができます。 リストには、スキーマの基となる名前、型、クラス、動作（レコードまたは時系列）、およびスキーマが最後に変更された日時が含まれます。

詳しくは、UI での既存の XDM リソースの参照 のガイドを参照してください。

スキーマの作成と命名

スキーマの構成を開始するには、スキーマ ワークスペースの右上隅にある「スキーマ を作成」を選択します。 ドロップダウンメニューが表示され、コアクラス XDM Individual Profile と XDM ExperienceEvent のどちらかを選択できます。 これらのクラスが目的に合わない場合は、「参照」を選択して他の使用可能なクラスから選択するか、 新しいクラス を作成します。

このチュートリアルの目的では、「XDM Individual Profile」を選択します。

スキーマの基にする標準の XDM クラスを選択したので、フィールドグループを追加 ダイアログが表示され、スキーマへのフィールドの追加をすぐに開始できます。 ここでは、「キャンセル」を選択してダイアログを閉じます。

Schema Editor が表示されます。 これは、スキーマを作成するキャンバスです。名称未設定のスキーマは、エディターに到達すると、キャンバスの「構造」セクションに自動的に作成され、そのクラスに基づくすべてのスキーマに含まれる標準フィールドも作成されます。 スキーマに割り当てられたクラスは、 構成 セクションの クラス にも表示されます。

エディターの右側のフィールドを使用して、スキーマの表示名と説明（オプション）を指定します。 名前を入力すると、キャンバスが更新され、スキーマの新しい名前が反映されます。

スキーマの名前を決定する際に考慮すべき重要な点がいくつかあります。

• 後でスキーマを簡単に見つけられるように、スキーマ名は短く、説明的にする必要があります。
• スキーマ名は一意である必要があります。つまり、将来再利用されないように十分に具体的でなければなりません。例えば、組織が異なるブランドに対して別々のロイヤルティプログラムを持つ場合、後で定義する他のロイヤルティ関連スキーマと区別しやすいように、スキーマに「ブランド A ロイヤルティメンバー」という名前を付けると効果的です。
• スキーマの説明を使用して、スキーマに関する追加のコンテキスト情報を指定することもできます。

このチュートリアルでは、ロイヤルティプログラムのメンバーに関連するデータを取り込むスキーマを構成するので、スキーマの名前は「ロイヤルティメンバー」になります。

フィールドグループの追加

これで、フィールドグループを追加して、スキーマにフィールドを追加できます。 フィールドグループは、1 つ以上のフィールドのグループで、特定の概念を説明するために一緒に使用されることがよくあります。 このチュートリアルでは、フィールドグループを使用してロイヤルティプログラムのメンバーを説明し、名前、誕生日、電話番号、住所などの主要な情報を取り込みます。

フィールドグループを追加するには、「フィールドグループ」サブセクションで「追加」を選択します。

新しいダイアログが開き、使用可能なフィールドグループのリストが表示されます。 各フィールドグループは、特定のクラスでのみ使用するため、ダイアログには、選択したクラス（この場合は XDM Individual Profile クラス）と互換性のあるフィールドグループのみが表示されます。 標準の XDM クラスを使用している場合、フィールドグループのリストは、使用頻度に基づいてインテリジェントに並べ替えられます。

リストからフィールドグループを選択すると、右側のパネルに表示されます。 必要に応じて複数のフィールドグループを選択し、確認する前に右側のレールのリストに各フィールドグループを追加できます。 また、現在選択されているフィールドグループの右側にアイコンが表示され、提供されるフィールドの構造をプレビューできます。

フィールドグループをプレビューする際に、右側のパネルに、フィールドグループのスキーマに関する詳細な説明が表示されます。 また、提供されたキャンバスで、フィールドグループのフィールド間を移動することもできます。 異なるフィールドを選択すると、右側のレールが更新され、該当するフィールドに関する詳細が表示されます。 プレビューが終了したら、「戻る」を選択して、フィールドグループ選択ダイアログに戻ります。

このチュートリアルでは、人口統計の詳細 フィールドグループを選択し、フィールドグループを追加 を選択します。

スキーマキャンバスが再び表示されます。「フィールドグループ」セクションに「人口統計の詳細」が表示され、「構造」セクションにはフィールドグループが提供するフィールドが含まれます。 「フィールドグループ」セクションでフィールドグループの名前を選択して、キャンバス内の特定のフィールドをハイライト表示できます。

このフィールドグループは、最上位の名前 person の下に、データ型「Person」の複数のフィールドを表示します。 このフィールドグループは、名前、生年月日、性別など、個人に関する情報を説明します。

name フィールドのデータ型は「人名」です。つまり、一般的な概念を表し、名、姓、敬称、サフィックスなど、名前に関連するサブフィールドが含まれます。

キャンバス内の異なるフィールドを選択して、スキーマ構造に影響を与える追加のフィールドを表示します。

別のフィールドグループの追加

同じ手順を繰り返して、別のフィールドグループを追加できます。 今回は、フィールドグループを追加 ダイアログを表示すると、「人口統計の詳細」フィールドグループが灰色表示になっていて、隣のチェックボックスは選択できないことに注意してください。 これにより、既に現在のスキーマに含まれているフィールドグループを誤って複製するのを防ぎます。

このチュートリアルでは、ダイアログから「Personal Contact Details」フィールドグループを選択し、「フィールドグループを追加」を選択してスキーマに追加します。

追加すると、キャンバスが再び表示されます。「個人の連絡先の詳細」が 構成 の フィールドグループ に、自宅住所、携帯電話などのフィールドが 構造 に追加されました。

name フィールドと同様、先ほど追加したフィールドは複数フィールドの概念を表します。 例えば、homeAddress のデータ型は「郵送先住所」、mobilePhone のデータ型は「電話番号」です。 これらの各フィールドを選択して展開し、データ型に含まれる追加のフィールドを確認できます。

カスタムフィールドグループの定義

「ロイヤルティメンバー」スキーマは、ロイヤルティプログラムのメンバーに関連するデータを取り込むためのものなので、特定のロイヤルティ関連のフィールドが必要になります。

標準の Loyalty Details フィールドグループをスキーマに追加して、ロイヤルティプログラムに関連する共通のフィールドを取り込むことができます。 標準のフィールドグループを使用して、スキーマによって取り込まれた概念を表すことを強くお勧めしますが、標準のロイヤルティフィールドグループの構造では、特定のロイヤルティプログラムの関連データをすべて取り込めない場合があります。 このシナリオでは、新しいカスタムフィールドグループを定義して、代わりにこれらのフィールドを取り込むことができます。

フィールドグループを追加 ダイアログを再度開きますが、今度は上部近くにある「新しいフィールドグループを作成」を選択します。 次に、フィールドグループの表示名と説明を入力するよう求められます。

クラス名と同様に、フィールドグループ名は短く単純で、フィールドグループがスキーマに与える影響を説明する必要があります。 これらも一意なので、名前を再利用できません。名前が十分に具体的であるようにしてください。

このチュートリアルでは、新しいフィールドグループに「Loyalty Details」と名前を付けます。

「フィールドグループを追加」を選択して、Schema Editor に戻ります。 「Loyalty Details」がキャンバスの左側にある「フィールドグループ」の下に表示されるはずですが、関連付けられたフィールドはまだないので、「構造」の下に新しいフィールドは表示されません。

フィールドグループにフィールドを追加する

「Loyalty Details」フィールドグループを作成したら、次に、フィールドグループがスキーマに貢献するフィールドを定義します。

まず、「フィールドグループ」セクションでフィールドグループ名を選択します。 これをおこなうと、フィールドグループのプロパティがエディターの右側に表示され、構造 の下でスキーマ名の横に プラス (+) アイコンが表示されます。

「Loyalty Members」の横にある プラス (+) アイコンを選択して、構造内に新しいノードを作成します。 このノード（この例では _tenantId と呼ばれます）は、IMS 組織のテナント ID を表し、前にアンダースコアが付いています。 テナント ID の存在は、追加するフィールドが組織の名前空間に限られていることを示しています。

つまり、追加するフィールドは組織に固有で、Schema Registry 内の組織のみがアクセスできる特定の領域に保存されます。 他の標準クラス、フィールドグループ、データタイプ、フィールドの名前との競合を防ぐために、定義したフィールドは常にテナント名前空間に追加する必要があります。

その名前空間ノード内には、「新しいフィールド」があります。 これは、「Loyalty Details」フィールドグループの先頭です。

エディターの右側にあるコントロールを使用して、まず、ロイヤルティ関連のフィールドの保持に使用する「Object」型の loyalty フィールドを作成します。 終了したら、「適用」を選択します。

変更が適用され、新しく作成された loyalty オブジェクトが表示されます。 オブジェクトの横にある プラス (+) アイコンを選択して、その他のロイヤルティ関連のフィールドを追加します。 「新しいフィールド」が表示され、「フィールドプロパティ」セクションがキャンバスの右側に表示されます。

各フィールドには、次の情報が必要です。

• フィールド名: キャメルケースで書かれたフィールド名。例：loyaltyLevel
• 表示名: タイトルケースで書かれたフィールド名。例：Loyalty Level
• 型: フィールドのデータ型。これには、基本的なスカラー型と Schema Registry で定義されたデータ型が含まれます。 例：文字列、整数、ブール値、人物、住所、電話番号 など。
• 説明: フィールドのオプションの説明は、大文字と小文字で記述し、最大 200 文字にする必要があります。

Loyalty オブジェクトの最初のフィールドは、loyaltyId という文字列になります。 新しいフィールドのタイプを「String」に設定すると、フィールドのプロパティ セクションに、デフォルト値、形式、最大長など、制約を適用するためのオプションが設定されます。

選択したデータ型に応じて、様々な制約オプションを使用できます。loyaltyId は電子メールアドレスになるので、フォーマット ドロップダウンメニューから「email」を選択します。 「適用」を選択して変更を適用します。

フィールドグループにフィールドを追加する

loyaltyId フィールドを追加したら、次のようなロイヤルティ関連の情報を取り込むためのフィールドを追加できます。

• ポイント（整数）
• メンバー登録日（日付）

各フィールドをスキーマに追加するには、loyalty オブジェクトの横にある プラス (+) アイコンを選択し、必要な情報を入力します。

完了すると、Loyalty オブジェクトに、ロイヤルティ ID、ポイント、およびメンバー登録のフィールドが含まれます。

列挙フィールドをフィールドグループに追加する

Schema Editor でフィールドを定義する場合、フィールドに含めることのできるデータにさらに制約を加えるために、基本的なフィールドタイプに適用できる追加のオプションがいくつかあります。 これらの制限の使用例を次の表に示します。

このチュートリアルでは、スキーマ内の “loyalty” オブジェクトに、顧客の「ロイヤルティレベル」を説明する新しい列挙フィールドが必要です。この値は、4 つのオプションの中の 1 つのみです。 このフィールドをスキーマに追加するには、loyalty オブジェクトの横にある プラス (+) アイコンを選択し、フィールド名 と 表示名 の必須フィールドに入力します。 型 の場合は、「文字列」を選択します。

配列、列挙、ID のチェックボックスなど、タイプが選択された後に、フィールドに追加のチェックボックスが表示されます。

「列挙」チェックボックスを選択して、下の「列挙値」セクションを開きます。 ここで、許容可能な各ロイヤルティレベルの​値（キャメルケース）と​ラベル（タイトルケースでの読みやすい名前でオプション）を入力できます。

すべてのフィールドプロパティを完了したら、「適用」を選択して、「loyaltyLevel」フィールドを loyalty オブジェクトに追加します。

複数フィールドオブジェクトのデータ型への変換

loyalty オブジェクトには、複数のロイヤルティ固有のフィールドが含まれ、他のスキーマで役立つ共通のデータ構造を表しています。 Schema Editor を使用すると、再利用可能な複数フィールドオブジェクトを簡単に適用できます。これらのオブジェクトの構造をデータ型に変換します。

データ型を使用すると、複数フィールド構造を一貫して使用でき、フィールドグループよりも柔軟性が高まります。データ型は、スキーマ内の任意の場所で使用できるからです。 これは、フィールドの 型 の値を、Schema Registry で定義された任意のデータ型の値に設定することでおこなわれます。

loyalty オブジェクトをデータ型に変換するには、構造 の下の loyalty フィールドを選択し、エディターの右側にある「フィールドのプロパティ」の下の「 新しいデータ型に変換」を選択します。 オブジェクトが正常に変換されたことを確認する緑色のポップオーバーが表示されます。

構造 の下を見ると、loyalty フィールドのデータ型が「Loyalty」で、フィールドの横に小さなロックアイコンが表示され、個々のフィールドではなく、複数フィールドデータ型の一部であることがわかります。

今後のスキーマでは、フィールドを「Loyalty」型として割り当て、ID、ロイヤルティレベル、メンバー登録日、ポイントのフィールドを自動的に含めることができます。

スキーマフィールドの検索とフィルタリング

スキーマに、基本クラスで指定されたフィールドに加えて、複数のフィールドグループが含まれるようになりました。 大きなスキーマを扱う場合は、左側のレールでフィールドグループ名の横にあるチェックボックスをオンにして、表示するフィールドを、目的のフィールドグループが提供するフィールドにのみフィルタリングできます。

スキーマ内の特定のフィールドを検索する場合は、検索バーを使用して、表示されるフィールドを、その下に提供されるフィールドグループに関係なく、名前でフィルタリングすることもできます。

ID フィールドとしてのスキーマフィールドの設定

スキーマが提供する標準のデータ構造を活用して、複数のソースにわたって同じ個人に属するデータを識別でき、セグメント化、レポート、データサイエンス分析など、様々なダウンストリームの使用例に使用できます。 個々の ID に基づいてデータをステッチするには、キーフィールドを該当するスキーマ内で ID フィールドとしてマークする必要があります。

Experience Platform では、の ID チェックボックスを使用して、ID フィールドを ​​簡単に示しま Schema Editorす。ただし、データの性質に基づいて、ID として使用するのに最適な候補フィールドを決定する必要があります。

例えば、同じ「ロイヤルティレベル」に属するロイヤルティプログラムメンバーが数千人いる場合がありますが、ロイヤルティプログラムの各メンバーは一意の loyaltyId（この場合、個々のメンバーの電子メールアドレス）を持ちます。 loyaltyId が各メンバーの一意の識別子であることは、ID フィールドの適切な候補となりますが、loyaltyLevel は異なります。

エディターの「構造」セクションで、「loyaltyId」フィールドを選択し、「フィールドのプロパティ」の下に「ID」チェックボックスが表示されます。 チェックボックスをオンにし、「プライマリID」に設定するオプションを表示します。 このボックスも選択します。

次に、ドロップダウン内の事前定義済みの名前空間のリストから ID 名前空間 を指定する必要があります。 loyaltyId は顧客の電子メールアドレスなので、ドロップダウンから「電子メール」を選択します。 「適用」を選択して、「loyaltyId」フィールドの更新を確定します。

変更を適用した後、 loyaltyId のアイコンに指紋の記号が表示され、現在は ID フィールドであることが示されます。

loyaltyId フィールドに取り込まれたすべてのデータを使用して、個人を特定し、その顧客の単一の表示をつなぎ合わせることができます。 Experience Platform での ID の使用について詳しくは、Identity Service のドキュメントを参照してください。

Real-time Customer Profile でのスキーマの使用を有効にする

Real-time Customer Profile では、の id データを Experience Platform 利用して、各顧客の全体像を提供します。このサービスは、顧客属性の堅牢な 360 °プロファイルと、Experience Platform と統合されたシステム全体で顧客が持つすべてのインタラクションのタイムスタンプ付きのアカウントを構築します。

Real-time Customer Profile で使用できるように、スキーマにプライマリ ID が定義されている必要があります。 最初にプライマリ ID を定義せずにスキーマを有効にしようとすると、エラーメッセージが表示されます。

Profile での「ロイヤルティメンバー」スキーマの使用を有効にするには、エディターの「構造」セクションで「Loyalty Members」を選択します。

エディターの右側に、スキーマの表示名、説明、タイプなどの情報が表示されます。 この情報に加えて、プロファイル 切り替えボタンがあります。

「Profile」を選択すると、Profile のスキーマを有効にするかどうかを確認するポップオーバーが表示されます。

「有効」を選択して選択を確定します。 「プロファイル」切り替えをもう一度選択して、必要に応じてスキーマを無効にできます。ただし、Profile を有効にしている間にスキーマを保存すると、無効にできなくなります。

次の手順とその他のリソース

これで、スキーマの合成が完了し、キャンバスに完全なスキーマが表示されます。 「保存」を選択すると、スキーマが Schema Library に保存され、Schema Registry からアクセスできるようになります。

これで、新しいスキーマを使用して、データを Platform に取り込むことができます。 データの取得にスキーマを使用した後は、追加的な変更のみがおこなわれる場合があります。スキーマバージョン管理について詳しくは、「スキーマ合成の基本」を参照してください。

次に、UI での スキーマ関係の定義 に関するチュートリアルに従って、新しい関係フィールドを「ロイヤルティメンバー」スキーマに追加できます。

「ロイヤルティメンバー」スキーマは、Schema Registry API を使用して表示および管理することもできます。 API の使用を開始するには、まず『Schema Registry API 開発者ガイド 』を読んでください。

ビデオリソース

次のビデオでは、Platform UI で簡単なスキーマを作成する方法を示します。

次のビデオは、フィールドグループとクラスの操作に関する理解を深めるためのものです。

付録

以下の節では、Schema Editor の使用に関する追加情報を示します。

新しいクラスの作成

Experience Platform は、組織に固有のクラスに基づいてスキーマを定義する柔軟性を提供します。新しいクラスの作成方法については、UI でのクラスの作成と編集に関するガイド を参照してください。

スキーマクラスの変更

スキーマが保存される前の最初の構成プロセス中の任意の時点で、スキーマのクラスを変更できます。

スキーマのクラスを変更する方法については、UI でのスキーマの管理 に関するガイドを参照してください。