Customer 360 データモデルについて知る
学習の目的
この単元を完了すると、次のことができるようになります。
- データモデルの課題を説明する。
- Customer 360 データモデルの用語を把握する。
- Salesforce で Customer 360 データモデルがどのように使用されているかを説明する。
Trailcast
このモジュールの音声録音をお聞きになりたい場合は、下記のプレーヤーを使用してください。この録音を聞き終わったら、必ず各単元に戻り、リソースを確認して関連付けられている評価を完了してください。
Customer 360 データモデル
多くの場合、ミッションの成功はハイテクなガジェットとテクニカルサポートによって支えられています。Data 360 で大量のデータを管理、整理できるのも、バックグラウンドでのサポートがあってこそです。Customer 360 データモデルを使用して、データの構造や形式が異なるデータソースを標準化し、関連付けています。API (システムが対話し合えるようにする開発者ツール) や他のマッピングを使用して、アプリケーションとデータを接続しています。基本的に、Customer 360 データモデルが Data 360 の標準データモデルです。統合をシームレスかつスケーラブルに行う手段を備え、 クロスプロダクト統合の障壁も軽減します。標準化が重要な理由は、いくつかあります。
データモデル
多くの企業は、コネクテッドエクスペリエンスやデジタルトランスフォーメーションを求めて、複数のシステムを採用しています。チームメンバーがさまざまなソースのデータを使用している NTO の例を覚えていますか? NTO のような状況は非常によくあります。会社が大きくなればなるほど、使用するシステムも増えていきます。各システムには、独自のデータモデルが備わっています。そのため、ユーザーが部門間、システム間でデータを統合するのが難しくなります。企業がこの問題を解決する手段として、開発者やコンサルタントにカスタムのコードやソリューションを作成して点と点をつなげるよう依頼することがよくありますが、このような方法ではイノベーションの減速化や統合の脆性化を招く恐れがあります。
データベース構造
エンタープライズデータが標準化されていることは稀です。データは、標準化されている代わりに特定のビジネス要件に合わせて大幅にカスタマイズされています。小数や長さが制限されていない未加工の形式となっている場合さえあります。このような状態によって面倒が生じていることがありますが、さらなる混乱も生み出していきます。データは、構造化または非構造化データ (正式なデータモデルがあるかどうか) と分類することもできます。データを保存するデータベースには、SQL (構造化クエリ言語) を使用するリレーショナルデータベースから、SQL を使用しない NoSQL データベースまで、さまざまな種類があります。(参考までに、Marketing Cloud Engagement ではリレーショナルデータベース構造を使用してデータを保存します。) 現在の多くの組織は、さまざまなデータベースにデータを保存しています。簡単にデータを取り出せるのであれば異なる型のデータを保有してもかまいませんが、必ずしもそのような状況にはなっていません。
データシステムについての詳細は、Trailhead の「ビッグデータアーキテクチャの戦略」モジュールを参照してください。
マーケティング担当者向けのデータモデルガイド
マーケティング担当者は、ビジネスやパーソナライズされたカスタマーエクスペリエンスがデータによって促進されることを知っています。データモデルとデータアーキテクチャのエキスパートになる必要はありませんが、業務にどのような影響を与えるかを理解しておくと役立ちます。ある顧客のレコードが小売業者の POS システムに保存される方法と、その同じ顧客が Marketing Cloud Engagement で識別される方法を考えてみてください。POS では、販売時間に基づく乱数で顧客を保存しているかもしれません (1145 など)。Marketing Cloud Engagement では、その同じ顧客を購読者キーを使用して保存します (Susan1145 など)。では、同じ顧客を識別する方法が異なり、データ形式も異なるシステムを統合するにはどうすればよいでしょうか?
Customer 360 データモデルでは、主題領域 (販売注文など) に基づく一般的なシナリオで使用できる標準化されたデータモデルを作成して、この問題を解決します。この方法でデータを標準化すると、データマッピングが行いやすくなります。データマッピングが容易になれば、複数のシステム上の同じ顧客を識別しやすくなります。
Customer 360 データモデルの用語
では、Customer 360 データモデルの基本コンポーネントをおさらいしましょう。
主題領域
主題領域は、類似のデータオブジェクトをグループ化し、データモデリングを支援するために使用されるビジネス概念または用語です (例: 販売注文、ロイヤルティ、またはエンゲージメントデータ)。各主題領域には、1 つ以上のデータモデルオブジェクトが含まれます。
データストリーム
Data 360 に取り込まれるデータソース (例: Marketing Cloud Engagement の顧客データエクステンション)。このデータストリームは、バッチ化されたデータまたはリアルタイムデータストリームに基づくことができます。
データレイクオブジェクト (DLO)
データレイクオブジェクトは、データストリームから Data 360 に取り込まれるデータのコンテナです。
データモデルオブジェクト (DMO)
データモデルオブジェクトは、データストリーム、インサイトなどのソースからのデータをグルーピングしたもの、または整理する方法です。DMO はビジネスニーズに基づき、標準またはカスタムの場合があります。一般的な標準 DMO には、販売注文、関係者 ID、メールエンゲージメントなどがあります。
Attribute (属性)
属性 (項目とも呼ばれます) は、DMO にある特定のデータです (例: 顧客の名)。これは、Marketing Cloud Engagement のデータエクステンション項目のようなものです。
外部キー
外部キーは、データリレーションを構築するデータソース間の共通リンクです (たとえば、顧客 ID 番号)。
Salesforce、データモデル、そしてマーケティング担当者
なぜ Customer 360 データモデルを採用するのでしょうか? Customer 360 データモデルは、さまざまな Salesforce アプリケーションや外部ソースのデータを 1 つにまとめ、標準化するのに役立ちます。Customer 360 データモデルを使用することで、さまざまなプラットフォームでデータが使いやすくなります。非常に複雑なデータパイプラインにも、セルフサービスのデータ管理プラットフォームを提供できるようになります。
マーケティング担当者にとって Customer 360 データモデルとは、Data 360 で使用され、マーケティングの一般的なユースケースに基づく事前作成済みモデルを用いてデータモデリングを容易にするものです。一般的な顧客エンゲージメントや顧客ロイヤルティの追跡といった目的のために作成されたこのデータモデルは、データバンドルと呼ばれています。このモジュールではデータバンドルの詳細な説明は行いませんが、データバンドルは多くの操作やデータサイエンスの博士号を必要とすることなくデータの標準化に役立つということを覚えておいてください。
もっと知りたい方は 標準データモデルについての詳細を学ぶには、「Data 360 の Customer 360 データモデル」バッジを獲得してください。
あらかじめ用意されているデータユースケースや標準オプションがビジネスに適していない場合は、独自のデータモデルをカスタマイズすることもできます。
Marketing Cloud Engagement 連絡先モデル
Data 360 を実装しても、Marketing Cloud Engagement Contact Builder の現在の連絡先モデルには影響しません。Marketing Cloud Engagement の連絡先モデルは、データモデルというパズルの 1 ピースにすぎません。Data 360 の役割は、複数のチャネルとクラウド間での統合と動作を可能にすることです。ということで、次の単元では Data 360 を使用するための準備作業を説明します。
データ戦略についての詳細が知りたいですか? 顧客データに関する考慮事項についての詳細は、Trailhead の「お客様中心のデータ戦略」モジュールを参照してください。
製品の概要と、バックグラウンドでどのようにデータが管理されているかを大まかに理解したところで、次は Data 360 を詳しく見ていきましょう。
リソース