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:複数のソースから集計したデータに基づいて、統合されたリアルタイム顧客プロファイルを提供します。

Schemas ワークスペースを開く browse

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

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

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

スキーマの作成と命名 create

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

Create schemaがハイライト表示されたSchemas ワークスペース Browse タブ。

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

​ ワークフローのオプションを含むスキーマを作成ダイアログで、強調表示されたオプションを選択します。

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

マシンラーニングアルゴリズムを使用して、アップロードされたファイルに基づくスキーマ構造を推奨する方法については、機械学習を支援するスキーマ作成ガイド ​を参照してください。 このUI ガイドでは、手動作成ワークフローに焦点を当てます。

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

Create schema ワークフローが表示されます。 次に、スキーマのベースクラスを選択します。 これらのクラスが目的に合わない場合は、XDM Individual ProfileとXDM ExperienceEventのコアクラス、またはOtherのいずれかを選択できます。 「Other クラス」オプションを使用すると、新しいクラスを作成するか、他の既存のクラスから選択できます。

これらのクラスについて詳しくは、XDM individual profileおよびXDM ExperienceEventのドキュメントを参照してください。 このチュートリアルの目的では、XDM Individual Profile​を選択した後、Next​を選択します。

XDM individual profile オプションとNextがハイライト表示されたCreate schema ワークフロー。

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

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

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

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

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

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

Schema display name、Description、Finishがハイライト表示されたCreate schema ワークフローのName and review セクション。

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

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

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

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

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

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

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

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

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

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

Add field groups ダイアログ。

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

業界フィールドグループがハイライト表示されたAdd field groups ダイアログ。

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

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

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

​ デモグラフィックの詳細フィールドグループを含むPreview field group ダイアログがプレビューされました。

このチュートリアルでは、Demographic Details フィールドグループを選択し、Add field group​を選択します。

​ デモグラフィックの詳細フィールドグループが選択され、Add field groupsがハイライト表示されたAdd field groups ダイアログ。

スキーマキャンバスが再び表示されます。 Field groups セクションに「Demographic Details」が一覧表示され、Structure セクションには、フィールドグループによって提供されたフィールドが含まれるようになりました。 Field groups セクションの下でフィールドグループの名前を選択して、キャンバス内で提供される特定のフィールドを強調表示できます。

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

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

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

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

name フィールドのデータ型は"Full name"であり、これは共通の概念を説明し、名前、姓、礼儀タイトル、接尾辞などの名前関連のサブフィールドを含んでいることを意味します。

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

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

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

このチュートリアルでは、リストから標準フィールドグループ Personal Contact Details​と​ Loyalty Details ​を選択し、Add field groups​を選択してスキーマに追加します。

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

キャンバスは、Composition セクションの​ Field groups ​にリストされている追加されたフィールドグループと、それらの複合フィールドがスキーマ構造に追加された状態で再び表示されます。

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

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

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

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

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

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

Create new field group、Display name、DescriptionのAdd field groups ダイアログがハイライト表示されました。

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

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

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

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

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

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

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

Untitled Fieldとスキーマ Field propertiesがハイライト表示されたスキーマエディター。

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

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

終了したら「Apply」を選択します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

階層クラスオブジェクトを含むスキーマエディターがField propertiesで追加され、強調表示されます。

フィールドの種類が選択された後、フィールドに追加のチェックボックスが表示されます。これには、ArrayEnum & Suggested ValuesIdentityRelationship​のチェックボックスが含まれます。

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

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

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

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

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

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

loyaltyTier オブジェクトをデータ型に変換するには、キャンバスのloyaltyTier フィールドを選択し、エディターの右側の​ Field properties ​の下にある​ Convert to new data type ​を選択します。

loyaltyTier オブジェクトとConvert to new data typeが強調表示されたスキーマエディター。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

キャンバスでpersonalEmail.address フィールドを選択すると、Identity チェックボックスが​ Field properties ​の下に表示されます。 チェックボックスをオンにして、Primary identity​が表示されるように設定するオプションをオンにします。 このボックスも選択します。

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

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

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

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

変更を適用すると、personalEmail.address のアイコンに ID フィールドになったことを示すフィンガープリントマークシンボルが表示されます。 このフィールドは、Identities​の下の左側のパネルにも表示されます。

電子メールアドレスがハイライト表示され、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​切り替えボタンがあります。

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

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

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

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

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

その他のアクション more

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

スキーマエディター内で、スキーマのJSON構造をコピーしたり、スキーマを削除したりするためのクイックアクションを実行することもできます。 ビューの上部にある「More」を選択すると、クイックアクションを含むドロップダウンが表示されます。

詳細ボタンがハイライト表示され、ドロップダウンオプションが表示されたスキーマエディター。

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

スキーマは、More アクションを使用してスキーマエディターから、またBrowse タブのスキーマの詳細から、UI内で削除できます。 スキーマの削除を妨げる特定の条件があります。 次の場合、スキーマを削除できません:

  • このスキーマはプロファイルに対して有効になっています。
  • スキーマはプロファイルに対して有効になっており、関連するデータセットがあります。
  • スキーマに関連付けられたデータセットがありますが、プロファイルに対しては有効になっていません。

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

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

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

これで、スキーマの作成が完了したので、キャンバスに完全なスキーマが表示されます。 Save​を選択すると、スキーマが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