RFM分析に必要な
データ準備と前処理のポイント
「分析精度はデータの質で9割決まる」

RFM分析に最低限必要なデータ項目

RFM分析を始めるために必要なデータは、実はそれほど多くありません。最低限、以下の3つの項目が含まれた購買データがあれば分析を開始できます。

必須項目（これがないと分析不可）

• 顧客ID：各顧客を一意に識別するためのID。メールアドレスや会員番号が一般的
• 購買日時：注文が確定した日付（年月日が必須、時刻はあれば望ましい）
• 購買金額：注文1回あたりの合計金額（税込み・送料込みで統一することを推奨）

あると分析の幅が広がる項目

• 注文ID：1回の注文を一意に識別するID。同一顧客の複数購入を正確にカウントするために有用
• 商品カテゴリ：購入商品のカテゴリ情報。セグメントごとの商品傾向分析に活用
• 購入チャネル：EC、店舗、電話注文など。チャネル別のRFM分析が可能になる
• クーポン利用有無：プロパー購入かセール購入かの判別に使う
• 返品フラグ：返品データを除外しないと、MonetaryやFrequencyが不正確になる

これらのデータは、ほとんどのECプラットフォームの注文データから取得可能です。まずは「顧客ID・購買日時・購買金額」の3項目だけで分析を始め、精度を上げたい段階で追加項目を取り入れましょう。

データクレンジング：重複・欠損・異常値の処理

生のデータをそのままRFM分析に使うと、結果が歪みます。分析前のデータクレンジング（前処理）は、分析精度を左右する最も重要なステップです。

重複データの処理

同じ注文が複数行にわたって記録されているケースは珍しくありません。以下の原因で重複が発生します。

• システム上の二重登録：決済エラー後の再処理などで同一注文が複数回記録される
• 商品明細レベルのデータ：1注文に複数商品が含まれる場合、商品ごとに行が分かれている。注文単位に集約が必要
• CSVエクスポート時のバグ：データ抽出時に意図しない重複が混入する

対処法：注文IDと顧客IDの組み合わせで重複チェックを行い、完全に同一の行は削除します。商品明細レベルのデータは、注文ID単位で金額を合算してから分析に使います。

欠損データの処理

顧客IDや購買日時が空欄のレコードは、RFM分析に使用できません。以下のルールで処理しましょう。

• 顧客IDが欠損：ゲスト購入の場合が多い。分析対象から除外するか、メールアドレスで代替する
• 購買日時が欠損：システムログから復元できるか確認。不可能な場合は除外する
• 購買金額が欠損またはゼロ：無料サンプルや0円注文の可能性。分析目的に応じて含めるか除外するか判断する

異常値の処理

異常に高額な注文や、明らかにテストデータと思われるレコードは、分析結果を大きく歪めます。

• 極端な高額注文：上位0.1%の金額を確認し、法人注文やテスト注文が混在していないかチェック
• マイナス金額：返品処理が含まれている。返品は別途集計し、元の注文と紐づけて処理する
• 未来日付の注文：データ入力ミスの可能性。目視で確認して修正または除外する
• テスト注文：社内テスト用のアカウントや注文を事前に除外リストに入れておく

購買日時のフォーマット統一

RFM分析のRecency（最新購買日）を正確に算出するためには、購買日時のフォーマットが統一されていることが不可欠です。複数のデータソースを統合する場合、日付フォーマットの不一致は最もよくあるトラブルの一つです。

よくある日付フォーマットの問題

• 和暦と西暦の混在：「令和6年1月15日」と「2024/01/15」が混在しているケース
• 区切り文字の不統一：「2024/01/15」「2024-01-15」「2024.01.15」「20240115」が混在
• 月日の順序の違い：日本式「2024/01/15」とアメリカ式「01/15/2024」の混在（海外ツール利用時に注意）
• タイムゾーンの不一致：UTCとJSTの差（9時間）で日付がズレる。特に海外サーバーを使用している場合に発生
• 文字列型と日付型の混在：Excelで日付が文字列として保存されている場合、ソートや計算が正しく動作しない

統一手順

1. すべてのデータソースの日付フォーマットをサンプリングして確認する
2. 統一フォーマットを決める（推奨：YYYY-MM-DD形式、ISO 8601準拠）
3. Excel / スプレッドシートの場合は、列の書式設定を「日付」に変更し、表示形式をYYYY-MM-DDに統一する
4. Pythonの場合は pd.to_datetime()、SQLの場合は CAST や STR_TO_DATE で変換する
5. 変換後に最小日付・最大日付を確認し、想定範囲内であることを検証する

日付フォーマットの統一は地味な作業ですが、これを怠るとRecencyの計算が根本から狂います。特に複数システムのデータを統合する場合は、必ず最初に実施しましょう。

顧客IDの名寄せと統合の実践

RFM分析の精度を最も大きく左右するのが「顧客IDの名寄せ」です。同一人物が異なるIDで登録されていると、本来1人の顧客のRecency・Frequency・Monetaryが複数人に分散し、正確なスコアリングができません。

名寄せが必要になる典型的なケース

• EC会員とゲスト購入：同じ人がログイン購入とゲスト購入を使い分けている
• 複数デバイス：PCとスマホで別のアカウントを作成している
• オンラインとオフライン：ECサイトと実店舗で別の顧客IDが付与されている
• メールアドレス変更：転職やプロバイダ変更でメールアドレスが変わった
• 旧システムからの移行：システムリプレイス時にIDの体系が変わった

名寄せの手法

名寄せには「確定マッチ」と「推定マッチ」の2つのアプローチがあります。

確定マッチ：一意性が高いキーで突合する方法です。精度は高いが、カバー率は限定的です。

