Schema Editor を使用したスキーマの作成

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

デモンストレーションを目的として、このチュートリアルの手順には、顧客ロイヤルティプログラムのメンバーを記述するサンプルスキーマの作成が含まれています。これらの手順を使用して、異なるスキーマを独自の用途で作成できますが、まずは、サンプルスキーマの作成方法を追って Schema Editor の機能を理解することをお勧めします。

はじめに

このチュートリアルを実行するには、スキーマの作成に関する Adobe Experience Platform の様々な側面を実践的に理解している必要があります。このチュートリアルを始める前に、次の概念に関するドキュメントを確認してください。

Schemas ワークスペースを開く browse

Schemas UIのExperience Platform ワークスペースには、Schema Libraryのビジュアライゼーションが表示され、組織で使用可能なスキーマの管理を表示できます。 ワークスペースには Schema Editor も含まれています。これは、このチュートリアル全体を通してスキーマを作成できるキャンバスです。

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

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

スキーマの作成と命名 create

スキーマの作成を開始するには、Create schema ワークスペースの右上隅にある​ Schemas ​を選択します。

Create a schema ダイアログが表示されます。 このダイアログでは、フィールドとフィールドグループを追加してスキーマを手動で作成するか、CSV ファイルをアップロードしてML アルゴリズムを使用してスキーマを生成するかを選択できます。 ダイアログからスキーマ作成ワークフローを選択します。

[Beta]{class="badge informative"}手動またはML支援のスキーマ作成 manual-or-assisted

マシンラーニングアルゴリズムを使用して、アップロードされたファイルに基づくスキーマ構造を推奨する方法については、機械学習を支援するスキーマ作成ガイド ​を参照してください。 このUI ガイドでは、手動作成ワークフローに焦点を当てます。

基本クラスの選択 choose-a-class

Create schema ワークフローが表示されます。 次に、スキーマのベースクラスを選択します。 これらのクラスが目的に合わない場合は、XDM Individual ProfileとXDM ExperienceEventのコアクラス、またはOtherのいずれかを選択できます。 「Other クラス」オプションを使用すると、新しいクラスを作成するか、他の既存のクラスから選択できます。

これらのクラスについて詳しくは、XDM individual profileおよびXDM ExperienceEventのドキュメントを参照してください。 このチュートリアルの目的では、XDM Individual Profile​を選択した後、Next​を選択します。

命名とレビュー name-and-review

クラスを選択すると、Name and review セクションが表示されます。 このセクションでは、スキーマを識別するための名前と説明を指定します。 スキーマの名前を決定する際に考慮すべき重要な点がいくつかあります。

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

​選択したクラスとスキーマ構造を確認および検証するために、スキーマのベース構造（クラスによって提供）がキャンバスに表示されます。

人間に適したSchema display nameをテキストフィールドに入力します。 次に、適切な説明を入力して、スキーマを特定します。 スキーマ構造を確認し、設定に満足したら、Finish​を選択してスキーマを作成します。

スキーマの作成 compose-your-schema

Schema Editor が表示されます。これは、スキーマを作成するキャンバスです。セルフタイトル付きのスキーマは、エディターに到着したときに、選択したベースクラスに含まれる標準フィールドとともに、キャンバスの​Structure セクションに自動的に作成されます。 スキーマに割り当てられたクラスは、Class セクションの​ Composition ​にも一覧表示されます。

フィールドグループの追加 field-group

これで、フィールドグループを追加して、スキーマへのフィールドの追加を開始できます。フィールドグループは、特定の概念を記述するために一緒に使用されることが多い 1 つ以上のフィールドから成るグループです。このチュートリアルでは、フィールドグループを使用してロイヤルティプログラムのメンバーを記述し、氏名、生年月日、電話番号、住所などの重要な情報を取り込みます。

フィールドグループを追加するには、Add サブセクションの​ Field groups ​を選択します。

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

左側のパネルでフィルターの 1 つを選択して、標準フィールドグループのリストを特定の業種（小売、金融機関、ヘルスケアなど）に絞り込むことができます。

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

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

このチュートリアルでは、Demographic Details フィールドグループを選択し、Add field group​を選択します。

スキーマキャンバスが再び表示されます。Field groups セクションに「Demographic Details」が一覧表示され、Structure セクションには、フィールドグループによって提供されたフィールドが含まれるようになりました。 Field groups セクションの下でフィールドグループの名前を選択して、キャンバス内で提供される特定のフィールドを強調表示できます。

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

name フィールドのデータ型は"Full name"であり、これは共通の概念を説明し、名前、姓、礼儀タイトル、接尾辞などの名前関連のサブフィールドを含んでいることを意味します。

キャンバス内の様々なフィールドをクリックすると、それらがスキーマ構造に寄与する追加のフィールドが表示されます。

さらなるフィールドグループの追加 field-group-2

これで、同じ手順を繰り返して、別のフィールドグループを追加できるようになりました。今回の​Add field group ダイアログを表示すると、「Demographic Details」フィールドグループがグレー表示され、その横にあるチェックボックスを選択できないことに注意してください。 これにより、現在のスキーマに既に含まれているフィールドグループが誤って複製されるのを防止できます。

