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

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

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

NOTE
CSV データをExperience Platformに取り込む場合、スキーマを手動で作成しなくても、そのデータをAIが生成した推奨事項 (現在ベータ版)によって作成されたXDM スキーマにマッピングできます。
Schema Registry API を使用してスキーマを作成する場合は、まずSchema Registry 開発者ガイドを参照してから、API を使用したスキーマの作成に関するチュートリアルを試してください。

はじめに

このチュートリアルを実行するには、スキーマの作成に関する 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 ​を選択します。

XDM個人プロファイル ​ オプションと次が強調表示された​ スキーマの作成 ワークフロー。

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

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

  • 後でスキーマを簡単に見つけられるように、スキーマ名は短くわかりやすい名前にしてください。
  • スキーマ名は一意である必要があります。つまり、将来再利用されないように十分に具体的でなければなりません。 例えば、組織が異なるブランドに対して別々のロイヤルティプログラムを持つ場合、後で定義する他のロイヤルティ関連スキーマと区別しやすいように、スキーマに「ブランド A ロイヤルティメンバー」という名前を付けると効果的です。
  • また、スキーマの説明を使用して、スキーマに関する追加のコンテキスト情報を提供することもできます。

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

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

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

![ スキーマ表示名]、説明、完了がハイライト表示された​ スキーマを作成 ワークフローの名前とレビュー セクション。(…/images/ui/resources/schemas/name-and-review.png)

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

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

NOTE
スキーマの表示名とオプションの説明は、スキーマプロパティ サイドバーから更新できます。 新しい名前を入力すると、キャンバスが自動的に更新され、スキーマの新しい名前が反映されます。

基本クラスとスキーマ図がハイライト表示されたスキーマエディター。

NOTE
スキーマが保存される前の初期構成プロセスにおける任意の時点でスキーマのクラスを変更できますが、その場合は細心の注意を払って行ってください。 フィールドグループは特定のクラスにのみ適合するので、クラスを変更すると、キャンバスと追加したフィールドがリセットされます。

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

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

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

​ フィールドグループを追加ボタンが強調表示されたスキーマエディター。

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

​ フィールドグループを追加​ ダイアログ ​。

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

業界フィールドグループがハイライト表示された​ フィールドグループを追加 ダイアログ。

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

選択したフィールドグループのプレビューアイコンがハイライト表示された​ フィールドグループを追加 ダイアログ。

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

​ デモグラフィックの詳細フィールドグループがプレビューされた​ フィールドグループのプレビュー ダイアログ。

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

​ デモグラフィックの詳細フィールドグループを選択し、​ フィールドグループを追加を強調表示した​ フィールドグループを追加 ダイアログ。

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

​ デモグラフィックの詳細フィールドグループがハイライト表示されたスキーマエディター。

