本文へ移動
Palantir 更新日: 2026年5月2日 約18分で読めます

通販CRMにおける顧客分析の考え方|パランティア的に購買行動を読む


言葉が強すぎると感じるかもしれない。「顧客を『敵』として分析する」

しかしこれは比喩の問題ではなく、「思考の構造」の問題だ。

軍事インテリジェンスで「敵」を分析するとき、アナリストが問うのは「敵の能力は何か」ではなく「敵は次に何をするか」だ。
過去の行動パターン、現在の位置、使用可能なリソース、動機。
これらを統合して「次の行動を予測する」ことが目的だ。

顧客分析において、マーケターが問うべきなのも「この顧客は次に何をするか」だ。
今持っている購買力(能力)を問うのではなく、次の購買が起きるか・いつ起きるか・何が引き金になるかを予測することが目的だ。

「過去に何をしたか」を見ることと、「次に何をするか」を予測することは、全く異なる認知作業だ。 多くの通販企業はデータから前者しか読んでいない。


HUMINT・SIGINT・OSINTを通販に翻訳する

軍事インテリジェンスには、情報収集の種類を分類する概念がある。

HUMINT(Human Intelligence):人的情報
人間から直接収集する情報。スパイ活動、尋問、協力者からの報告など。

SIGINT(Signals Intelligence):シグナル情報
通信・電磁波・電子信号から収集する情報。電話の傍受、暗号解読など。

OSINT(Open Source Intelligence):公開情報インテリジェンス
公開されている情報から収集・分析する。ニュース、SNS、地図情報など。

これらを通販に翻訳すると

軍事用語通販での対応具体例
HUMINT顧客の声カスタマーサポートの会話記録、アンケート、レビュー、クレーム履歴
SIGINT行動シグナルサイト閲覧ログ、クリック履歴、カート追加・削除、メール開封・クリック
OSINT外部文脈データ天気予報、競合の価格情報、SNSトレンド、季節性データ

パランティアのシステムが強いのは、この三種類の情報を同一のプラットフォームに統合し、相互に参照できるようにしているからだ。

HUMINTだけでは「顧客が不満を持っている」しか分からない。
しかしSIGINTと組み合わせると「不満を持った顧客がその後7日以内に購買を辞めているパターン」が見えてくる。
そこにOSINTを加えると「競合が値下げした翌週に顧客の離脱が加速している」という外部要因との相関が明らかになる。


「購買前の行動シグナル」を読む—インテリジェンス思考の顧客分析SQL

軍事アナリストは「攻撃の前兆」を読む訓練を受けている。

兵器の移動、通信量の増加、補給物資の集積

これらは「攻撃の前兆シグナル」だ。このシグナルをいつ・どのくらいの精度で検知できるかが、防御の勝敗を決める。

通販における「購買の前兆シグナル」は何か。

-- 「購買前72時間の行動パターン」を分析する
-- 購買に至った顧客が、購買の何日前にどんな行動をしていたかを把握する

WITH purchase_events AS (
  -- 購買イベントを取得
  SELECT
    customer_id,
    TD_TIME_FORMAT(time, 'yyyy-MM-dd', 'JST')   AS purchase_date,
    time                                         AS purchase_time
  FROM orders
  WHERE
    status = 'completed'
    AND TD_TIME_RANGE(time, '2024-10-01 JST', '2024-12-31 JST')
),
pre_purchase_behavior AS (
  -- 購買前72時間(3日)の行動ログを取得
  SELECT
    b.customer_id,
    p.purchase_date,
    TD_TIME_FORMAT(b.time, 'yyyy-MM-dd', 'JST') AS behavior_date,
    b.event_type,                               -- 'view' / 'cart_add' / 'cart_remove' / 'search' など
    b.product_category,
    b.page_url,
    -- 購買からの経過時間(時間)
    (p.purchase_time - b.time) / 3600           AS hours_before_purchase
  FROM purchase_events p
  JOIN site_behavior_log b
    ON p.customer_id = b.customer_id
    AND b.time BETWEEN p.purchase_time - 259200  -- 72時間前(秒換算)
                   AND p.purchase_time
)
-- 購買前の行動タイプ別・時間帯別の頻度を集計
SELECT
  event_type,
  CASE
    WHEN hours_before_purchase <= 6  THEN '購買6時間前以内'
    WHEN hours_before_purchase <= 24 THEN '購買24時間前以内'
    WHEN hours_before_purchase <= 48 THEN '購買48時間前以内'
    ELSE                                  '購買72時間前以内'
  END                                              AS time_bucket,
  COUNT(*)                                         AS event_count,
  COUNT(DISTINCT customer_id)                      AS customer_count,
  ROUND(AVG(hours_before_purchase), 1)             AS avg_hours_before