このチュートリアルでは、リストから標準フィールドグループ Personal Contact Details​と​ Loyalty Details ​を選択し、Add field groups​を選択してスキーマに追加します。

キャンバスは、Field groups セクションの​ Composition ​にリストされている追加されたフィールドグループと、それらの複合フィールドがスキーマ構造に追加された状態で再び表示されます。

カスタムフィールドグループの定義 define-field-group

Loyalty Members スキーマは、ロイヤルティプログラムのメンバーに関連するデータを取得するためのもので、スキーマに追加した標準のLoyalty Details フィールドグループは、プログラムの種類、ポイント、結合日など、これらのほとんどを提供します。

ただし、場合によっては、ユースケースを達成するために、標準フィールドグループでカバーされない追加のカスタムフィールドを含める必要がある状況も考えられます。 カスタムロイヤルティフィールドを追加する場合は、次の 2 つの選択肢があります。

新しいフィールドグループを作成するには、以前と同様に​Add サブセクションで​ Field groups ​を選択しますが、今回は、表示されるダイアログの上部にある​ Create New Field group ​を選択します。 次に、新しいフィールドグループの表示名と説明を入力するように求められます。 このチュートリアルでは、新しいフィールドグループ「Custom Loyalty Details」に名前を付け、Add field groups​を選択します。

「Custom Loyalty Details」は、キャンバスの左側の​ Field groups ​の下に表示されるようになりましたが、まだ関連付けられているフィールドがないため、Structure​の下に新しいフィールドは表示されません。

フィールドグループにフィールドを追加します。 field-group-fields

これで「Custom Loyalty Details」フィールドグループを作成したので、このフィールドグループがスキーマに提供するフィールドをようやく定義できます。

まず、キャンバスでスキーマ名の横にある​ プラス（＋） ​アイコンを選択します。

「Untitled Field」プレースホルダーがキャンバスに表示され、右側のパネルが更新されて、フィールドの設定オプションが表示されます。

このシナリオでは、スキーマには、人物の現在のロイヤルティ層の詳細を記述するオブジェクトタイプのフィールドが必要です。 右側のパネルのコントロールを使用して、関連するフィールドを保持するために使用するタイプ「loyaltyTier」のObject フィールドの作成を開始します。

Assign to​で、フィールドを割り当てるフィールドグループを選択する必要があります。 すべてのスキーマフィールドはクラスかフィールドグループのどちらかに属していますが、このスキーマは標準クラスを使用しているので、フィールドグループの選択のみ可能です。 「Custom Loyalty Details」という名前を入力し始めると、該当するフィールドグループがリストに表示されるので、それを選択します。

終了したら「Apply」を選択します。

変更内容が適用され、新しく作成された loyaltyTier オブジェクトが表示されます。これはカスタムフィールドなので、組織のテナント ID を名前空間とするオブジェクト内に自動的にネストされ、先頭にアンダースコアが付きます（この例では _tenantId）。

loyaltyTier オブジェクトの横にある​ プラス（＋） ​アイコンを選択して、サブフィールドの追加を開始します。新しいフィールドプレースホルダーが表示され、Field properties セクションがキャンバスの右側に表示されます。

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

loyaltyTier オブジェクトの最初のフィールドは、id という文字列になります。これは、ロイヤルティメンバーの現在の階層の ID を表します。 この会社では、様々な要因に基づいて顧客ごとに異なるロイヤルティ層ポイントしきい値を設定しているので、階層 ID はロイヤルティメンバーごとに一意になります。 新しいフィールドのタイプを「String」に設定すると、Field properties セクションに、デフォルト値、形式、最大長など、制約を適用するためのいくつかのオプションが入力されます。 詳細については、​ データ検証フィールドのベストプラクティス ​に関するドキュメントを参照してください。

id はランダムに生成されるフリーフォーム文字列なので、それ以上の制約は必要ありません。Apply​を選択して変更を適用します。

フィールドグループにさらにフィールドを追加します。 field-group-fields-2

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

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

完了すると、loyaltyTier オブジェクトには id、currentThreshold、nextThreshold、および effectiveDate のフィールドが含まれます。

フィールドグループへの列挙フィールドの追加 enum

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

このチュートリアルでは、スキーマ内の loyaltyTier オブジェクトには、階層クラスを記述する新しい列挙型フィールドが必要です。値は 4 つのオプションのうちいずれかになります。このフィールドをスキーマに追加するには、オブジェクトの横にある プラス（+） loyaltyTier アイコンを選択し、Field name​と​ Display name ​の必須フィールドに入力します。 Type​に「String」を選択します。

フィールドの種類が選択された後、フィールドに追加のチェックボックスが表示されます。これには、Array、Enum & Suggested Values、Identity、Relationship​のチェックボックスが含まれます。

「Enum & Suggested Values」チェックボックスを選択し、「Enum」を選択します。 ここでは、許容されるロイヤルティ層クラスごとに​Value （キャメルケース内）と​Display Name （タイトルケース内のオプションの読みやすい名前）を入力できます。

