Schema Editor を使用したスキーマの作成
Adobe Experience Platform ユーザーインターフェイスを使用すると、Schema Editor と呼ばれるインタラクティブなビジュアルキャンバスで Experience Data Model(XDM)スキーマを作成および管理できます。 このチュートリアルでは、Schema Editor を使用してスキーマを作成する方法について説明します。
デモンストレーションを目的として、このチュートリアルの手順には、顧客ロイヤルティプログラムのメンバーを記述するサンプルスキーマの作成が含まれています。 これらの手順を使用して、異なるスキーマを独自の用途で作成できますが、まずは、サンプルスキーマの作成方法を追って Schema Editor の機能を理解することをお勧めします。
はじめに
このチュートリアルを実行するには、スキーマの作成に関する Adobe Experience Platform の様々な側面を実践的に理解している必要があります。 このチュートリアルを始める前に、次の概念に関するドキュメントを確認してください。
- Experience Data Model (XDM):Experience Platform が、カスタマーエクスペリエンスデータを整理する際に使用する、標準化されたフレームワーク。
- スキーマ作成の基本:クラス、スキーマフィールドグループ、データタイプ、個々のフィールドなど、XDM スキーマとその構成要素の概要。
- Real-Time Customer Profile:複数のソースから集計したデータに基づいて、統合されたリアルタイム顧客プロファイルを提供します。
スキーマ ワークスペースを開く browse
Experience Platform UIの スキーマ ワークスペースを使用して、組織で使用可能なスキーマを表示および管理します。 ワークスペースにはSchema Editorも含まれており、このチュートリアル全体を通してスキーマを作成および編集できます。
Experience Platformにログインしたら、左側のナビゲーションで「スキーマ」を選択して、スキーマ ワークスペースを開きます。 「参照」タブには、表示およびカスタマイズするスキーマのリスト(Schema Libraryの表現)が表示されます。 このリストには、スキーマの基になる名前、タイプ、クラスおよび動作(レコードまたは時系列)のほか、スキーマが最後に変更された日時が含まれます。
詳しくは、UI での既存の XDM リソースの調査に関するガイドを参照してください。
スキーマの作成と命名 create
スキーマの作成を開始するには、スキーマ ワークスペースの右上隅にある「スキーマを作成」を選択します。
「 スキーマを作成」ダイアログが表示されます。 このダイアログでは、フィールドとフィールドグループを追加してスキーマを手動で作成するか、CSV ファイルをアップロードしてML アルゴリズムを使用してスキーマを生成するかを選択できます。 ダイアログからスキーマ作成ワークフローを選択します。
[Beta]{class="badge informative"}手動またはML支援のスキーマ作成 manual-or-assisted
マシンラーニングアルゴリズムを使用して、アップロードされたファイルに基づくスキーマ構造を推奨する方法については、機械学習を支援するスキーマ作成ガイド を参照してください。 このUI ガイドでは、手動作成ワークフローに焦点を当てます。
基本クラスの選択 choose-a-class
スキーマの作成 ワークフローが表示されます。 次に、スキーマのベースクラスを選択します。 XDM Individual ProfileとXDM ExperienceEventのコアクラス、またはこれらのクラスが目的に合わない場合はOtherのいずれかを選択できます。 「その他 クラス」オプションを使用すると、新しいクラスを作成するか、既存の他のクラスから選択できます。
これらのクラスについて詳しくは、XDM個人プロファイル およびXDM ExperienceEventのドキュメントを参照してください。 このチュートリアルの目的では、XDM Individual Profileを選択し、その後 Next を選択します。
命名とレビュー name-and-review
クラスを選択すると、「名前とレビュー」セクションが表示されます。 このセクションでは、スキーマを識別するための名前と説明を指定します。 スキーマの名前を決定する際に考慮すべき重要な点がいくつかあります。
- 後でスキーマを簡単に見つけられるように、スキーマ名は短くわかりやすい名前にしてください。
- スキーマ名は一意である必要があります。つまり、将来再利用されないように十分に具体的でなければなりません。 例えば、組織が異なるブランドに対して別々のロイヤルティプログラムを持つ場合、後で定義する他のロイヤルティ関連スキーマと区別しやすいように、スキーマに「ブランド A ロイヤルティメンバー」という名前を付けると効果的です。
- また、スキーマの説明を使用して、スキーマに関する追加のコンテキスト情報を提供することもできます。
このチュートリアルでは、ロイヤルティプログラムのメンバーに関連するデータを取り込むスキーマを作成するので、スキーマの名前は「Loyalty Members」とします。
選択したクラスとスキーマ構造を確認および検証するために、スキーマのベース構造(クラスによって提供)がキャンバスに表示されます。
人間に適した スキーマ表示名をテキストフィールドに入力します。 次に、適切な説明を入力して、スキーマを特定します。 スキーマ構造を確認し、設定に満足したら、終了を選択してスキーマを作成します。
![ スキーマ表示名]、説明、完了がハイライト表示された スキーマを作成 ワークフローの名前とレビュー セクション。(…/images/ui/resources/schemas/name-and-review.png)
スキーマの作成 compose-your-schema
Schema Editor が表示されます。 これは、スキーマを作成するキャンバスです。 セルフタイトル付きのスキーマは、エディターに到着したときに、選択したベースクラスに含まれる標準フィールドとともに、キャンバスの構造 セクションに自動的に作成されます。 スキーマに割り当てられたクラスは、構成 セクションの クラス にも一覧表示されます。
フィールドグループの追加 field-group
これで、フィールドグループを追加して、スキーマへのフィールドの追加を開始できます。 フィールドグループは、特定の概念を記述するために一緒に使用されることが多い 1 つ以上のフィールドから成るグループです。 このチュートリアルでは、フィールドグループを使用してロイヤルティプログラムのメンバーを記述し、氏名、生年月日、電話番号、住所などの重要な情報を取り込みます。
フィールドグループを追加するには、フィールドグループ サブセクションの 追加 を選択します。
新しいダイアログが表示され、使用可能なフィールドグループのリストが表示されます。 各フィールドグループは特定のクラスでのみ使用できるものなので、ダイアログには、選択したクラス(この場合は、XDM Individual Profile クラス)に適合するフィールドグループのみがリストされます。 標準の XDM クラスを使用している場合、フィールドグループのリストは使用頻度に基づいてインテリジェントに並べ替えられます。
左側のパネルでフィルターの 1 つを選択して、標準フィールドグループのリストを特定の業種(小売、金融機関、ヘルスケアなど)に絞り込むことができます。
リストからフィールドグループを選択すると、右側のパネルに表示されます。 必要に応じて複数のフィールドグループを選択し、各グループを右側のレールのリストに追加してから確認することができます。 また、現在選択されているフィールドグループの右側にアイコンが表示され、提供されるフィールドの構造をプレビューできます。
フィールドグループをプレビューする際に、右側のパネルに、フィールドグループのスキーマに関する詳細な説明が表示されます。 また、提供されたキャンバスでフィールドグループのフィールド間を移動することもできます。 別のフィールドを選択すると、右側のパネルが更新され、該当するフィールドの詳細が表示されます。 プレビューが終了したら、戻るを選択して、フィールドグループ選択ダイアログに戻ります。
このチュートリアルでは、デモグラフィックの詳細 フィールドグループを選択し、フィールドグループを追加を選択します。
スキーマキャンバスが再び表示されます。 フィールドグループ セクションに「 デモグラフィックの詳細」が一覧表示され、構造 セクションには、フィールドグループによって提供されたフィールドが含まれるようになりました。 「フィールドグループ」セクションでフィールドグループの名前を選択すると、キャンバス内で提供される特定のフィールドを強調表示できます。
このフィールドグループは、トップレベル名personの下にデータタイプ「人物」を持つ複数のフィールドを提供します。 このフィールドグループは、名前、生年月日、性別など、個人に関する情報を説明します。
name フィールドのデータ型が「 フルネーム 」であり、共通の概念を説明し、名前、姓、礼儀名、接尾辞などの名前関連のサブフィールドが含まれていることに注意してください。
キャンバス内の様々なフィールドをクリックすると、それらがスキーマ構造に寄与する追加のフィールドが表示されます。
さらなるフィールドグループの追加 field-group-2
これで、同じ手順を繰り返して、別のフィールドグループを追加できるようになりました。 今回、フィールドグループを追加 ダイアログを表示する際に、「 デモグラフィックの詳細」フィールドグループがグレー表示され、その横にあるチェックボックスを選択できないことに注意してください。 これにより、現在のスキーマに既に含まれているフィールドグループが誤って複製されるのを防止できます。
このチュートリアルでは、リストから標準フィールドグループ 個人連絡先の詳細と ロイヤルティの詳細 を選択し、フィールドグループを追加を選択してスキーマに追加します。
キャンバスは、コンポジション セクションの フィールドグループ の下に追加されたフィールドグループと、それらの複合フィールドがスキーマ構造に追加された状態で再び表示されます。
カスタムフィールドグループの定義 define-field-group
ロイヤルティメンバー スキーマは、ロイヤルティプログラムのメンバーに関連するデータを取得するためのもので、スキーマに追加した標準の ロイヤルティの詳細 フィールドグループは、プログラムの種類、ポイント、結合日など、これらのほとんどを提供します。
ただし、場合によっては、ユースケースを達成するために、標準フィールドグループでカバーされない追加のカスタムフィールドを含める必要がある状況も考えられます。 カスタムロイヤルティフィールドを追加する場合は、次の 2 つの選択肢があります。
- 新しいカスタムフィールドグループを作成して、これらのフィールドを取り込みます。 この方法については、このチュートリアルで説明します。
- カスタムフィールドを使用して、標準の ロイヤルティの詳細 フィールドグループを拡張します。 これにより、 ロイヤルティの詳細がカスタムフィールドグループに変換され、元の標準フィールドグループは使用できなくなります。 標準フィールドグループ 🔗の構造にカスタムフィールドを追加するについて詳しくは、 スキーマ UI ガイドを参照してください。
新しいフィールドグループを作成するには、以前と同様にフィールドグループ サブセクションで 追加 を選択しますが、今回は、表示されるダイアログの上部にある 新しいフィールドグループを作成 を選択します。 次に、新しいフィールドグループの表示名と説明を入力するように求められます。 このチュートリアルでは、新しいフィールドグループ「Custom Loyalty Details」に名前を付け、フィールドグループを追加を選択します。
![新しいフィールドグループを作成、表示名および説明がハイライト表示された フィールドグループを追加 ダイアログ。]
「Custom Loyalty Details」は、キャンバスの左側の フィールドグループ の下に表示されるようになりましたが、まだフィールドが関連付けられていないため、構造の下に新しいフィールドは表示されません。
フィールドグループにフィールドを追加します。 field-group-fields
これで「Custom Loyalty Details」フィールドグループを作成したので、このフィールドグループがスキーマに提供するフィールドをようやく定義できます。
まず、キャンバスでスキーマ名の横にある プラス(+) アイコンを選択します。
「名称未設定のフィールド 」プレースホルダーがキャンバスに表示され、右側のパネルが更新されて、フィールドの設定オプションが表示されます。
このシナリオでは、スキーマには、人物の現在のロイヤルティ層の詳細を記述するオブジェクトタイプのフィールドが必要です。 右側のパネルのコントロールを使用して、関連するフィールドを保持するために使用するタイプ「 オブジェクト 」のloyaltyTier フィールドの作成を開始します。
割り当て先で、フィールドを割り当てるフィールドグループを選択する必要があります。 すべてのスキーマフィールドはクラスかフィールドグループのどちらかに属していますが、このスキーマは標準クラスを使用しているので、フィールドグループの選択のみ可能です。 「Custom Loyalty Details」という名前を入力し始めると、該当するフィールドグループがリストに表示されるので、それを選択します。
完了したら、適用を選択します。
変更内容が適用され、新しく作成された loyaltyTier オブジェクトが表示されます。 これはカスタムフィールドなので、組織のテナント ID を名前空間とするオブジェクト内に自動的にネストされ、先頭にアンダースコアが付きます(この例では _tenantId)。
loyaltyTier オブジェクトの横にある プラス(+) アイコンを選択して、サブフィールドの追加を開始します。 新しいフィールドプレースホルダーが表示され、キャンバスの右側に「フィールドプロパティ」セクションが表示されます。
各フィールドには、次の情報が必要です。
- フィールド名: フィールドの名前(できればcamelCaseで記述)。 スペース文字は使用できません。 これは、コード内および他のダウンストリームアプリケーションでフィールドを参照するために使用される名前です。
- 例:loyaltyLevel
- 表示名: タイトルケースで書かれたフィールドの名前。 これは、スキーマの表示または編集時にキャンバスに表示される名前です。
- 例:Loyalty Level
- Type: フィールドのデータ型。 これには、基本的なスカラータイプと、Schema Registry に定義されている任意のデータタイプが含まれます。 例:String、Integer、Boolean、Person、Address、電話番号など
- 説明: フィールドの説明は、オプションで最大200文字まで含める必要があります。
loyaltyTier オブジェクトの最初のフィールドは、id という文字列になります。これは、ロイヤルティメンバーの現在の階層の ID を表します。 この会社では、様々な要因に基づいて顧客ごとに異なるロイヤルティ層ポイントしきい値を設定しているので、階層 ID はロイヤルティメンバーごとに一意になります。 新しいフィールドのタイプを「文字列」に設定すると、フィールドプロパティ セクションに、形式、最大長、デフォルト値などの追加オプションが追加されます。 取り込みの検証が必要な場合は、形式と長さの設定を使用します。 デフォルト値は、情報スキーマのメタデータのみを記録し、取り込み中またはデータ準備フロー中に自動的に適用されません。 タイプ固有のフィールドプロパティ を参照してください。
id はランダムに生成されるフリーフォーム文字列なので、それ以上の制約は必要ありません。 適用を選択して変更を適用します。
フィールドグループにさらにフィールドを追加します。 field-group-fields-2
id フィールドを追加したら、次のようなロイヤルティ層の情報を取り込むためのその他のフィールドを追加できます。
- 現在のポイントしきい値(整数):メンバーが現在の階層に留まるために維持する必要があるロイヤルティポイントの最小数。
- 次の階層ポイントのしきい値(整数):メンバーが次の階層に進むために獲得しなければならないロイヤルティポイントの数。
- 発効日(日時):ロイヤルティメンバーがこの階層に参加した日付。
各フィールドをスキーマに追加するには、loyalty オブジェクトの横にあるプラス(+) アイコンを選択し、必要な情報を入力します。
完了すると、loyaltyTier オブジェクトには id、currentThreshold、nextThreshold、および effectiveDate のフィールドが含まれます。
フィールドグループへの列挙フィールドの追加 enum
Schema Editor でフィールドを定義する場合、フィールドに含めることができるデータにさらに制約を加えるために、基本的なフィールドタイプに適用できるいくつかの追加オプションがあります。 これらの制約のユースケースを次の表で説明します。
このチュートリアルでは、スキーマ内の loyaltyTier オブジェクトには、階層クラスを記述する新しい列挙型フィールドが必要です。値は 4 つのオプションのうちいずれかになります。 このフィールドをスキーマに追加するには、loyaltyTier オブジェクトの横にあるプラス(+) アイコンを選択し、フィールド名および 表示名 の必須フィールドに入力します。 Typeで、「文字列」を選択します。
そのタイプが選択された後、フィールドに追加のチェックボックスが表示されます。これには、配列、列挙と推奨値、ID、関係のチェックボックスが含まれます。
「列挙と推奨値」チェックボックスを選択し、列挙を選択します。 ここでは、許容されるロイヤルティ層クラスごとにValue (キャメルケース内)とDisplay Name (タイトルケース内のオプションの読みやすい名前)を入力できます。
すべてのフィールドプロパティを完了したら、適用を選択して、tierClass フィールドをloyaltyTier オブジェクトに追加します。
複数フィールドオブジェクトのデータタイプへの変換 datatype
loyaltyTier オブジェクトには複数のフィールドが含まれ、他のスキーマで役立つ共通のデータ構造を表すようになりました。 Schema Editor を使用すると、再利用可能な複数フィールドオブジェクトを簡単に適用できます。そのためには、これらのオブジェクトの構造をデータタイプに変換します。
データタイプを使用すると、複数フィールド構造を一貫して使用でき、フィールドグループよりも柔軟性が高まります。これは、データタイプがスキーマ内のどこでも使用できるからです。 これは、フィールドの Type の値を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 フィールドの候補として適しています。
identityMap フィールドを使用して ID 情報を格納することもできます。identityMap を使用する予定がある場合は、スキーマに直接追加するプライマリ ID を上書きすることに注意してください。 詳しくは、スキーマ構成の基本ガイドの identityMap の節を参照してください。キャンバスでpersonalEmail.address フィールドを選択すると、ID チェックボックスが フィールドプロパティ の下に表示されます。 チェックボックスをオンにし、これを プライマリ ID として設定するオプションが表示されます。 このボックスも選択します。
次に、ドロップダウンの定義済み名前空間のリストから ID名前空間 を指定する必要があります。 このフィールドはお客様のメールアドレスなので、ドロップダウンから「Email」を選択します。 「適用」を選択して、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
スキーマエディターから詳細 アクションを使用するか、参照 タブのスキーマの詳細ビューからスキーマを削除できます。 次の場合は、スキーマを削除できません。
- このスキーマはプロファイルに対して有効になっています。
- スキーマはプロファイルに対して有効になっており、関連するデータセットがあります。
- スキーマに関連付けられたデータセットがありますが、プロファイルに対しては有効になっていません。
JSON 構造をコピー copy-json-structure
スキーマライブラリ内の任意のスキーマのエクスポートペイロードを生成するには、JSON構造をコピーを選択します。 このアクションは、JSON構造をクリップボードにコピーします。 書き出したJSONを使用して、スキーマと関連リソースを別のサンドボックスまたは組織に読み込むことができます。 これにより、異なる環境間でのスキーマの共有と再利用が簡単で効率的になります。
次の手順とその他のリソース
これで、スキーマの作成が完了したので、キャンバスに完全なスキーマが表示されます。 保存を選択すると、スキーマは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 でのスキーマの管理に関するガイドを参照してください。