2026.11.08 AI

リアルタイム顧客分析とは？CDPで行動を即時に捉える仕組みと導入判断

リアルタイム顧客分析は、サイトの閲覧、カートへの投入、アプリの起動といった顧客ひとりひとりの行動を、発生から数秒〜数分のうちに判定し、その顧客がまだ接点にいるあいだに施策を返す分析の型です。前日までの購買履歴をRFMで切り分ける日次の顧客分析とは、答える問いが違います。この記事では、効果が出る施策場面、GA4・BigQuery・CDPで組んだときに実際に得られる鮮度と追加費用、導入を見送るべき条件、外部送信規律への対応までを、マーケティング部門と情報システム部門が導入を判断するための材料として整理しました。

まとめ｜リアルタイム顧客分析は施策の受け皿と判断の締め切りで要否が決まる

結論から書きます。リアルタイム顧客分析を入れるかどうかは、2つの問いで決まります。ひとつは、顧客がまだその場にいるうちに返せる施策（サイト内の表示切り替え、アプリのプッシュ通知、店舗スタッフへの連絡など）を持っているか。もうひとつは、判断の締め切りがセッションの内側、つまり数分から30分程度に収まるか。どちらかが欠けるなら、日次で作るセグメントのままでも成果は変わりません。

次に押さえたいのは、「リアルタイム」の中身がツールごとに大きく違う点です。GA4のリアルタイムレポートは過去30分の動きを画面で確かめる機能で、正式なSLOを持たないベストエフォート型と公式に明記されています。BigQueryへのストリーミングエクスポートは数分以内に届く一方、1GBあたり0.05米ドルの追加費用がかかり、欠落の可能性も書かれています。要件書にはツール名ではなく、「何分以内に・どの程度の欠損まで許容して届けば施策が成立するか」を数字で書いてください。

本文では、顧客分析一般との役割の違い、施策場面ごとの締め切り、GA4・CDPの公式仕様から読める鮮度、見送り条件、段階的な移行手順の順に扱います。投資判断だけを急ぐ場合は、見送り条件の章から読んでも結論にたどり着けます。

リアルタイム顧客分析の定義と日次の顧客分析・リアルタイム分析一般との違い

似た言葉が3つ並ぶため、最初に範囲を固めます。混ぜたまま要件定義に入ると、作るべき基盤の規模を読み違えます。

顧客単位の行動イベントをセッション中に判定して施策を返す仕組みの全体像

リアルタイム顧客分析の処理は、3つの段階でできています。行動イベントに顧客IDを付けて受け取る段階、その顧客の過去の購買や会員ランクと突き合わせて条件を判定する段階、そして判定結果を配信の仕組みへ渡す段階です。肝心なのは、判定の単位が「サイト全体」ではなく「その顧客」である点にあります。

サイト全体のアクセス数や売上を秒単位で追うのは、リアルタイム分析一般の領域です。鮮度要件の切り分け方や常時稼働の費用構造はリアルタイム分析の定義とバッチとの違い、見送りの判断基準で扱っています。顧客分析の場合、判定結果を受け取るのは人よりもWebの表示切り替えや通知配信といったシステムである場面が多く、そこが設計の起点になります。

RFM・コホートの日次分析と分かれる「今この顧客に何を返すか」という問い

日次の顧客分析が答えるのは、「どの顧客層に来月どんな施策を打つか」という問いです。RFMやコホートの選び方と、Excel・BI・基盤の使い分けは顧客分析の手法の選び方と判断基準にまとめました。リアルタイム顧客分析が答えるのは、「いまカートを放置したこの顧客に、離脱する前に何を出すか」です。

両者は置き換えの関係にありません。日次で算出した属性を、リアルタイム判定の条件に組み込んで使います。たとえば「過去1年の購入回数が5回以上」という条件は日次で計算しておき、「直近30分で同じカテゴリを3ページ閲覧した」という条件だけをその場で判定する。前半を毎回その場で計算しようとすると、基盤の負荷と費用が跳ね上がります。

GA4の数分とCDPのストリーミング評価で異なるリアルタイムの実際の鮮度

同じ「リアルタイム」という言葉でも、届く速さと完全性は製品ごとに違います。公式ドキュメントの記載を並べると、次のようになります。

仕組み	公式記載の鮮度	顧客単位の施策	注意点
GA4 リアルタイムレポート	過去5分・30分	不向き	正式なSLOなし
GA4 イントラデイ	標準で2〜6時間	当日中の施策なら可	集計画面が中心
BigQuery ストリーミング	数分以内	可	欠落の可能性あり
CDP ストリーミング評価	ほぼリアルタイム	可	条件の形に制限

