データモデル作成の準備をする
学習の目的
この単元を完了すると、次のことができるようになります。
- データ取得とモデリングに関連する主要な用語を定義する。
- Data Cloud を使用する利点を明らかにする。
事前に計画する
1 人の人から生成されるデータの多さや、そのデータのソースの多様さには驚かされます。簡単な 1 回のショッピングでさえ、販売メッセージ、Web トラフィック、購入、好み、ロケーション、その他の多くのソースに関連する顧客データが生成されます。データアウェアスペシャリストのあなたは、顧客をより完全に理解するために、その情報のすべてを常に整理してアクセスできるようにする必要があります。データを適切な場所に配置し、ビジネス分析タスクを実行するために必要なリンクをすべて作成するのはあなたの責務です。
データモデルの定義作業は複雑になることがあります。収集しているデータ (と収集方法)、既存のデータ構造、データが他のソースとどう関連付けられるかを理解する必要があります。さらに、そのすべてのデータを一元化されたアクション可能な顧客ビューにまとめる必要があります。Data Cloud には、その一元化ビューを作成し、顧客をエンゲージするために必要なすべてのツールが揃っています。
Data Cloud の作業を始める前に、紙、ノート、ホワイトボードなど落書きができるものを用意します。列がすべてのデータセット、行が各データセットの特別な考慮事項のマトリックスを作成します。
データセット
マトリックスの列を設定するときには、次の要素を考慮します。
- 取り込む可能性があるデータソースをすべてリストアップします。
- 従来のソフトウェア
- 外部データベース
- CRM
- e コマース
- データレーク
- マーケティングデータベースとメールデータベース
- カスタマーサービス
- デジタルエンゲージメントデータ (Web とモバイルを含む)
- 分析
- データソースごとに必要なデータセットをすべて特定する (e コマースデータなら、販売注文の詳細と販売注文ヘッダーデータなど)。
特別な考慮事項
マトリックスの行を設定するときには、次の特性を考慮します。
- 各データセットのプライマリキー (データの行を一意に識別する値) を理解する。
- データセットの外部キーを特定する。ソースにあるこの補助キーは別のデータセットのプライマリキーにリンクしている可能性があります。(たとえば、販売注文の詳細データセットに、購入された品目に対応する商品 ID が含まれているとします。この商品 ID は、その商品の詳細 (色や大きさなど) を含むまったく別のテーブルにリンクしています。この場合、販売注文の詳細データセットの商品 ID は外部キー、商品データセットの商品 ID はプライマリキーです)。
- データが不変であるかどうか (レコードの送信後は変更の対象外) 、既存レコードの更新をデータセットにも反映する必要があるかを判断する。
- データに適用したい変換があるかどうかを判断します。(たとえば、簡単な数式を使用して、名前をクリーンアップしたり、行ベースの計算を実行したりすることができます。)
- 各データソースから取得される属性 (または項目) を確認する。同じ項目が複数のソースで追跡されている場合は、最も信頼できるデータソースを決定します。後でソースの優先順序を設定できます。
- 各データセットにアクセスするための認証情報を手元に用意しておく。
- データの更新頻度をメモする。
コンセプトの計画からモデルの作成まで
実装の全体を把握するための調査が終わったので、後はしくみを理解するだけです。図のように、データは 2 フェーズアプローチで取り込まれます。
- データ取得: データセットからすべての項目を変更せずに現状のまま取得します。こうすることで、設定時にミスをしたり、ビジネス要件が変わったりしても、常にデータを元の状態に戻すことができます。命名法の整理や行ベースの計算実行を目的とする追加の数式項目を作成してデータを拡張することもできます。Data Cloud では、各データセットはデータストリームで表されます。
- データモデリング: ソース間のハーモナイズされたビューを作成するために、データストリームをデータモデルにマッピングします。
最初のステップである各データセットの取得時には、作成したマトリックスで特定したデータセットのソースを参照します。Data Cloud 内に、ソースの名前を場所があります。そのソースの横で、[オブジェクトの表示ラベル] と [オブジェクト API 参照名] を入力して、そのソースから取り込むデータセットを指定します。
マトリックスでデータセットのプライマリキーを参照し、データソースオブジェクトを定義するときにその項目をプライマリキーとして指定します。データセットを追加の数式項目で拡張する場合は、このフェーズで数式ロジックを適用できます。データが不変かどうかを指定したことを覚えていますか? イベントの dateTime 値を持つデータセットのカテゴリには、多くの場合、エンゲージメント種別が適しています。このような行動データセットは日付ベースのコンテナに整理されます。後で Data Cloud がデータを参照してセグメンテーションカウントを提供するとき、データの場所が正確に認識されているため、情報をすぐに取得できます。
Customer 360 データモデル
すべてのデータが取得されましたが、各データセットがそれぞれ独自の言語を話していると想像してください。すべてのデータセットが互いを理解するにはどうすればよいでしょうか? のデータセットが互いに会話を始めるには、すべてが同じ汎用言語に従う必要があります。そこで第 2 フェーズのデータモデリングが必要になります。Data Cloud では Customer 360 データモデルというデータモデルを使用します。
このモデルは、複数の主題領域を扱う複数のオブジェクトで構成されます。主題領域として、関係者、商品、販売注文、エンゲージメントなどがあります。このモデルは拡張可能です。つまり、標準オブジェクトにカスタム属性を追加でき、新規カスタムオブジェクトを作成して他の既存のオブジェクトとのリレーションを指定できます。
事前計画時に、マトリックスで外部キーを指定しました。この外部キーを使用して、Customer 360 データモデルの元の領域を独自のカスタムオブジェクトで拡張できます。
Customer 360 データモデルは、ソースオブジェクトにセマンティックコンテキストを割り当てて誰でも理解できるようにする手段として考えることができます。たとえば、自宅がアパート、戸建、マンションのいずれでも、人が住む場所という点は一致します。同様に、すべてのデータソースに対してハーモナイズされたデータレイヤーを作成し、基礎となるソースオブジェクトから離して抽象化します。オフライン注文データ (注文項目が Salescheck_Number) とオンライン注文データ (注文項目が Order_ID ) があるとします。項目名は異なりますが、どちらも注文 ID を示しています。そこでマッピングでは、両方に Customer 360 データモデルの参照注文 ID としてだけタグ付けします。このプロセスにより、情報をさまざまなソースのコンテキストから、1 つの分類法に従う新しいデータレイヤーに移動します。データソースに関係なく、データは標準化されタスク内で使用可能になります。このようにしてすべてのデータセットが同じ言語を話すようになります。
標準データモデルについての詳細は、「Data Cloud の Customer 360 データモデル」バッジを参照してください。