• メールアドレスの完全一致
• 電話番号の完全一致（ハイフンの有無を統一してから比較）
• 会員番号やポイントカード番号の紐づけ

推定マッチ：複数の属性情報を組み合わせて同一人物と推定する方法です。カバー率は高いが、誤マッチのリスクがあります。

• 氏名＋住所＋電話番号の組み合わせ（表記ゆれに注意）
• 氏名＋生年月日の組み合わせ
• 配送先住所の一致（同居家族を誤って統合しないよう注意）

まずは確定マッチで安全に統合し、その後必要に応じて推定マッチで補完するのが現実的な進め方です。名寄せの結果は必ず「統合ログ」として記録し、問題が発生した際にロールバックできるようにしましょう。

ECプラットフォーム別のデータ出力方法

主要なECプラットフォームから、RFM分析に必要なデータを出力する方法を紹介します。

Shopify

Shopifyは注文データのエクスポート機能が充実しています。

1. 管理画面「注文管理」→「エクスポート」からCSVをダウンロード
2. 必要な列：Email（顧客ID代替）、Created at（注文日時）、Total（注文金額）
3. 注意点：Shopifyの日付はUTCで出力されるため、JSTに変換が必要（+9時間）
4. Shopify APIを使えば、自動でデータ取得する仕組みも構築可能

BASE

BASEは管理画面からのCSV出力に対応しています。

1. 「注文管理」→「CSVダウンロード」から期間を指定して出力
2. 必要な列：購入者のメールアドレス、注文日、合計金額
3. 注意点：BASEでは一度にダウンロードできるデータ量に制限がある場合があるため、期間を分けて出力する

EC-CUBE

EC-CUBEはオープンソースのため、データベースから直接抽出するのが最も柔軟です。

1. 管理画面「受注管理」→「受注マスター」からCSVエクスポート
2. またはデータベース（dtb_order テーブル）から直接SQLで抽出
3. 必要な列：customer_id、order_date、payment_total
4. 注意点：キャンセル済み注文のステータスを除外するフィルタが必要

その他のプラットフォーム（makeshop, カラーミーショップ等）

多くのECプラットフォームは、管理画面からCSV形式で注文データを出力できます。共通して注意すべきポイントは以下のとおりです。

• 文字コードの確認（Shift_JIS / UTF-8）。Excelで開く際に文字化けする場合はエンコードを変換する
• ヘッダー行の有無と列名の確認
• 金額に含まれる項目の確認（税込み/税抜き、送料込み/送料別）
• キャンセル・返品注文のフィルタリング

データ更新頻度と鮮度の重要性

RFM分析は「スナップショット分析」であり、分析時点のデータが古ければ、結果も古くなります。データの鮮度は、施策のタイミングに直結する重要な要素です。

更新頻度の目安

• 日次更新（推奨）：Winback施策やF2転換施策など、タイミングが重要な施策を実施している場合。自動化の仕組みが必要
• 週次更新：多くのEC事業者にとって現実的な頻度。毎週月曜に前週分のデータを取り込む運用
• 月次更新：最低限の頻度。月次レポートやセグメント見直しには対応できるが、リアルタイム施策には不向き

鮮度が落ちるとどうなるか

データの鮮度が低い状態で施策を実施すると、以下のような問題が発生します。

• すでに購入済みの顧客にWinbackメールを送ってしまう（顧客体験の低下）
• 離脱が進んでいる顧客を「アクティブ」と誤判定し、手遅れになる
• F2転換の最適タイミング（初回購入後7〜14日）を逃す
• セール直後のデータが反映されず、実態と乖離したセグメントで施策を実行してしまう

自動化のポイント

データ更新の自動化は、RFM分析を継続的に運用するための必須条件です。以下の方法が一般的です。

• API連携：ECプラットフォームのAPIを使い、定期的にデータを自動取得する
• CSV自動インポート：Google DriveやS3にCSVを自動出力し、分析ツールが自動で読み込む
• データベース直接連携：ECのデータベースと分析基盤を直接接続する（最もリアルタイム性が高い）

分析開始前のチェックリスト

データの準備が整ったら、分析を始める前に以下のチェックリストを確認しましょう。一つでも問題があると、分析結果の信頼性が低下します。

データ品質チェック

• 顧客IDに欠損（NULL・空文字）はないか？
• 購買日時の形式は統一されているか？（YYYY-MM-DD推奨）
• 購買金額にマイナス値や極端な異常値はないか？
• キャンセル・返品注文は適切に除外（またはフラグ付け）されているか？
• テスト注文や社内注文は除外されているか？
• 重複レコードは排除されているか？

データカバレッジチェック

• 分析対象期間は十分か？（最低1年分、理想は2〜3年分のデータ）
• データの欠落期間はないか？（システム障害やデータ移行で一部期間が抜けていないか）
• 全チャネルのデータが含まれているか？（ECのみ？店舗も含む？）
• ゲスト購入のデータは含まれているか？除外する場合、その影響範囲を把握しているか？

名寄せチェック

• 同一人物が複数の顧客IDで登録されていないか？
• 名寄せを実施した場合、統合ログは保存されているか？
• 名寄せ後のユニーク顧客数は妥当か？（名寄せ前と比較して極端に減っていないか）

分析設計チェック

• Recency・Frequency・Monetaryの各スコアの閾値は自社データに基づいて設定されているか？
• スコアの分布は偏りすぎていないか？（各スコアに10〜30%ずつ分布するのが理想）
• 分析結果から導く施策は事前に定義されているか？
• 結果の報告先・活用先は明確になっているか？

このチェックリストをクリアしたデータであれば、RFM分析の結果は十分に信頼できるものになります。逆に、一つでもクリアできていない項目がある場合は、その項目を解消してから分析を始めることを強く推奨します。「汚いデータ」で分析しても、「汚い結果」しか出ません。