顧客セグメンテーション入門：RFM・ライフサイクル・行動で顧客を分け、設計書に残す

メルマガを全員に同じ内容で送る運用から一歩進めようとすると、最初に「誰を、いくつのグループに分けるか」という問いに行き当たります。分け方は無数にあり、分けるほど文面と運用の手間は増えます。この記事では、購買履歴から作るRFM、顧客の段階で分けるライフサイクル、閲覧やクリックで分ける行動の3つを、CRMに実際に入っているデータで組める形に落とし込みます。あわせて、個人情報の扱いと、結果をセグメント設計書として残す手順を扱います。

セグメント数は、打てる施策の数で決まる

セグメント設計の失敗でいちばん多いのは、分析が先行して施策が追いつかない形です。顧客を20グループに分けたものの、用意できた文面は「新規向け」「通常」「休眠向け」の3本だけ、という状況を考えてみてください。この場合、20グループのうち17は分けた意味を持ちません。

順序を逆にします。まず今期に実行できる施策を数えます。ウェルカムメール、購入後のフォロー、休眠顧客への呼びかけ、新商品の案内の4種類が回せるなら、必要なセグメントは4〜6個です。施策を1つ増やせる体制になった時点で、セグメントを1つ増やします。

分け方の軸は大きく3つあります。それぞれ必要なデータと弱点が違うため、並べて比べておきます。

3つは排他的ではなく、段階的に導入するのが現実的です。購買履歴があれば作れるRFMから始め、次にライフサイクルを足し、行動データは同意と計測の仕組みが整ってから加えます。計測側の考え方はカスタマージャーニー分析：ファネル・コホート・継続率で扱っています。

CRMに入れるデータは最小限から：項目と個人情報としての扱い

RFMとライフサイクルを組むだけなら、顧客単位で次の項目があれば足ります。

• 顧客ID（メールアドレスとは別に振る）
• 登録日・初回購入日・最終購入日
• 注文ごとの日付・注文番号・金額、返品や返金の額
• メール配信の同意状態（同意した日時、取得した画面や経路、同意時に表示した文言）
• 配信停止の日時

年齢、性別、職業といった属性は、持っていれば使えます。ただ、集める前に「その属性で文面を変えるのか」を確認してください。変えないのなら集めない方が、管理の負担も、万一の漏えい時の影響も小さくなります。

ここから個人情報の扱いが関わってきます。個人情報保護委員会のQ&Aは、利用目的を「できる限り」特定することを求め、「お客様のサービスの向上」のような抽象的な記載では足りないという考え方を示しています。さらに、行動や関心を分析するプロファイリングにあたる処理では、分析結果の使い道だけでなく、分析そのものを利用目的に含めて示す必要があるとされています。RFMスコアは購入履歴の分析にあたるため、プライバシーポリシーの利用目的に「購入履歴を分析し、お客様に合った商品・サービスをご案内するため」のように、分析を含めた形で書いておくのが無難です。文言は事業内容によって変わるので、通則編のガイドラインで最新の記述を確認し、判断に迷う場合は専門家に相談してください。

もう一つ、抽出条件に必ず入れておきたいのが配信の可否です。RFMで「優良」と判定された人でも、広告・宣伝のメールを送れるかどうかは別の問題です。迷惑メール相談センターの解説によれば、特定電子メール法は原則として、あらかじめ送信に同意した人以外への広告宣伝メールの送信を禁じています。公開されているメールアドレス宛てなどの例外はありますが、例外の当てはまりは個別の事情で変わるため、セグメントの抽出クエリには「配信同意あり、かつ配信停止なし」という条件を固定で入れておくのが運用上は確実です。

この条件は、後から追加される抽出クエリで抜け落ちやすい点でもあります。配信リストを手作業でエクスポートするたびに条件を書き直す運用だと、ある月のキャンペーンだけ配信停止者が混ざる、という事故が起こります。同意状態を条件に含めたビュー（保存済みのセグメント）を1つ作り、すべての抽出がそこから始まる形にしておくと防げます。

RFMを手で組む：仮のECで、集計からスコアまで

数字はすべて説明用の仮のものです。文房具を扱う架空のEC（顧客1,000人、購入履歴は直近12か月）を想定します。

手順1：顧客ごとにR・F・Mを集計する

R（Recency）は最終購入からの日数、F（Frequency）は購入回数、M（Monetary）は購入金額です。注文データがあれば、次のような集計で出せます。

-- 顧客ごとのR・F・Mを集計（MySQL風の記法。DBにより関数名は異なります）
SELECT
  customer_id,
  DATEDIFF(CURRENT_DATE, MAX(order_date))        AS r_days,
  COUNT(DISTINCT order_id)                       AS f_orders,
  SUM(order_amount - COALESCE(refund_amount, 0)) AS m_amount
FROM orders
WHERE order_date >= DATE_SUB(CURRENT_DATE, INTERVAL 12 MONTH)
GROUP BY customer_id;

金額から返金分を引いている点に注意してください。返品の多い顧客を高いMのまま「優良」に入れると、施策の狙いとずれます。

手順2：5段階のしきい値を決める

各軸を1〜5点に変換します。ここでは、事業側で決める固定のしきい値を使います（数値は仮の例）。

