Customer 360とは、一人の顧客に関するデータをあらゆる接点、チャネル、システムから集め、施策に使える1つのプロファイルにまとめた顧客ビューである。 日本語では「360度の顧客ビュー」「顧客360度ビュー」と呼ばれることも多い。CRM、MAツール、Web解析、購買履歴、対応履歴に分かれている情報をデータ連携で束ね、その顧客が誰で、何をしてきて、どう接触されたいかを1か所で参照できる状態を指す。
Customer 360に含まれるデータ
| データの種類 | 含まれるもの | 何がわかるか |
|---|---|---|
| 識別情報 | 氏名、メールアドレス、電話番号、居住地、勤務先 | プロファイルの土台。チャネルをまたいだ名寄せの手がかりになる |
| 取引データ | 購買履歴、購入金額、契約の状態、決済手段 | 何を、いくらで、どの頻度で買っているか |
| 行動データ | サイト閲覧、メールの開封とクリック、アプリの利用、広告接触 | ブランドとの接触の実態（行動データ） |
| 対応履歴 | 問い合わせ、チャット、サポートの記録、アンケート回答 | 関係の質と、不満や満足の要因 |
| 同意と設定 | 配信の可否、データ利用の許諾、連絡手段の希望 | どこまで使ってよいかの境界（同意管理） |
最後の行が欠けているCustomer 360は、実務では使えない。同意の状態を持たないプロファイルは、その顧客を施策の対象に含めてよいかどうかを実行の直前に判定できないためである。
シングルカスタマービューとの違い
シングルカスタマービュー（SCV）は、重複したレコードを統合し、顧客ごとに1件のレコードを作るという技術的な到達点を指す。名寄せの結果として出来上がる、唯一の正となるレコード（ゴールデンレコード）がその中身である。
Customer 360は、そこから先を含む。統合されたレコードに、履歴の文脈、予測スコア、そしてそれを施策として動かすための手段が加わってはじめてCustomer 360になる。SCVはCustomer 360の前提条件であり、同義語ではない。統合はできているが施策には使えていない、という状態は珍しくない。
360度の顧客ビューが成果に効く理由
- パーソナライズの前提が揃う：購買履歴、閲覧行動、本人が申告した好みが揃っていれば、パーソナライズは推測ではなく事実にもとづいて行える。
- チャネルをまたいでも話が通じる：問い合わせを受けた担当者が、直前に届いたメールと最近の購入を把握している。顧客が同じ説明を繰り返す必要がなくなる。
- 兆候の段階で動ける：解約の前触れや、追加購入の機が熟した状態は、単一チャネルのデータでは見えないことが多い。
- 判断の材料が揃う：どの体験が継続と売上につながっているかを、カスタマージャーニー全体で追える。
CDPがCustomer 360を組み立てる工程
CDP（カスタマーデータプラットフォーム）は、この顧客ビューを作って維持することを目的に設計された製品である。連携先ごとに個別開発を積み上げる方式との違いは、次の5工程を標準機能として持っている点にある。
- 取り込み：CRM、MAツール、EC、コールセンター、モバイルアプリ、Web解析からデータ取り込みを行う。
- 名寄せ：メールアドレス、端末ID、会員IDといった異なる識別子が同一人物のものかを判定し、レコードを結ぶ。
- 統合プロファイルの生成：一人分のデータを1つのプロファイルにまとめ、新しい行動が発生するたびに更新する。
- 拡充：顧客生涯価値（LTV）、エンゲージメントのスコア、商品との親和性、所属セグメントといった派生属性を計算して付与する（データの拡充）。
- 提供：APIや標準コネクタ、データアクティベーションの機能を通じて、下流のツールが同じプロファイルを参照できるようにする。
更新をどれだけ速く反映する必要があるかによって、要件は変わる。セッション中の出し分けまで求めるならリアルタイムCDPの水準が必要になり、日次のバッチで足りる用途とは構成が別物になる。
「Customer 360」を名乗る製品は同じものではない
この言葉は、主要ベンダーが自社製品のブランド名として使ってきた経緯があるため、額面どおりに受け取れない。Salesforceは自社のCRM群全体を「Customer 360」と呼んでいるが、その実体はCRMと追加モジュールの集合である。定義に沿ったCustomer 360は、既知の顧客と匿名の訪問者、オンラインとオフライン、そして部門をまたいだ全てのチームを対象にする。
| 実現方式 | 顧客ビューの作り方 | 強み | 制約 |
|---|---|---|---|
| CDP | データの統合と実行連携のために設計された専用製品 | 全データ種別に対応、名寄せが標準機能、更新が速い | 実行チャネル側との接続設計が別途必要 |
| CRM | CRMにマーケティングやサービスのモジュールを足す | 商談とサポートの業務に強い、周辺製品が多い | 既知の連絡先が中心で、匿名の行動データは扱いにくい |
| データウェアハウス | ウェアハウス上に統合の仕組みを自前で構築する | データの統制が効き、既存投資を活かせる | 名寄せと実行連携を作り込む工数がかかる |
| マーケティングスイート | 解析、パーソナライズ、CDPを束ねて提供する | 対応範囲が広い | 買収に伴う製品間の継ぎ目、スイートタックスによる費用 |
日本で使われている代表的なCDPの例としては、Adobe Real-Time CDP、Salesforce Data Cloud、Tealium、Treasure AI（旧Treasure Data）などがある。いずれも推奨や順位づけではなく、カテゴリーの実例として挙げている。
方式をどう選ぶか
判断は、統合したデータを誰が使うか、どれだけ速い更新が要るか、既存の投資がどこにあるかの3点で決まる。
使う人から決める。 目的が複数チャネルでのパーソナライズとオーディエンスセグメンテーションであれば、CDPを中心に据える構成が最も早く成果に届く。既知の顧客に対する営業とサポートの改善が主目的なら、既存のCRMを拡張する方が現実的である。データエンジニアリングの体制があり、すでにモダンなデータ基盤が動いているなら、ウェアハウスを中心にする選択もある。
速さの要件を見極める。 セッション中のパーソナライズ、イベントを引き金にした配信、ネクストベストアクション（NBA）による判断を行うなら、プロファイルの参照はサブセカンドでなければ成立しない。バッチ前提の構成では、この用途は満たせない。
費用は総保有コストで比べる。 CRM中心の構成はスイート単位のライセンスが前提になりやすく、ウェアハウス中心の構成はソフトウェア費用が抑えられる代わりに構築と維持の人件費が乗る。3年分を円建てで並べて比較する。評価の観点はAI時代のCDPの評価基準で扱っている。
AIがCustomer 360に加える変化
- 予測属性：LTVの見込み、解約の可能性、購入の起こりやすさといった属性が加わる（予測分析）。過去の記録だったプロファイルが、次の判断に使える材料になる。
- 更新の即時化：流入するデータをその都度処理し、プロファイルを現在の状態に保つ。数時間前の状態を見て判断する余地がなくなる。
- 欠損の補完：行動の傾向や類似する顧客の情報から、欠けている属性や好みを推定する。
- 異常の検知：不正利用の兆候や、生活の変化を示す行動の変化を、通常の分布からの逸脱として捉える。
参照する主体も変わりつつある。エージェンティックCDPの構成では、統合プロファイルを読み取って判断を下すのは人の分析担当ではなく、APIやMCPを介して問い合わせるAIエージェントになる。人が見て理解できる画面よりも、機械が確実に読める形でプロファイルが提供されているかどうかが問われるようになる。
Customer 360の構築でつまずく5つのパターン
Customer 360の構築は、明確な失敗に終わるより、途中で止まることのほうが多い。プロファイルは出来上がり、構成図も正しいのに、顧客が受け取る体験は何も変わっていない。統合されたプロファイルと、実際の接客の改善との間にあるこの差は、次の5つでほぼ説明がつく。いずれも本番稼働の前に検知できる。
誰も使わないプロファイル。 統合された顧客像が分析基盤の中に収まり、四半期の報告で眺められるだけで、配信ツールにも、対応担当者の画面にも、製品チームが呼び出せるAPIにも届かない。レポートしか生まないCustomer 360は、呼び名を変えたデータウェアハウスの構築案件である。目的は統合そのものではなく、顧客への働きかけを変えることだったはずだ。対策は、取り込みの作業に入る前に、そのプロファイルを最初に読む3つの実行先（配信チャネル、対応窓口の画面、アプリケーション）を名指しで決めることである。顧客に接するシステムが実際にプロファイルを読むまで、この案件は未完了として扱う。
一度調整したきりのマッチング規則。 導入時点のデータに合わせて調整したマッチング規則は、新しいソース、新しい種類の識別子、新しい同意の状態が加わるたびに精度が落ちていく。過剰統合は同じ世帯の2人を1人にまとめ、不足統合は同じ顧客を、それぞれ完全に見える4つのプロファイルに分けたまま残す。どちらも、誰かが自分宛てでないメッセージを受け取るまで表に出ない。対策は、統合済みの組から標本を抽出して監査し、別人どうしを1つにまとめた割合（過剰統合率）と、同一人物が別々のプロファイルとして残っている割合（不足統合率）を追うことである。マッチングの件数だけでは足りない。件数が伸び続けているあいだに、統合の精度だけが落ちていくことがあるためだ。あわせて、本番稼働のときに一度だけ実施する受け入れテストではなく、継続して点検する担当者を名指しで置く。
測らないまま前提にされるデータ品質。 完全なレコードとは何かという基準はソースごとに違い、CDPは質の低い入力も、質の高い入力と同じ忠実さで統合する。空欄の項目、古い住所、移行のときに残った試験用のレコードは、そのままプロファイルの属性になり、セグメントの条件はそれを事実として扱う。完全なはずの顧客像が、確信を伴った的外れなターゲティングを生むのはこのためである。対策は、接続する前にソースごとの充足率、重複、鮮度を測り、属性の単位でデータ品質の指標を公開することである。下流のチームは、どの項目を信頼してよいかをそこで判断できる。
プロファイルを組み上げてから後付けされる同意。 同意と連絡手段の希望を最後に貼り付けると、プロファイルは技術的には完成していながら、一部は使えないものになる。ただし、ここで本当に問題なのは、配信直前の点検で気付けるかどうかではない。二つのソースのレコードを結び付けること自体に、その結合を正当化する根拠（取得のときに本人へ示した利用目的の範囲、または第三者提供についての同意）が要る、という点にある。根拠のないまま結合した時点でリスクは生じており、統合したプロファイルを実際に配信へ使ったかどうかとは関係がない。組み上がったプロファイルへ後から権限の情報を埋め込む作業は、最初から組み込むより時間がかかる。対策は、同意と連絡手段の希望を、他の属性と同じくアイデンティティグラフの上で名寄せと同時に解決し、プロファイルの正規の属性として保持することである。配信前のレビューで対象から外すのではなく、アクティベーションの時点で同意を適用する。
本番稼働で終わる体制。 導入チームは稼働後に解散し、ソース側の担当者は誰にも知らせずにスキーマを変え、プロファイルの属性には値が入らなくなる。派手に壊れるわけではないので、四半期のあいだ誰も気付かない。空のまま放置される属性が増えていくだけである。対策は、ソースごとの取り込みと派生属性のそれぞれに担当者を名指しで割り当て、データガバナンスの常設の場でその状態を確認することである。スキーマ変更の連絡は、好意ではなくチーム間の取り決めとして扱う。
順序の決め方ひとつで、このうちいくつかは同時に避けられる。最初のリリースの範囲を、そのプロファイルを使う活用事例に合わせて絞り、ソースは後続の活用事例が求める順に足していく。すべてのシステムを接続し終えてからアクティベーションに進もうとすると、最初の1年は連携の作業で終わり、統合されたプロファイルが成果を変えるという証拠は何も残らない。段階の切り方はCDP導入ガイドで扱っている。
FAQ
Customer 360とシングルカスタマービューは何が違うのか？
シングルカスタマービュー（SCV）は顧客ごとに1件のレコードを作るという技術的な到達点、Customer 360はその統合された顧客像を施策として使うところまでを含む概念である。 SCVは重複の排除と名寄せに焦点を当てている。Customer 360には、履歴の文脈、予測スコア、そしてそれを実行に移す手段が加わる。SCVはCustomer 360の前提条件である。
Customer 360プラットフォームとCRMは何が違うのか？
CRMは担当者の入力を通じて既知の顧客との関係を管理するのに対し、Customer 360を担うプラットフォームは匿名の行動データを含むあらゆるソースからデータを自動で取り込む。 SalesforceがCRM群を「Customer 360」と呼んでいるとおり、この名称は製品ブランドとしても使われている。全データ種別、全チャネル、全部門を対象にするという定義に最も近い製品カテゴリーはCDPである。
CDPがなくてもCustomer 360は作れるのか？
作れるが、名寄せ、プロファイルの更新、実行連携の3つを自前で用意することになる。 CRM、データウェアハウス、個別開発の組み合わせでも部分的な顧客ビューは実現できる。ただしこの構成では、分析には使えるが施策には回せない、というところで止まりやすい。データが揃っていることと、そのデータが顧客接点まで届くことは別の問題である。
Customer 360の構築にはどれくらいの期間がかかるのか？
期間を決めるのは製品ではなく、接続するソースの数、名寄せの規則を決めるまでの合意形成、そして同意の状態をどこまで整理できているかである。 標準コネクタで接続できるソースが中心であれば、最初の統合プロファイルは短期間で立ち上がる。反対に、部門ごとに顧客の定義が異なる場合や、同意の取得記録がシステムに残っていない場合は、その調整が全体の期間を決める。全ソースを一度に統合するのではなく、最初の施策に必要な範囲から始めるのが現実的である。
Customer 360をどう評価すればよいか？
取り込めるソースの範囲、名寄せの精度、プロファイルの充足度、実行連携の手段、そして統制の5点で見る。 自社の全ソースに接続できるか。異なるシステムのレコードをどこまで正確に結べるか。匿名の行動データを含む全データ種別を扱えるか。マーケティングやサポートのツールへ必要な速さで渡せるか。データの保存地域や監査ログの要件を満たすか。デモ環境ではなく自社の実データで概念実証（PoC）を行うことでしか、これらは確認できない。
関連用語
- シングルカスタマービュー（SCV）：Customer 360の前提となる、顧客ごとに1件の統合レコード
- 名寄せ：Customer 360の中核にある、レコードを同一人物に結ぶ処理
- データアクティベーション：統合プロファイルを実行チャネルへ届ける工程
- 予測分析：プロファイルに予測属性を加える分析手法
- ゴールデンレコード：Customer 360が生成する、唯一の正となるプロファイル
- エンタープライズCDP：全社規模でCustomer 360を運用する場合の要件
- データガバナンス：統合したプロファイルの利用範囲を定める統制の仕組み
この記事は他の言語でも読めます： Customer 360 · Customer 360: o que é a visão 360° do cliente