データとデータモデルオブジェクトを確認する
学習の目的
この単元を完了すると、次のことができるようになります。
- 関係者主題領域の重要性を説明する。
- 情報を取得するために、関係者データモデルのデータモデルオブジェクトを実装する。
データの計画を練る
ある会社が Customer 360 データモデルのデータモデルオブジェクトと属性を使用して、どのようなアプローチをするかを見てみましょう。前述のとおり、各自のデータモデルはまだ Customer 360 データモデルに定義されていません。すべての作業がすでに完了していたら喜ばしいことですが、今のところ、未来の予測は不可能です。Customer 360 データモデルには、特定のデータモデルオブジェクトと属性を表すための標準化された方法が用意されています。つまり、誰もが同じ種類のブロックを使用しているため、すべてがどう連携し、動作するかがわかります。何をつくる場合であっても関係ありません。このブロックを使用すると、将来のデータモデル需要に合わせて、より適切に拡張できるようになります。では、例を見てみましょう。
Pia Larson をご紹介します。Pia はアウトドア用品と衣料の小売業者である Northern Trail Outfitters (NTO) のエンタープライズアーキテクトで、自社のデータモデルの計画を練る任務を担っています。NTO は、店頭販売、オンライン販売、顧客マーケティングジャーニー、Web サイトでの行動など、あらゆる種類のソースからデータを取得しています。Pia の仕事は、すべてのデータをまとめることです。
何よりも先に、Pia はデータの出所を知る必要があります。そのためには、すべてのデータソースを調べる必要があります。NTO は、セールスプロセス、サポートインタラクション、マーケティング活動などから情報を収集します。Pia は NTO のカスタマージャーニーのすべてのファセットでステークホルダーと話をし、データが保存されている場所を確認する必要があります。
Pia が NTO に必要だと判断したのは、1 つに統合された取引先責任者 ID と、取引先責任者が実行するアクションに関する情報です。Pia は、そのアクションに関する情報を 1 つに統合された ID にまとめたいと考えています。Customer 360 データモデルを確認した後、NTO がデータモデルの基礎として必要な情報は関係者主題領域とエンゲージメント主題領域であると判断しました。
次に、この 2 つのデータモデルオブジェクトのマッピングを始めます。Pia は、Data Cloud では個人、関係者 ID、連絡先メール、連絡先電話、および連絡先住所データモデルオブジェクトが必要だということも気付いています。この一般的なオブジェクトは、統合プロファイルの作成に使用できる一般的な顧客データの強固な基盤となります。
関係者を結合する
Customer 360 データモデルでは、関係者主題領域の関係者は人物または組織のインスタンスを表します。このエンティティは、個人、法人、またはその他の機関である可能性があります。データモデルオブジェクトにはさまざまな種類の情報を添付できますが、各インスタンスはそのエンティティを一意に表します。関係者主題領域には、特定のエンティティの情報 (取引先責任者情報、ロールとビジネスの関係、その他の関連情報など) を識別するのに役立ついくつかのデータモデルオブジェクトが含まれます。
関係者主題領域には、関係者 ID、個人、連絡先メールという聞き馴染みのあるデータモデルオブジェクトが含まれています。ある 1 人の人物に関連する関係者主題領域とその主題領域に関連付けられているデータモデルオブジェクトを見てみましょう。具体的には、NTO の顧客である Rachel Rodriguez の例です。
Rachel のケースでは、名前にいくつかの代替スペルが見られますが、呼んでほしいニックネームもある人や伝統的な愛称が多数ある名前の人 (例: Elizabeth、Beth、Betsy、Liz、Liza、Eli など) がいたらどうでしょうか。大量な情報をまとめなければなりません。いくつかの異なる住所 (昔のアパート、職場の住所、現在の居住場所) を入れると、システムで考慮するべきバリエーションはさらに増えます。昔の携帯電話番号やメールアドレスについては、もう取り上げません。重要な作業はもっとあります。
関係者主題領域の個人
Rachel に関する情報は、さまざまなソースから取得されます。NTO は、そうしたソースの情報を解決する必要があります。そこで Pia は、すべての情報を正しいデータモデルオブジェクトとそれぞれの属性に確実に直接リンクさせる必要があります。この情報はすべて、Data Cloud で Rachel Rodriguez の統合プロファイルを作成するという最終目標を達成するのに役立ちます。ただし、このすべての項目の中でも、他より特に重要なものがあります。
個人 ID は個人 DMO 内にあり、個人 DMO と他の DMO をリンクするのに役立ちます。Pia は Data Cloud インスタンスに入るすべてのデータストリームの概要を定めるときに、個人 ID に戻る Rachel の情報のすべてを確実にマッピングする必要があります。個人データモデルオブジェクトに含まれている一連のリレーションの例を見てみましょう。
この例では、取引先の取引先責任者というデータモデルオブジェクトの個人項目が個人 ID 項目に関連付けられています。連絡先住所、連絡先メール、連絡先電話番号も、個人 ID 項目に関連付けられています。このすべての項目は、ManyToOne のカーディナリティで関連付けられています。つまり、複数の住所と電話番号を 1 人の個人に関連付けることができます。(心配は無用です。使い捨てのメールアドレスを使用しても、誰にも言いません)。個人データモデルオブジェクトの個人 ID 項目は、OneToOne のカーディナリティで統合リンク個人データモデルオブジェクトの個人 ID 項目にも関連付けられています。このデータモデルオブジェクトは、ID 解決プロセスの実行後に使用できるようになります (このプロセスは、「Data Cloud の取得とモデリング」モジュールで確認できます)。この場合、このリンクの値の数は 1 つのみとなるため、レコードの特性の維持に役立ちます。
統合リンク個人についての詳細は、このバッジの後半で説明します。
関係者をパーソナライズする
データモデルは、Data Cloud インスタンスに合わせてパーソナライズされます。どう組み立てるかは、各自のデータニーズと Data Cloud へのデータの取り込みに使用するデータソースによって異なるからです。ですが、標準化されたデータモデルオブジェクトを使用しているのには理由があることを思い出してください。標準化によって、Data Cloud ですべての情報を適切な統合個人と一致できる確率が高くなります。また、データモデルの機能が最大限に発揮され、稼働までの時間が短縮します。さらに、AppExchange のアプリケーションをより簡単に活用できます。なぜなら、使用するデータの種別と構成について全員がすでに合意しているからです。
データモデルを計画するときには、識別子を正確に一致させることを覚えておく必要がありますが、他より優先するデータソースについても検討してください。この情報は、後に Data Cloud で ID 解決を処理するときに役立ちます。このプロセスによって、すべての正しい情報が正しいレコードに確実にリンクできるようになり、使用する情報の優先度が定められます (例: フルネームかニックネーム、または希望するメールアドレスなど)。すべての情報を統合プロファイルにまとめるときには NTO の一意のメンバーシップリワード番号が役立ち、ルールを使用すれば顧客との実際のやり取りで優先、使用する情報を選定できます。
まとめ
この単元では、Data Cloud 内における、人物に関するデータモデルについて説明しました。次は、人が実行するアクションと、それを取得する方法を見ていきます。
リソース