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

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

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

NOTE
CSV データを Platform に取り込む場合は、そのデータを、AI 生成のレコメンデーションツール(現在はベータ版)で作成された XDM スキーマにマッピングできます。その際、スキーマを手動で作成する必要はありません。
Schema Registry API を使用してスキーマを作成する場合は、まずSchema Registry 開発者ガイドを参照してから、API を使用したスキーマの作成に関するチュートリアルを試してください。

はじめに

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

  • Experience Data Model (XDM):Platform が、カスタマーエクスペリエンスデータを整理する際に使用する、標準化されたフレームワーク。
    • スキーマ作成の基本:クラス、スキーマフィールドグループ、データタイプ、個々のフィールドなど、XDM スキーマとその構成要素の概要。
  • Real-Time Customer Profile:複数のソースから集計したデータに基づいて、統合されたリアルタイム顧客プロファイルを提供します。

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

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

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

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

スキーマの作成と命名 create

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

スキーマ ワークスペース 参照 タブ スキーマを作成 がハイライト表示されています。

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

ワークフローオプションと「選択」がハイライト表示されたスキーマを作成ダイアログ

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

ML アルゴリズムを使用して、アップロードされたファイルに基づいてスキーマ構造をレコメンデーションする方法については、 機械学習を利用したスキーマ作成ガイドを参照してください。 この UI ガイドは、手動作成ワークフローを中心としています。

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

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

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

XDM 個人プロファイル オプションと 次へ がハイライト表示された スキーマを作成 ワークフロー

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

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

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

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

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

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

スキーマ表示名 、 説明 、および 完了 がハイライト表示された スキーマを作成 ワークフローの 名前とレビュー セクション

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

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

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

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

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

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

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

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

「フィールドグループを追加」ボタンがハイライト表示されたスキーマエディター。

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

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

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

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

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

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

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

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

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

![ デモグラフィックの詳細フィールドグループが選択され ]​ フィールドグループを追加 ​ がハイライト表示された ​ フィールドグループを追加」ダイアログ ​

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

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

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

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

NOTE
フィールドではスカラータイプを使用する場合があることに注意してください (such 文字列、整数、配列または日付)、および任意のデータタイプ (a Schema Registry 内で定義される共通の概念を表すフィールドのグループ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

名称未設定フィールド とスキーマ フィールドプロパティ がハイライト表示されたスキーマエディター

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

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

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

スキーマに追加されたロイヤルティ層オブジェクトを含むスキーマエディター フィールドプロパティ がハイライト表示されている様子

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

スキーマ図でハイライト表示されたテナント ID とロイヤルティ層を含むスキーマエディター。

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

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

テナント ID と新しいサブフィールドがスキーマ図のロイヤルティ層に追加されたスキーマエディター。

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

  • フィールド名: ​フィールドの名前(なるべくキャメルケースで記述)。スペース文字は使用できません。 これは、コード内および他のダウンストリームアプリケーションでフィールドを参照するために使用される名前です。
    • 例:loyaltyLevel
  • 表示名: ​単語の先頭のみ大文字で書かれたフィールド名。これは、スキーマの表示または編集時にキャンバスに表示される名前です。
    • 例:Loyalty Level
  • Type: データタイプ of フィールド。 これには、基本的なスカラータイプが含まれます and 任意のデータタイプ defined Schema Registry で。 例:文字列、整数、ブーリアン、人物、住所、電話番号など
  • 説明: ​フィールドの説明(オプション)は、200 文字以内で指定してください。

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

新しい ID フィールドのフィールドプロパティ値がハイライト表示されたスキーマエディター。

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

ID フィールドが追加されハイライト表示されたスキーマエディター。

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

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

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

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

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

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

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

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

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

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

階層クラスオブジェクトが追加され、 フィールドプロパティ でハイライト表示されたスキーマエディター

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

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

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

「適用 がハイライト表示された状態で列挙および推奨値フィールドのプロパティが完了し した

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

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

データタイプを使用すると、複数フィールド構造を一貫して使用でき、フィールドグループよりも柔軟性が高まります。これは、データタイプがスキーマ内のどこでも使用できるからです。これを行うには、フィールドの​ タイプ ​の値を、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 名前空間 を指定する必要があります。このフィールドは顧客のメールアドレスなので、ドロップダウンから「メール」を選択します。「適用」を選択し、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

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

ビデオリソース

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

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

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

付録

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

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

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

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

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

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

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

recommendation-more-help
62e9ffd9-1c74-4cef-8f47-0d00af32fc07