NOTE
スキーマエディター内では、標準(Adobeで生成された)クラスとフィールドグループが、南京錠アイコン( 南京錠アイコン( )で示されます。南京錠は、クラス名またはフィールドグループ名の横にある左側のパネルと、システム生成リソースの一部であるスキーマダイアグラム内の任意のフィールドの横に表示されます。
南京錠アイコンがハイライト表示されたスキーマエディター

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

NOTE
フィールドでは、スカラータイプ(文字列、整数、配列、日付など)のほかに、Schema Registry 内で定義されている任意のデータタイプ(一般的な概念を表すフィールドのグループ)も使用できることを覚えておいてください。

name フィールドのデータ型が「​ フルネーム ​」であり、共通の概念を説明し、名前、姓、礼儀名、接尾辞などの名前関連のサブフィールドが含まれていることに注意してください。

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

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

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

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

2つの新しいフィールドグループを選択し、​ フィールドグループを追加がハイライト表示された​ フィールドグループを追加 ダイアログ。

キャンバスは、コンポジション セクションの​ フィールドグループ ​の下に追加されたフィールドグループと、それらの複合フィールドがスキーマ構造に追加された状態で再び表示されます。

新しい複合スキーマ構造がハイライト表示されたスキーマエディター。

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

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

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

  1. 新しいカスタムフィールドグループを作成して、これらのフィールドを取り込みます。 この方法については、このチュートリアルで説明します。
  2. カスタムフィールドを使用して、標準の​ ロイヤルティの詳細 フィールドグループを拡張します。 これにより、​ ロイヤルティの詳細がカスタムフィールドグループに変換され、元の標準フィールドグループは使用できなくなります。 標準フィールドグループ 🔗の構造にカスタムフィールドを追加するについて詳しくは、​ スキーマ ​ UI ガイドを参照してください。

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

![新しいフィールドグループを作成、表示名および説明がハイライト表示された​ フィールドグループを追加 ダイアログ。]

NOTE
クラス名の場合と同様に、フィールドグループ名は簡潔かつシンプルで、フィールドグループがスキーマにどのように寄与するかがよくわかるものにしてください。 これらも一意なので、名前を再利用できません。名前が十分に具体的なものになるようにしてください。

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

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

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

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

​ プラスアイコンがハイライト表示されたスキーマエディター。

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

名称未設定の​ フィールド ​とスキーマ ​ フィールドプロパティ ​が強調表示されたスキーマエディター。

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

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

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

​ ロイヤルティ層オブジェクトがスキーマに追加されたスキーマエディター​ フィールドプロパティ ​が強調表示されています。

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

​ スキーマ図でテナント IDとロイヤルティ層がハイライト表示されているスキーマエディター。

NOTE
テナント ID オブジェクトの存在は、追加しようとしているフィールドが組織の名前空間に含まれていることを示しています。
つまり、追加しようとしているフィールドは組織に固有のもので、組織のみがアクセスできる特定の領域にある Schema Registry に保存されることになります。 他の標準クラス、フィールドグループ、データタイプおよびフィールドの名前との競合を防ぐために、定義するフィールドは、必ずテナント名前空間に追加する必要があります。

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

​ テナント IDと新しいサブフィールドを含むスキーマエディターが、スキーマダイアグラムのロイヤルティ層に追加されました。

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

  • フィールド名: フィールドの名前(できればcamelCaseで記述)。 スペース文字は使用できません。 これは、コード内および他のダウンストリームアプリケーションでフィールドを参照するために使用される名前です。
    • 例:loyaltyLevel
  • 表示名: タイトルケースで書かれたフィールドの名前。 これは、スキーマの表示または編集時にキャンバスに表示される名前です。
    • 例:Loyalty Level
  • Type: フィールドのデータ型。 これには、基本的なスカラータイプと、Schema Registry に定義されている任意のデータタイプが含まれます。 例:String、Integer、Boolean、Person、Address、電話番号など
  • 説明: フィールドの説明は、オプションで最大200文字まで含める必要があります。

loyaltyTier オブジェクトの最初のフィールドは、id という文字列になります。これは、ロイヤルティメンバーの現在の階層の ID を表します。 この会社では、様々な要因に基づいて顧客ごとに異なるロイヤルティ層ポイントしきい値を設定しているので、階層 ID はロイヤルティメンバーごとに一意になります。 新しいフィールドのタイプを「文字列」に設定すると、フィールドプロパティ セクションに、形式最大長デフォルト値​などの追加オプションが追加されます。 取り込みの検証が必要な場合は、形式​と長さの設定を使用します。 デフォルト値​は、情報スキーマのメタデータのみを記録し、取り込み中またはデータ準備フロー中に自動的に適用されません。 ​ タイプ固有のフィールドプロパティ ​を参照してください。

新しいID フィールドの取り込み検証とデフォルト値フィールドのプロパティが強調表示されたスキーマエディター。

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

ID フィールドを含むスキーマエディターが追加され、強調表示されます。

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

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

  • 現在のポイントしきい値(整数):メンバーが現在の階層に留まるために維持する必要があるロイヤルティポイントの最小数。
  • 次の階層ポイントのしきい値(整数):メンバーが次の階層に進むために獲得しなければならないロイヤルティポイントの数。
  • 発効日(日時):ロイヤルティメンバーがこの階層に参加した日付。

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

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

​ ロイヤルティ層オブジェクトがハイライト表示されたスキーマエディター。

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

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

制約
説明
必須
データの取得にフィールドが必須であることを示します。 このフィールドを含まないデータセットに基づいてスキーマセットにアップロードされたデータの取り込みは失敗します。
配列
フィールドに値の配列が含まれ、各値は指定されたデータタイプを持つことを示します。 例えば、「String」というデータ型を持つフィールドに対してこの制約を使用すると、フィールドに文字列の配列が含まれることを指定します。
列挙と推奨値
このフィールドに、可能な値の列挙リストの値の 1 つを含める必要があることを示します。 または、このオプションを使用して、フィールドをそれらの値に制限することなく、文字列フィールドの推奨値のリストを提供することもできます。
ID
このフィールドが ID フィールドであることを示します。 ID フィールドの詳細については、このチュートリアルの後半で説明します。
関係
スキーマの関係は、結合スキーマと Real-Time Customer Profile を使用して推論できますが、同じクラスを共有するスキーマにのみ適用されます。 関係制約は、このフィールドが異なるクラスに基づくスキーマのプライマリ IDを参照し、2つのスキーマ間の関係を意味することを示します。 詳しくは、関係の定義に関するチュートリアルを参照してください。
NOTE
必須フィールド、IDフィールド、関係フィールドは、左側のパネルの各セクションに表示され、スキーマの複雑さに関係なく、これらのフィールドを簡単に見つけることができます。

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

階層クラスオブジェクトを含むスキーマエディターが​ フィールドプロパティ ​で追加され、強調表示されます。

そのタイプが選択された後、フィールドに追加のチェックボックスが表示されます。これには、配列列挙と推奨値ID関係​のチェックボックスが含まれます。

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

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

列挙と提案の値フィールドのプロパティが完了し、適用が強調表示されます。

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

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

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

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

loyaltyTier オブジェクトを含むスキーマエディターと新しいデータタイプに変換が強調表示されています。

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

loyaltyTier オブジェクトと新しい表示名がハイライト表示されたスキーマエディター。

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

NOTE
また、スキーマの編集とは別に、カスタムデータタイプの作成や編集を行うこともできます。 詳しくは、データタイプの作成と編集に関するガイドを参照してください。

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

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

​ スキーマ図のサイズを縮小するために、スキーマ エディターのフィールド グループ セクションで選択した一部のチェックボックス。

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

関連する結果がキャンバスに強調表示されたスキーマエディターの検索フィールド。

IMPORTANT
検索機能では、一致するフィールドを表示する際に、選択したフィールドグループのフィルターを考慮に入れます。 検索クエリで期待した結果が表示されない場合は、関連するフィールドグループを除外していないことを再確認する必要があります。

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

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

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

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

IMPORTANT
以下の手順では、既存のスキーマフィールドに ID 記述子を追加する方法について説明します。 スキーマ自体の構造の中で ID フィールドを定義する代わりに、identityMap フィールドを使用して ID 情報を格納することもできます。
identityMap を使用する予定がある場合は、スキーマに直接追加するプライマリ ID を上書きすることに注意してください。 詳しくは、スキーマ構成の基本ガイドidentityMap の節を参照してください。

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

NOTE
各スキーマには、1 つのプライマリ ID フィールドのみを含めることができます。 スキーマフィールドをプライマリ ID として設定した場合、後でスキーマ内の別の ID フィールドをプライマリとして設定しようとすると、エラーメッセージが表示されます。

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

電子メールアドレスが強調表示され、プライマリ ID チェックボックスが有効になっているスキーマエディター。

NOTE
標準名前空間のリストとその定義については、Identity Service ドキュメントを参照してください。

変更を適用すると、personalEmail.address のアイコンに ID フィールドになったことを示すフィンガープリントマークシンボルが表示されます。 フィールドは、左側のパネルの​ 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 を定義せずにスキーマを有効にしようとすると、エラーメッセージが表示されます。

見つからないプライマリ ID ダイアログ。

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

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

​ スキーマ ルートとプロファイルの有効化トグルがハイライト表示されたスキーマ エディター。

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

​ プロファイルの有効化の確認ダイアログ。

WARNING
スキーマを Real-Time Customer Profile に対して有効にして保存したら、無効にはできません。

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

その他のアクション more

NOTE
XDM リソースを操作する場合、インベントリテーブル(行メニュー)とリソース詳細ビュー(詳細)の両方からアクションを使用できます。 削除JSON構造のコピーパッケージに追加​など、アクションの完全なセットにアクセスするには、カスタム(テナント定義)リソースを選択する必要があります。 標準(Adobeが提供する)リソースのアクションは限られています。 アクション、制約、権限の概要については、​ スキーマ、クラス、フィールドグループ、およびデータ型の管理:アクションと削除を参照してください。

スキーマエディター内で、スキーマの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 開発者ガイドを参照してください。

ビデオリソース

WARNING
次のビデオに示す Experience Platform UI は旧式のものです。 最新の UI のスクリーンショットと機能については、上記のドキュメントを参照してください。

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

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

付録

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

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

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

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

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

WARNING
スキーマのクラスの再割り当ては、細心の注意を払って行う必要があります。 フィールドグループは特定のクラスにのみ適合するので、クラスを変更すると、キャンバスと追加したフィールドがリセットされます。

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

recommendation-more-help
experience-platform-help-xdm