FROM pre_purchase_behavior
GROUP BY event_type, time_bucket
ORDER BY time_bucket, event_count DESC

このクエリを実行すると、「購買の6時間前に最も多く発生している行動は何か」が分かる。
例えば「商品ページを2回以上閲覧」が購買の6時間前に集中しているとすれば、それが「購買の前兆シグナル」だ。


「離脱の前兆」を読む——チャーン予測の実装

軍事アナリストが最も恐れるのは「予期しない離脱」だ。

信頼していた同盟国が突然離反する、協力者が内通している予期しない離脱は作戦全体を崩壊させる。

通販における「予期しない離脱」は、優良顧客の突然の休眠だ。

重要なのは「離脱したあとに気づく」のではなく、「離脱の前に兆候を検知する」ことだ。

-- 「離脱前兆スコア」を計算する
-- 過去購買パターンと比較して「いつもと違う」を検知する

WITH customer_baseline AS (
  -- 各顧客の「通常の購買パターン」を過去1年から算出する
  SELECT
    customer_id,
    COUNT(order_id)                        AS annual_order_count,
    AVG(amount)                            AS avg_order_amount,
    -- 平均購買間隔(日数)
    AVG(
      DATE_DIFF('day', prev_order_date, order_date)
    )                                      AS avg_purchase_interval_days,
    MAX(order_date)                        AS last_order_date
  FROM (
    SELECT
      customer_id,
      order_id,
      order_date,
      amount,
      LAG(order_date) OVER (
        PARTITION BY customer_id ORDER BY order_date
      )                                    AS prev_order_date
    FROM orders
    WHERE
      status = 'completed'
      AND order_date BETWEEN DATE_ADD('day', -365, CURRENT_DATE)
                         AND CURRENT_DATE
  ) t
  GROUP BY customer_id
),
churn_signals AS (
  SELECT
    b.customer_id,
    b.avg_purchase_interval_days,
    b.last_order_date,
    -- 最終購買からの経過日数
    DATE_DIFF('day', b.last_order_date, CURRENT_DATE) AS days_since_last_order,
    -- 「平均購買間隔の何倍が経過しているか」を計算
    ROUND(
      DATE_DIFF('day', b.last_order_date, CURRENT_DATE)
        / NULLIF(b.avg_purchase_interval_days, 0)
    , 2)                                   AS interval_multiplier,
    b.annual_order_count,
    b.avg_order_amount
  FROM customer_baseline b
  WHERE b.annual_order_count >= 2  -- 購買が2回以上ある顧客のみ対象
)
SELECT
  customer_id,
  avg_purchase_interval_days,
  days_since_last_order,
  interval_multiplier,
  -- 離脱リスクスコア(0〜100)
  CASE
    WHEN interval_multiplier >= 3.0 THEN 90   -- 通常の3倍以上 → 高リスク
    WHEN interval_multiplier >= 2.0 THEN 70   -- 通常の2倍以上 → 中リスク
    WHEN interval_multiplier >= 1.5 THEN 40   -- 通常の1.5倍以上 → 低リスク
    ELSE                                   10  -- 正常範囲
  END                                      AS churn_risk_score,
  -- ウィンバック施策のタイミング判定
  CASE
    WHEN interval_multiplier >= 3.0 THEN '緊急ウィンバック(SMS推奨)'
    WHEN interval_multiplier >= 2.0 THEN 'ウィンバックメール(クーポン付き)'
    WHEN interval_multiplier >= 1.5 THEN 'リマインドメール(商品レコメンド)'
    ELSE                                  '正常モニタリング継続'
  END                                      AS recommended_action
FROM churn_signals
ORDER BY churn_risk_score DESC, interval_multiplier DESC

このクエリが「離脱の前兆」を検知するための基本的な実装だ。

「平均購買間隔の1.5倍が経過している顧客」は、まだ完全に離脱していないが「いつもより遅い」というシグナルを出している。
ここでリマインドメールを送るのと、「3倍が経過してから」送るのでは、施策の効果が大きく異なる。

インテリジェンス思考では「早期警戒」が命だ。


「顧客の動機」を読む——なぜその顧客は買うのか

パランティアのアナリストが「敵の動機」を分析するように、「顧客の動機」を分析することがインテリジェンス思考の核心だ。

しかし「動機」は直接観察できない。行動のパターンから推論するしかない。

通販においてよく観察される「購買動機のパターン」は大きく5つある。

パターン①:「補充動機」
消耗品が切れるから買う 特徴:定期的なサイクルで同一・類似商品を購買する。購買間隔が安定している。

