違いをひとことで言うと？
カスタマーデータプラットフォーム（CDP）は、あらゆるソースから顧客データを集め、1人につき1つのIDに名寄せし、オーディエンスをほかのツールに同期します。顧客に何も送らないデータ基盤です。カスタマーエンゲージメントプラットフォーム（CEP）は活用の層です。プロファイルとイベントのストアを自前で持ち、人に届くセグメント、ジャーニー、メッセージを動かします。このガイドでは2つのカテゴリーを比較します。しきい値、シグナル、費用といった判断のためのチェックリストは、ガイドCDPは必要か？をご覧ください。
CEPにはできず、CDPにできることは？
CDPは、サイトやアプリのSDK、サーバーサイドのストリーム、データウェアハウスや課金ツールからのインポートなど、あらゆるソースからイベントと属性を集めます。それを1人につき1つのIDに名寄せし、できあがったオーディエンスを連携先のツールに同期します。CDP Instituteは、CDPを「ほかのシステムからアクセスできる、永続的で統合された顧客レコードを作成し、維持するソフトウェア」と定義しています。鍵になるのは最後の部分です。アウトプットは、ほかのシステムが使うレコードです。CDPはデータ基盤であり、集め、名寄せし、振り分けます。送信は、CDPがデータを渡すツールの側で行われます。CDPに直せないのは雑なインプットです。だからこそ、整ったトラッキングプランは、CDPがあってもなくても同じくらい重要です。
CEPはそのデータで何をするのか？
CEPはプロファイルとイベントのファーストパーティストアを自前で持ち、その上でセグメントを計算します。イベントが届くたびに再計算される動的セグメントもその1つです。そして、メール、SMS、アプリ内メッセージ、プッシュ通知を送るジャーニーを実行します。CDPが意図して避けている最後の区間、つまりデータを顧客が実際に受け取るメッセージに変える部分を受け持ちます。このストアは実装の細部ではありません。プロファイルとイベントが自社で管理するシステムにあることが、実際のところ顧客データを自社で所有することの大部分です。
CDPとCEPを並べて比較
CDPとCEPの混同は、概念ではなく商売の問題です。どちらの側のベンダーも、相手の用語を取り込み続けています。市場にはそうする理由があります。CDP Instituteの2025年7月の業界レポートには208社のCDPベンダーが挙がっており、CDP.comがまとめたアナリストの推計では、2026年のCDP市場規模は、誰が測るかによって40億ドルから105億ドルまで幅があります。それでも、仕事ははっきり分かれています。この表は、マーケティングの言葉を取り除いても残る区分です。
| カスタマーデータプラットフォーム | カスタマーエンゲージメントプラットフォーム | |
|---|---|---|
| 主な仕事 | 顧客データの収集、名寄せ、振り分け | データの活用（セグメント化、ジャーニーの制御、送信） |
| 入ってくるもの | SDK、バックエンド、データウェアハウス、SaaSツールからのイベントと属性 | 自前のSDKとAPIからのイベントと、プロファイルの属性 |
| 出ていくもの | 整ったプロファイルとオーディエンス（連携先のツールに同期） | メール、SMS、アプリ内メッセージ、プッシュ通知と、その分析 |
| 名寄せ | 中核機能（ソースやデバイスをまたいで同じ人物を統合） | 基本的（通常は自前のストア内で、1プロファイルにつき1つのID） |
| メッセージを送るか | 送らない（定義上、送信するツールにオーディエンスを渡す） | 送る（送信こそが目的） |
| 運用するのは | データエンジニアやグロースエンジニア | マーケターや創業者（セットアップにはエンジニア） |
| 元が取れるとき | 多くの連携先が同じ名寄せ済みプロファイルを必要とするとき | オンボーディングし、定着させるユーザーができた時点から |
CDPが必要な課題とは、どんなものか？
- 広告プラットフォーム、分析、サポート、メッセージングなど、複数の連携先ツールが同じ整ったプロファイルを必要としていて、今はそれぞれが独自にプロファイルをつくっています。
- 分析基盤がデータウェアハウス起点です。データウェアハウスが信頼できる唯一の情報源で、下流のツールはそれぞれ、管理されたその一部を必要としています。
- IDがプロダクトをまたいで分断されています。同じ顧客が2つのアプリに3つのメールアドレスで存在し、それが同一人物だと言えるシステムが1つもありません。
- イベントの収集が重複しています。ツールごとに独自のスニペット、独自のスキーマ、同じファネルの独自版があります。
1つのシステムで両方をこなせるか？
小さなチームなら、たいていはCEPの側からこなせます。CEPのファーストパーティストアは、すでに収集の半分を担っています。クライアントのイベントにはSDK、サーバーサイドのイベントにはAPIがあり、プロファイルとセグメントはジャーニーと同じデータベースにあります。その上にCDPを足すと、新しい機能は増えないまま、保守するデータ層が2つになります。スキーマが1つ増え、デバッグする同期も1つ増えます。プロダクトも活用プラットフォームも1つのチームにとって、CDPは欠けているデータ層ではなく、2つ目のデータ層です。上で挙げた構成上のシグナルが本当にあるなら、両者はきれいに組み合わさります。CDPが集めて名寄せし、CEPにデータを渡し、CEPが最後の区間を受け持ちます。チームがその線を越えたかどうかは、ガイドCDPは必要か？で順を追って確認できます。
fromHelloの位置づけは？
fromHelloは、オープンソースのマーケティングオートメーション（MA）ツールです。扱うのは、人の行動をきっかけに届くメッセージです。ファーストパーティストアを自前で持っています。JS/TS SDKはオフラインキューつきでクライアントサイドのイベントを記録し、イベントAPIはサーバーサイドのイベントを受け付けます。プロファイル、セグメント、ジャーニー、メッセージは1つのデータベースにあり、セルフホストすることも、アーリーアクセス中のfromHello Cloudで私たちが運用することもできます。fromHelloはCDPではなく、CDPのふりもしません。Meta、LinkedIn、Google向けの広告オーディエンスとピクセルのリレー、そして送信用のWebhookを除けば、連携先のカタログも、ツールをまたいだIDグラフもありません。自社の構成に上で挙げたCDPのシグナルがあるなら、fromHelloは図のCEPの位置に入ります。CDPの下流で、名寄せ済みのプロファイルを受け取り、活用を担います。その席にどのプラットフォームを座らせるかをまだ選んでいるなら、オープンソースのMAツールのまとめから始めてください。