GA4のリアルタイムレポートの公式ヘルプは、表示期間を過去5分間と30分間とし、高基数のディメンションは「(other)」にまとめられると書いています。データの更新頻度のヘルプでは、標準プロパティの日次データの処理に12時間かかるとされています。つまりGA4の画面は状況を確かめる道具で、特定の顧客に施策を返す起点にはなりません。顧客単位で動かすには、表の下2行のどちらかが必要です。

リアルタイム顧客分析が成果につながる施策場面とマーケDXでのユースケース

施策場面ごとに、判断の締め切りと受け手が異なります。締め切りが数時間あるなら、ストリーミングの基盤は要りません。

カゴ落ちと閲覧離脱をセッション内で拾うECサイトの表示切り替えと通知

カートに商品を入れたまま購入に進まない顧客への働きかけは、最も相談の多い用途です。ただし、手段によって必要な鮮度が変わります。翌朝や数時間後にメールを送る運用なら、GA4のイントラデイ（標準プロパティで2〜6時間）や日次バッチで間に合い、新しい基盤は不要です。

秒から分の鮮度が要るのは、同じセッションの中で手を打つ場合に限られます。決済画面から戻った瞬間に送料条件を表示する、離脱しそうな動きの直後に在庫残数を出す、といった施策です。この場合はWebサイト側の表示切り替えの仕組みまで一体で作る必要があり、分析基盤だけ整えても効果は出ません。

アプリ起動と来店を起点にしたクーポン配信と在庫データ連動の条件

アプリの起動や店舗の近くでの位置情報を合図に、会員ランクと直近の閲覧履歴に応じたクーポンを出す施策もよく挙がります。ここで抜けやすいのが在庫との連動です。欠品している商品のクーポンが届くと、顧客の不満は施策をしない場合より大きくなります。

店舗とECの在庫を一元で引けない状態なら、リアルタイム化より先に在庫データの統合が必要です。統合の要件と順序はオムニチャネルの在庫・顧客データ統合要件で整理しています。

解約兆候と支払いエラーを担当部署へ即時に回すサブスク型サービスの運用

サブスクリプション型のサービスでは、解約手続きページの閲覧や、カード決済の失敗といった行動が解約の手前に現れます。これをカスタマーサクセスの担当者へ即時に通知し、電話やチャットでフォローする運用です。

受け手が人である以上、実際の対応速度は担当者の勤務時間で決まります。対応が平日の日中だけなら、深夜に秒単位で検知しても翌朝にまとめて処理するのと結果は同じです。この用途では、営業時間中の通知を数分以内に届けられれば十分で、24時間の常時判定は過剰になります。

料金ページの再訪を営業担当へ知らせるBtoBの見込み客対応と通知の閾値

BtoBでは、商談中の企業の担当者が料金ページや導入事例を繰り返し見ている動きを、営業担当に知らせる使い方があります。ここで決めておくべきは通知の閾値です。1回の閲覧ごとに通知すると、1日に数十件の通知が届いて誰も読まなくなります。

実務では「同じ企業から24時間以内に料金ページを2回以上」のように回数と時間枠で絞り、営業担当1人あたり1日数件に収まる水準へ調整します。閾値は導入後2週間ほどの通知件数を見て見直す前提で、最初から固定しないほうが運用が続きます。

GA4・BigQuery・CDPで組むリアルタイム顧客分析の構成と鮮度・費用の実際

構成の選択肢は、GA4のデータをBigQueryへ流して自社で判定する形と、パッケージ型のCDPに判定を任せる形に大きく分かれます。どちらでも、最初に設計するのはID統合です。

匿名の訪問者と会員IDを結び付けるID統合を最初に設計すべき理由と順序

顧客単位の判定は、その行動が誰のものか分かって初めて成り立ちます。ログイン前の行動はCookieや端末の識別子でしか追えず、会員情報とはつながっていません。ログインした時点で、それまでの匿名の行動をその会員に結び付ける処理が必要です。

この結び付けが弱いと、判定の大半が「誰だか分からない訪問者」に対して行われ、会員ランクや購買履歴を条件に使えなくなります。メールアドレスや電話番号の表記ゆれをそろえる名寄せのキー設計は、顧客データ統合の進め方と名寄せのキー設計で詳しく扱っています。リアルタイムの判定ロジックを作る前に、ここを固めてください。

GA4のストリーミングエクスポートとBigQueryで組む場合の鮮度・追加費用・欠損