パターン②:「ギフト動機」
誰かへのプレゼントとして買う 特徴:クリスマス・誕生日前後に購買。普段と異なるカテゴリへの単発購買。高単価商品へのジャンプ。

パターン③:「トレンド動機」
話題だから試してみる 特徴:新商品への早期購買。SNSトレンドとの相関。繰り返し購買率が低い(1回で終わることが多い)。

パターン④:「問題解決動機」
困っていることを解決したい 特徴:検索ワードが具体的・機能的。レビューを大量に読む行動。比較購買(複数商品の閲覧→1商品購買)。

パターン⑤:「信頼動機」
このブランドが好きだから買う 特徴:ブランドの直接検索。新商品への素早い反応。価格比較なしの購買。クーポンへの反応が低い。

-- 顧客ごとの「購買動機パターン」を推定するSQL

WITH purchase_patterns AS (
  SELECT
    o.customer_id,
    -- 補充動機:同一カテゴリの定期購買パターン
    STDDEV(DATE_DIFF('day', LAG(o.order_date) OVER (
      PARTITION BY o.customer_id, o.product_category_id
      ORDER BY o.order_date
    ), o.order_date))                            AS purchase_interval_stddev,
    -- トレンド動機:初回購買後の継続率
    COUNT(DISTINCT o.order_id)                   AS total_orders,
    COUNT(DISTINCT o.product_category_id)        AS category_diversity,
    -- 信頼動機:クーポン未使用購買の割合
    AVG(CASE WHEN o.coupon_used = FALSE THEN 1.0 ELSE 0.0 END) AS no_coupon_ratio
  FROM orders o
  WHERE
    o.status = 'completed'
    AND o.order_date >= DATE_ADD('day', -180, CURRENT_DATE)
  GROUP BY o.customer_id
)
SELECT
  customer_id,
  -- 動機スコアから主動機を推定
  CASE
    WHEN purchase_interval_stddev < 10
     AND total_orders >= 3
    THEN '補充動機型(定期購買顧客)'
    WHEN category_diversity = 1
     AND total_orders = 1
    THEN 'トレンド動機型(単発購買者)'
    WHEN no_coupon_ratio >= 0.8
     AND total_orders >= 3
    THEN '信頼動機型(ロイヤル顧客)'
    WHEN category_diversity >= 4
    THEN '問題解決動機型(多様なニーズを持つ顧客)'
    ELSE 'ミックス型(複合動機)'
  END                                            AS motivation_type,
  purchase_interval_stddev,
  total_orders,
  category_diversity,
  ROUND(no_coupon_ratio * 100, 1)               AS no_coupon_pct
FROM purchase_patterns
ORDER BY total_orders DESC

インテリジェンスの「判断」と「行動」を分離する

軍事インテリジェンスの組織において、「情報を収集・分析するアナリスト」と「作戦を実行する指揮官」は明確に分かれている。

アナリストは「敵は3日後に北から攻撃する可能性が80%」という判断を提供する。指揮官は「だったら北の防衛を強化する」という決断を下す。このどちらが欠けても、戦争には勝てない。

通販企業でも同じ分離が必要だ。

データエンジニア・アナリストの役割
「顧客Aは今から3日以内に離脱する確率が75%であり、ウィンバックメールへの過去の反応率は40%、クーポンへの反応率は60%」という判断を提供する。

マーケターの役割
「だったら今日クーポン付きのウィンバックメールを送る」という決断を下す。

しかし実際の通販企業では、この分離が曖昧になりがちだ。データエンジニアが「判断(何をすべきか)」まで踏み込みすぎると施策の自律性が失われ、マーケターが「分析(何が起きているか)」まで担うと精度が落ちる。

パランティア的なアプローチは「判断のシステム化」だ。 アナリストが毎回手動で行う判断のロジックを、SQLとdataパイプラインで自動化する。そしてその出力を「マーケターが意思決定できる形」で届ける。

次回のシリーズでは、「在庫の予測的補充」という、より複雑なインテリジェンスの問いに挑む。


次回予告

「予測的補充という作戦計画—在庫を『弾薬』として管理する」

弾薬が切れた軍は戦えない。在庫が切れた通販は売れない。「予測的補充」という思想と、それをSQLで実装する具体的な設計を解説する。


次のアクション

SQLやデータ活用を、手元で試しながら理解する

記事で読んだ考え方を、SQL練習場や関連カテゴリの記事でさらに深掘りできます。相談やご依頼もお問い合わせページから受け付けています。

SQL練習場で試す お問い合わせ

この記事を書いた人:martechfarm

Treasure Data Top Lapidarist Award受賞。

SQL / Digdag / Python / CDP設計 / CRM設計を横断し、企業のデータ活用を支援。

実績・支援内容を見る →

MarTech Farmをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む