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 アルゴリズムを使用してスキーマを生成するかを選択できます。 ダイアログからスキーマ作成ワークフローを選択します。

[ベータ版]{class="badge informative"} 手動 または ML 支援によるスキーマ作成 manual-or-assisted

ML アルゴリズムを使用して、アップロードされたファイルに基づいてスキーマ構造をレコメンデーションする方法については、​ 機械学習を利用したスキーマ作成ガイド ​ を参照してください。 この 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 (camelCaseの場合)と 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

スキーマは、UI 内で、More のアクションを使用してスキーマエディターから、また「Browse」タブのスキーマの詳細から削除できます。 スキーマを削除できない条件もあります。 次の場合、スキーマは削除できません。

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