GA4を計測に使っているなら、BigQueryへのエクスポートが入口となる構成です。BigQuery Exportの公式ヘルプによれば、ストリーミングエクスポートは当日分を数分以内に events_intraday_YYYYMMDD テーブルへ書き込みます。追加費用は1GBあたり0.05米ドルで、1GBはおよそ60万イベントに当たると記載されています。

費用そのものは小さく、1日10万イベントのサイトなら月300万イベント、約5GBで月0.25米ドル程度です。注意すべきは費用より完全性のほうです。ストリーミングはベストエフォート型で遅延や欠落が起こりうること、新規ユーザーの参照元・メディア・キャンペーンが含まれないことが明記されています。流入元を条件にした判定は、ストリーミングのデータだけでは組めません。日次エクスポートは標準プロパティで1日100万イベントの上限があるため、大規模サイトでは日次側の扱いも先に確認が要ります。BigQueryをCDPとして組む具体的なテーブル設計はBigQueryでCDPを構築する構成にまとめました。

パッケージ型CDPのストリーミング評価で扱える条件と24時間ルックバックの制約

パッケージ型のCDPも、あらゆる条件をその場で判定できるわけではありません。Adobe Experience Platformのストリーミングセグメンテーションガイドでは、ストリーミングで評価できる条件を、24時間未満の時間枠での単一イベント、単一イベントとプロファイル属性の組み合わせ、24時間の相対時間枠内の複数イベントに限っています。

プロファイル属性だけで作った条件はストリーミングの対象外で、バッチで評価されます。条件を編集して対象から外れると、自動でバッチ評価に切り替わる点も見落とせません。「過去90日に3回購入した顧客」をその場で判定したいなら、90日分の集計は日次で属性として持たせ、当日のイベントと組み合わせる設計に変える必要があります。製品を選ぶ前に、自社が判定したい条件を書き出し、ストリーミングの対象に収まるかを照合してください。

リアルタイム顧客分析を見送るべき条件と日次セグメントで十分な会社の見分け方

ここは判断を言い切ります。以下に当てはまる会社は、リアルタイム化に投資しても成果が出ません。

即時に返す配信チャネルが無い状態でリアルタイム化が空回りする構造と失敗例

最も多い失敗は、判定の仕組みだけが先に完成し、判定結果を顧客に返す手段が無い状態です。施策がメールだけで、そのメール配信ツールが1日1回の一斉送信しかできないなら、秒単位で判定しても顧客に届くのは翌日になります。

この状態で作られた基盤は、管理画面に「今この瞬間の顧客数」が表示されるだけの用途に落ち着きます。見栄えは良いものの、誰の行動も変えません。発注前に、判定結果を受け取る仕組み（Webの表示切り替え、プッシュ通知、担当者への通知）の名前と、受け取ってから顧客に届くまでの秒数を書き出してください。書けない場合は、まだ着手の段階にありません。

会員のログイン率・1日の該当件数・施策の承認手順で判定する見送り条件

配信チャネルがそろっていても、次のいずれかに当てはまるなら日次セグメントで足ります。

ログインする訪問者が少なく、判定の大半が匿名の訪問者になる：会員属性を条件に使えず、顧客単位の判定が成立しません。
条件に当たる顧客が1日に数件しか出ない：件数が少なすぎて施策の効果を比べられず、常時稼働の費用だけが残ります。
施策の出し分けに毎回人の承認が要る：判定が秒でも、実行は承認の速さで決まります。
判定の締め切りが当日中や翌日で足りる：GA4のイントラデイや日次バッチの時刻を早めるだけで要件を満たせます。

2つ以上に当てはまったら、投資は保留にしてください。先に手を付けるべきは、ログイン率を上げる導線の改善や、日次セグメントでの施策の効果検証です。そこで効果が確認できた施策だけを、リアルタイムに移す順番が安全です。

外部送信規律と同意管理で増える説明の範囲とリアルタイム追跡の注意点

顧客の行動を細かく取りにいくほど、Webサイトやアプリに計測用のタグやSDKが増えます。2023年6月16日に施行された改正電気通信事業法の外部送信規律では、利用者の端末から外部へ情報を送らせる場合に、通知・公表、同意取得、オプトアウト措置のいずれかを講じることが求められます。対象となるサービスの範囲や具体的な記載事項は、総務省の外部送信規律の解説ページで自社が該当するかを先に確かめてください。

リアルタイム化に伴ってCDPや通知配信のタグを追加すると、公表している送信先の一覧も更新が必要になります。タグの追加と公表文の更新を同じ手順書に入れておかないと、計測だけが先に増えて説明が追いつかない状態が生まれます。

