会員データを店舗とECで1つにする手順

店舗で入会した会員と、ECで登録した会員が別々に存在しています。同じ人なのに、購入履歴が2つに分かれています。

この状態では、顧客あたりの購入金額も、来店頻度も、実態より低く出ます。分析の精度以前に、事実と違う数字で意思決定しています。

統合は技術的には難しくありません。難しいのは、どこまでを同一人物と見なすかを決めることです。

問題：分かれたまま集計している

どの数字も「実態より悪い方向」にずれます。改善施策の効果も同じだけ薄く見えます。

統合のキーを決める

同一人物と判定する材料を決めます。1つでは足りません。

現実的な組み合わせは次の3段階です。

迷ったら統合しません。誤って統合すると、他人の購入履歴が混ざります。分けたままなら、数字が低く出るだけで済みます。

表記ゆれの整え方

判定の前に、両側のデータを同じ形に揃えます。

電話番号を数値型で扱わないでください。先頭の0が消え、一致しなくなります。

進め方

1. 両側のデータを別々のテーブルとして取り込む（元データは変更しない）
2. 表記を揃えた列を追加する（元の列は残す）
3. 判定ルールで候補を作る
4. 候補の件数を確認する
5. 統合用のID（共通ID）を発行する
6. 分析はこの共通IDで行う

要点は、元のシステムのデータを書き換えないことです。統合は分析基盤の上だけで行い、店舗側・EC側のシステムはそのままにします。書き換えると、戻せなくなります。

統合表の形

判定に使ったキーを残します。後から「なぜこの2件が同一人物なのか」を説明できる状態にしておきます。

統合したあとに壊れるもの

ここを想定していないと、統合の直後に混乱します。

会員数が減ることを、事前に関係部署へ伝えます。何も言わずに数字が減ると、集計ミスを疑われます。

個人情報の扱い

取得時の利用目的を先に確認します。技術的にできることと、してよいことは別です。

やること

手順1. 重複の規模を先に数える

統合の前に、どのくらい重なっているかを数えます。

-- 電話番号が両方に存在する件数
SELECT COUNT(DISTINCT phone_normalized)
FROM store_members
WHERE phone_normalized IN (
  SELECT phone_normalized FROM ec_members
)

重複が1%なら、統合の優先度は低いです。20%あるなら効果は大きいです。数えてから着手を決めます。

手順2. 100件だけ目で確認する

自動判定の結果から100件を抜き出し、本当に同一人物かを目で見ます。誤判定が1件でもあれば、ルールを緩めすぎています。

手順3. 保留した候補の扱いを決める

「要確認」に落ちた候補は、放置すると永遠に残ります。

手順4. 定期実行にする

新しい会員は毎日増えます。判定を月1回など定期的に回します。初回だけで終わらせると、半年で元に戻ります。

失敗例

まとめ

• 分かれたままだと、どの数字も実態より悪い方向にずれます
• 判定は3段階に分け、「要確認」は統合しません。誤統合は戻せません
• 表記を揃えてから判定します。電話番号は文字列で扱います
• 元のシステムは書き換えず、分析基盤の上だけで統合します
• 判定に使ったキーを残します。後から説明できる状態にしておきます
• 統合すると会員数が減ります。事前に関係部署へ伝えます
• 取得時の利用目的に、統合して分析することが含まれるかを先に確認します
• 月1回など定期実行にします。初回だけでは半年で元に戻ります

最初にやることは、重複がどのくらいあるかを数えることです。1%なら後回しでよく、20%あれば最優先になります。