すべてのフィールドプロパティが完了したら、Apply​を選択してtierClass フィールドをloyaltyTier オブジェクトに追加します。

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

loyaltyTier オブジェクトには複数のフィールドが含まれ、他のスキーマで役立つ共通のデータ構造を表すようになりました。 Schema Editor を使用すると、再利用可能な複数フィールドオブジェクトを簡単に適用できます。そのためには、これらのオブジェクトの構造をデータタイプに変換します。

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

loyaltyTier オブジェクトをデータ型に変換するには、キャンバスのloyaltyTier フィールドを選択し、エディターの右側の​ Convert to new data type ​の下にある​ Field properties ​を選択します。

オブジェクトが正常に変換されたことを確認する通知が表示されます。 キャンバスでは、loyaltyTier フィールドにリンクアイコンが表示され、右側のパネルはデータタイプが「Loyalty Tier」であることを示しています。

今後のスキーマでは、フィールドを「Loyalty Tier」タイプとして割り当てることができ、ID、階層クラス、ポイントしきい値、および発効日のフィールドが自動的に含まれるようになります。

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

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

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

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

スキーマが提供する標準的なデータ構造を利用して、複数のソースから同じ個人に属するデータを識別できるため、セグメント化、レポート、データサイエンス分析など、様々なダウンストリームのユースケースが可能になります。個々のIDに基づいてデータを結合するには、該当するスキーマ内でキーフィールドをIdentity フィールドとしてマークする必要があります。

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

例えば、同じロイヤルティレベルに属するロイヤルティプログラムメンバーが何千人もいる場合や、同じ住所を共有するメンバーが複数存在する場合があります。 ただし、このシナリオでは、登録時に、ロイヤルティプログラムの各メンバーは個人のメールアドレスを入力します。 個人の電子メールアドレスは通常1人で管理されるので、フィールド personalEmail.address （Personal Contact Details フィールドグループが提供）はID フィールドの候補として適しています。

キャンバスでpersonalEmail.address フィールドを選択すると、Identity チェックボックスが​ Field properties ​の下に表示されます。 チェックボックスをオンにして、Primary identity​が表示されるように設定するオプションをオンにします。 このボックスも選択します。

次に、ドロップダウンの定義済み名前空間のリストから​ Identity namespace ​を指定する必要があります。 このフィールドはお客様の電子メールアドレスなので、ドロップダウンから「Email」を選択します。 「Apply」を選択して、personalEmail.address フィールドの更新を確認します。

変更を適用すると、personalEmail.address のアイコンに ID フィールドになったことを示すフィンガープリントマークシンボルが表示されます。このフィールドは、Identities​の下の左側のパネルにも表示されます。

これで、personalEmail.address フィールドに取り込まれたすべてのデータを使用して、その個人を識別し、その顧客の単一のビューを結び付けることができます。Experience Platform での ID の操作について詳しくは、Identity Service のドキュメントを参照してください。

Real-Time Customer Profile で使用するためのスキーマの有効化 profile

Real-Time Customer Profile では、Experience Platform の ID データを活用して各顧客の全体像を提供します。 このサービスは、あらゆる角度からの堅牢な顧客属性プロファイルに加えて、Experience Platform と統合されたあらゆるシステムで顧客が行ってきたすべてのインタラクションのタイムスタンプ付きアカウントを構築します。

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

「ロイヤルティメンバー」スキーマを Profile で使用できるようにするには、まず、キャンバスでスキーマタイトルを選択します。

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

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

Enable​を選択して選択を確定します。 必要に応じて、Profile トグルを再度選択してスキーマを無効にできますが、Profileが有効になっている間にスキーマが保存されると、無効にできなくなります。

その他のアクション more

スキーマエディター内で、スキーマのJSON構造をコピーしたり、スキーマを削除したりするためのクイックアクションを実行することもできます。 ビューの上部にある「More」を選択すると、クイックアクションを含むドロップダウンが表示されます。

スキーマの削除 delete-a-schema

スキーマは、More アクションを使用してスキーマエディターから、またBrowse タブのスキーマの詳細から、UI内で削除できます。 スキーマの削除を妨げる特定の条件があります。 次の場合、スキーマを削除できません：

JSON 構造をコピー copy-json-structure

スキーマライブラリ内の任意のスキーマの書き出しペイロードを生成するには、Copy JSON structure​を選択します。 このアクションは、JSON構造をクリップボードにコピーします。 書き出したJSONを使用して、スキーマと関連リソースを別のサンドボックスまたは組織に読み込むことができます。 これにより、異なる環境間でのスキーマの共有と再利用が簡単で効率的になります。

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

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

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

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

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

ビデオリソース

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

次のビデオは、フィールドグループとクラスの操作に関する理解を深めることを目的としています。

付録

以下の節では、Schema Editor の使用に関する追加情報について説明します。

新しいクラスの作成 create-new-class

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

スキーマクラスの変更 change-class

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

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