日次分析からリアルタイムへ段階的に移す進め方と内製・外注の役割分担

一度にストリーミングの基盤を作る必要はありません。鮮度は段階を踏んで上げられます。

日次セグメント・イントラデイ・ストリーミングの順で鮮度を上げる導入手順

段階ごとに、次の段階へ進む条件をあらかじめ決めておきます。

日次セグメントで施策を回し、施策ごとの効果（購入率や解約率の差）を測る。
効果が出た施策のうち、鮮度を上げれば成果が伸びると説明できるものだけを、GA4のイントラデイや1時間おきのバッチに移す。
それでも締め切りに間に合わない施策に限り、BigQueryのストリーミングエクスポートかCDPのストリーミング評価で判定する。

各段階で効果が頭打ちになったら、そこで止めて構いません。3段階目まで進む施策は、多くの会社で1〜2本に収まります。処理保証やウィンドウ集計といったストリーム処理の実装面はストリーム処理の仕組みと処理モデルの解説が参考になります。

施策ルールは社内に残しイベント収集とID統合の基盤構築を外部へ切り出す境界

社内に残すべきは、どの行動を合図に誰へ何を返すかという施策ルールと、その閾値です。ここは商品と顧客を知っている人でないと調整できず、外部に預けると運用開始後の見直しが止まります。一方、イベント計測の設計、ID統合の処理、BigQueryやCDPへのデータの流し込みと監視は専門性が高く、経験のある外部に任せたほうが立ち上がりが早くなります。

当社では、行動イベントの収集からID統合、判定用のデータ基盤の構築と既存のBI環境への接続までを受託しています。施策ルールの設計は社内に残しつつ基盤側だけを切り出したい場合は、データ分析基盤構築・MLOps構築支援でご相談を受け付けています。

リアルタイム顧客分析の仕組み・ツール・費用について実務でよくある質問

導入の検討でよく挙がる質問に、判断に直結する形で答えます。

リアルタイム顧客分析はGA4だけで実現できますか？

画面で状況を確かめる範囲なら可能ですが、顧客ひとりに施策を返す用途には足りません。GA4のリアルタイムレポートは過去5分・30分の集計を見せる機能で、公式に正式なSLOを持たないベストエフォート型とされています。個別の顧客を判定して施策につなぐには、BigQueryへのストリーミングエクスポートで当日のイベントを数分以内に受け取り、そこで判定する構成が必要です。その場合も新規ユーザーの参照元などが含まれない点を前提に条件を組んでください。

リアルタイム顧客分析とリアルタイム分析は何が違いますか？

判定の単位が違います。リアルタイム分析はサイト全体の売上や稼働状況など、集団の数字を短い間隔で追う考え方全般を指します。リアルタイム顧客分析はその中でも、顧客ひとりの行動をその顧客の属性と突き合わせ、本人に施策を返すところまでを含む用途です。そのため、ID統合と配信の仕組みが必須になり、集団の数字を見るだけの構成より準備が多くなります。

CDPを導入しないとリアルタイム顧客分析はできませんか？

パッケージ型CDPは必須ではありません。GA4とBigQueryを使えば、ストリーミングエクスポートで受け取ったイベントに日次で算出した顧客属性を結合し、自社で判定する構成が組めます。パッケージ型CDPを選ぶ価値が出るのは、広告媒体やメール配信ツールとの連携をすでに用意された部品で済ませたい場合や、判定条件を現場の担当者が画面で編集したい場合です。逆に、判定条件が少なく社内にSQLを書ける人がいるなら、BigQuery側で組むほうが費用を抑えられます。

リアルタイム顧客分析の費用はどこで膨らみますか？

データの転送費より、判定の仕組みと配信側の開発、運用の人件費で膨らみます。GA4のストリーミングエクスポートの追加費用は1GBあたり0.05米ドルで、1日10万イベント程度なら月1米ドルにも届きません。一方で、Webサイトの表示切り替えやプッシュ通知の仕組みを新たに作る開発費、判定が止まったときに対応する体制の費用は、この何百倍にもなりえます。見積もりでは、転送費ではなく配信側と運用側の項目を先に確認してください。

中小規模のECサイトでも導入する意味はありますか？

条件に当たる顧客の件数次第です。1日のセッションが数百件規模で、カゴ落ちのような条件に当たる顧客が1日数件なら、リアルタイム化しても効果を比べられるだけの件数が集まりません。まず日次のセグメントでカゴ落ちメールなどを運用し、効果が確認できてから、セッション内の表示切り替えに進むかを判断してください。その段階でもGA4とBigQueryの組み合わせなら初期費用を抑えて試せます。