Arthur Hughes『Strategic Database Marketing』（McGraw-Hill）は、RFMを実務向けに整理した古典として知られています。第3版の目次にはRFM分析を扱う章があり、各軸を顧客数ベースで5段階に分けて組み合わせる方法がよく紹介されます（版によって記述が異なるため、詳細は原典で確認してください）。上の表が顧客数の五等分ではなく固定のしきい値なのは、運用上の理由からです。五等分は毎月の分布で境界が動くため、顧客の行動が変わっていなくても、他の顧客の動き次第でスコアが上下します。施策の効果を月をまたいで比べたいときには、固定のしきい値の方が読みやすくなります。

手順3：スコアをセグメントにまとめる

仮の顧客4人にスコアを付けると、次のようになります。

125通りの組み合わせをそのまま運用する必要はありません。RとFを軸に、次の4グループと「その他」に畳みます。

Mをこの表の条件に入れていないのは意図的です。購入金額は少数のヘビーユーザーに偏りやすく、条件に加えるとグループが細かくなりすぎます。Mは、優良セグメントの中で特別な案内を出す相手を選ぶときの追加条件として使えば十分です。

RFMには限界もあります。Fader、Hardie、Leeの研究（Journal of Marketing Research, 2005）は、RFMの3つの値だけから将来の価値を推定する確率モデルを提案しています。その分析が示す見方の一つは、過去の購入パターンが異なる顧客同士でも、将来の期待価値は近いことがあるということです。つまりRFMのスコアは「過去の要約」であり、将来の購入確率そのものではありません。購買サイクルが商品によって大きく違う事業（日用品と家具が同じ店にある場合など）では、Rのしきい値を商品カテゴリごとに分ける必要もあります。

ライフサイクルと行動を重ねる：2軸まで、6グループまで

RFMは購入履歴のある顧客にしか使えないため、見込み客や初回購入前の人は別の軸で扱います。ライフサイクルの段階は、たとえば次のように定義します（日数は仮の例）。

1. 見込み：メール登録済みで、まだ購入なし
2. 初回購入後：初回購入から30日以内
3. リピート：2回以上購入し、最終購入から120日以内
4. 休眠：最終購入から121日以上（RFMの休眠セグメントと同じ線引きにそろえる）

「初回購入後」と「リピート」の境目を、日数と購入回数のどちらで決めるか。ここを文書に残していないと、担当者ごとに別の抽出をしてしまいます。ライフサイクルの各段階で何を伝えるかは、ライフサイクルマーケティング：顧客維持プランの作り方で段階×メッセージ×チャネルのマトリクスとして整理しています。

行動データは、まず1〜2個のフラグに絞ります。「直近7日以内にカートへ入れたが未購入」「直近30日に特定カテゴリのページを複数回閲覧」といった条件です。注意点として、閲覧履歴の取得にタグやCookieを使う場合は、同意の取り方や、電気通信事業法の外部送信規律に基づく通知・公表の要否を確認する必要があります。取得方法の整理が済んでいない段階では、メール内のクリックなど、自社が直接把握できる行動から始める方が安全です。

ただし、軸を重ねるほど精度が上がるわけではありません。ライフサイクル4段階と行動フラグ2つを掛け合わせるだけで8グループになり、そこにRFMの4グループを重ねると、1グループが数十人という状態がすぐに生まれます。仮にあるセグメントが40人だとして、文面Aと文面Bで反応した人の差が数人なら、それは文面の差なのか偶然なのか判別できません。テストに必要な人数の考え方はCRO：勘からテスト計画へ移行する方法に譲りますが、少なくとも「施策ごとに比較できる人数が確保できるか」は、セグメントを増やす前の関門にしてください。

RFMそのものが合わない事業もあります。月額課金のように購入頻度が契約で決まっている場合、Fはほとんど情報を持ちません。そうした事業では、利用頻度や機能の利用状況を使うライフサイクルの軸に重心を移します。

セグメント設計書：書く項目と、見直しの周期

集計とスコアリングは、セグメント設計書に落とさない限り属人化します。1セグメントにつき1行で、次の項目を書きます。

見直しは周期を決めて行います。月次ではしきい値に対する人数の分布と、セグメント間の移動を見ます。優良セグメントが急に膨らんだなら、行動が変わったのではなく、セール期間で全員のFが上がっただけかもしれません。四半期ごとには、1つのセグメントに対して施策が実際に動いているかを確認し、使っていないセグメントは廃止します。

AIは、この設計書づくりの補助に使えます。たとえば抽出SQLの下書き、セグメント名の案、設計書の記入漏れの指摘といった用途です。ただしAIには、顧客の氏名やメールアドレスを含む実データを貼らないでください。個人情報保護委員会は2023年に生成AIサービスの利用に関する注意喚起を出しており、個人データをプロンプトに入力する場合は、利用目的の範囲内か、提供事業者が入力データを機械学習に使わないかなどを確認するよう求めています。列名と、仮に作った数行のデータだけで足りる作業を選んでください。

設計書の次の段階は、セグメントごとにどのタイミングで何を送るかを決めるシナリオ設計です。続きは自動メールシナリオの設計：ウェルカム・オンボーディング・フォローにまとめています。自社の顧客データでセグメント設計書と施策表を組み、講師のレビューを受ける演習は、カスタマーエクスペリエンス実践コースで扱っています。