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のデータ型は「[!UICONTROL 住所]」、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オブジェクトをデータ型に変換するには、[!UICONTROL 構造]​の下のloyaltyフィールドを選択し、エディターの右側にある「[!UICONTROL ​フィールドのプロパティ​]」の下の「新しいデータ型​に変換」を選択します。 オブジェクトが正常に変換されたことを確認する緑のポップオーバーが表示されます。

構造​の下を見ると、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でのスキーマの管理に関するガイドを参照してください。