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

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

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

はじめに

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

スキーマワークスペースを開く browse

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

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

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

スキーマの作成と命名 create

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

この スキーマを作成 ワークフローが表示されます。 次に、スキーマの基本クラスを選択します。 次のコアクラスから選択できます XDM 個人プロファイル および XDM ExperienceEvent、または その他 これらのクラスが目的に合わない場合。 この その他 「クラス」オプションを使用すると、次のいずれかを実行できます 新しいクラスの作成 または、他の既存のクラスから選択します。

を参照してください。 XDM 個人プロファイル および XDM ExperienceEvent これらのクラスの詳細については、を参照してください。 このチュートリアルでは、を選択します。 XDM 個人プロファイル 続いて 次.

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

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

​キャンバスにスキーマの基本構造（クラスによって提供される）が表示され、選択したクラスとスキーマ構造を確認できます。

人間に優しい スキーマの表示名 「」テキストフィールドに入力します。 次に、スキーマの識別に役立つ適切な説明を入力します。 スキーマ構造をレビューし、設定に満足したら、次を選択します 終了 スキーマを作成します。

Schema Editor が表示されます。これは、スキーマを作成するキャンバスです。自動的に作成された独自のスキーマ 構造 エディターを開いたときに、選択した基本クラスに含まれている標準フィールドと共にキャンバスのセクションに移動します。 スキーマに割り当てられたクラスは、「構成」セクションの「クラス」にもリストされています。

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

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

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

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

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

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

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

このチュートリアルでは、「デモグラフィックの詳細」フィールドグループを選択し、次に「フィールドグループを追加」をクリックします。

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

このフィールドグループでは、データタイプが「ユーザー」の最上位の名前 person の下にいくつかのフィールドが提供されます。このフィールドグループは、名前、生年月日、性別など、個人に関する情報を説明します。

name フィールドのデータタイプは「フルネーム」であることに注意してください。これは一般的な概念を表しており、名、姓、敬称、接尾辞など、名前に関連するサブフィールドを含みます。

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

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

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

このチュートリアルでは、標準フィールドグループである​ 個人の連絡先の詳細 ​と​ ロイヤルティの詳細 ​をリストから選択したあと、「フィールドグループを追加」を選択してこれらのフィールドグループをスキーマに追加します。

キャンバスが再び表示され、追加したフィールドグループが「構成」セクションの「フィールドグループ」にリストされます。また、スキーマ構造に追加されたそれらの複合フィールドも表示されます。

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

ロイヤルティメンバースキーマは、ロイヤルティプログラムのメンバーに関連するデータを取り込むためのもので、スキーマに追加した標準のロイヤルティの詳細フィールドグループは、プログラムタイプ、ポイント、加入日など、これらのほとんどを提供します。

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

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

これで、キャンバスの左側にある「フィールドグループ」に「Custom Loyalty Details」が表示されますが、まだフィールドは関連付けられていないので、「構造」には新しいフィールドは表示されません。

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

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

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

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

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

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

完了したら、「適用」を選択します。

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

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

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

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

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

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

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

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

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

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

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

このチュートリアルでは、スキーマ内の loyaltyTier オブジェクトには、階層クラスを記述する新しい列挙型フィールドが必要です。値は 4 つのオプションのうちいずれかになります。このフィールドをスキーマに追加するには、loyaltyTier オブジェクトの横にある​ プラス (+) アイコンを選択し、フィールド名 ​および​ 表示名 ​の必須フィールドに入力します。タイプ ​の場合、「文字列」を選択します。

タイプを選択すると、フィールドに対して追加のチェックボックスが表示されます。これには、配列、列挙と推奨値、ID、および​ 関係 ​のチェックボックスが含まれます。

列挙と推奨値 ​チェックボックスをオンにして、「列挙」を選択します。 ここで、許容可能な各ロイヤルティ階層クラスの​ 値（キャメルケース）と​ 表示名（オプション。単語の先頭のみ大文字で書かれた読みやすい名前）を入力できます。

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

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

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

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

loyaltyTier オブジェクトをデータタイプに変換するには、キャンバスで loyaltyTier フィールドを選択し、エディターの右側にある「フィールドプロパティ」の下にある「新しいデータタイプに変換」を選択します。

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

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

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

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

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

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

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

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

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

キャンバスで personalEmail.address フィールドを選択すると、フィールドのプロパティ ​の下に ID のチェックボックスが表示されます。チェックボックスをオンにすると、これを​ プライマリ ID として設定するオプションが表示されます。このボックスも選択します。

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

変更を適用すると、personalEmail.address のアイコンに ID フィールドになったことを示す指紋記号が表示されます。このフィールドは、ID の下の左側のレールにも表示されます。

これで、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 が有効になっている場合にスキーマを保存すると、無効にできなくなります。

その他のアクション more

スキーマエディター内で、クイックアクションを実行して、スキーマの JSON 構造をコピーしたり、スキーマを削除したりできます。 を選択 詳細 ビューの上部に、クイックアクションを含むドロップダウンを表示します。

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

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

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

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

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

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

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

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

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

ビデオリソース

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

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

付録

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

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

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

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

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

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