ECサイトの顧客データ基盤｜どこまで作るべきか

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

ECサイトの顧客データが、施策に使える形になっていないのはなぜか

ECの受注システムは、注文を正確に処理するために作られています。
注文番号を軸に、商品と金額と配送先が記録されます。

この構造では、同じ人の複数の注文が自動でつながりません。
会員登録をしていない購入や、メールアドレスが変わった場合が特にそうです。

つながらないまま集計すると、顧客数が実態より多く出ます。
多く出た顧客数で割ったLTVは、実態より低くなります。

もう1つの問題が、商品の分類です。
受注システムの商品マスタは、仕入れや在庫管理のために作られています。

広告の配分に必要なのは、粗利率と購入周期で束ねた分類です。
この2つの分類が一致していないと、集計のたびに手作業が発生します。

手作業が発生する集計は、月次では続きません。
続かない集計は、判断の材料になりません。

何が足りないかを先に特定する

基盤の整備を検討するとき、最初に決めるのは使う目的です。
目的が決まらないうちに範囲を広げると、作るだけで数年かかります。

ECで最初に必要になるのは2つです。
顧客を一意に特定することと、商品を粗利と周期で束ねることです。

この2つができれば、LTVも入口カテゴリ別の質も出せます。
行動の細かい記録は、その後の段階で構いません。

顧客を一意に特定するには、何が必要か

顧客の一意化で最初に問題になるのが、会員登録のない購入です。
ゲスト購入を許容しているECでは、注文ごとに別人として記録されます。

つなぐ手段は、メールアドレスや電話番号や配送先の組み合わせです。
どれか1つに頼ると、変更があった時点で切れます。

組み合わせの優先順位は、先に決めてください。
決めずに運用すると、集計のたびに結果が変わります。

もう1つが、同一世帯の扱いです。
同じ配送先で別のメールアドレスの場合、同一人物か家族かの判断が必要になります。

厳密に分けようとすると、判断のルールが複雑になります。
ECの判断に使う範囲では、配送先が同じでもメールアドレスが違えば別として扱うほうが運用しやすくなります。

決めたルールは文書に残し、過去の集計も同じルールで引き直します。
引き直さないと、期をまたいだ比較ができません。

顧客の一意化で決めること

一意化の精度をどこまで求めるか

一意化の精度を100%に近づけようとすると、作業が終わりません。
判断に使う範囲では、大半がつながっていれば足ります。

目安として、注文の9割が特定の顧客に紐づけば実用になります。
残りは不明として、別の区分で集計します。

不明の割合が2割を超える場合は、識別の設計に問題があります。
その場合は精度を上げる作業より、設計の見直しが先になります。

商品のデータは、どう束ね直すのか

商品マスタの分類は、仕入れ先やブランドで作られていることが多くあります。
発注と在庫管理には適していますが、広告の配分には使えません。

配分に必要なのは、粗利率と購入周期です。
この2つが近い商品を束ねると、同じ獲得単価の上限が適用できます。

束ねる単位は、細かすぎると運用が続きません。
全体で10から20程度の群にまとめるのが目安です。

束ねた群には、粗利率と購入周期と在庫の安定度を属性として持たせます。
この3つがあれば、投下の判断に使えます。

新商品が追加されたときの割り当ても、運用として決めてください。
決めていないと、群に入らない商品が増えていきます。

割り当ての判断は、商品部とマーケティングで行います。
どちらか一方に任せると、片方の都合で群が増えます。

広告の管理構造との対応

商品群を作っても、広告の管理構造と対応していなければ集計できません。
キャンペーンや広告グループの単位を、商品群に合わせる必要があります。

対応させる作業は、一度行えば以降は維持だけで済みます。
ただし新商品や新しい配信を追加するたびに、割り当てが必要になります。

割り当ての漏れを防ぐには、月次で未分類の投下額を確認します。
未分類が増えていれば、運用が崩れている合図です。

行動のデータは、どこまで取るべきか

行動データの収集は、範囲を広げるほど費用と手間が増えます。
使わないデータを集めても、保管と管理の負担だけが残ります。

判断に使う範囲は、実際には限られています。
購入までの段階別の通過と、再訪問の有無が中心です。

段階別の通過は、カートから決済までの離脱を特定するために使います。
これがないと、改善の優先順位が決められません。

再訪問の有無は、検討期間の長さを知るために使います。
初回訪問で買う商品と、複数回の訪問を経て買う商品では設計が変わります。

閲覧した商品の履歴は、提案の精度を上げるために使えます。
ただし提案の仕組みがない段階で集めても、活用されません。

収集の範囲は、使う施策が決まってから広げてください。
先に集めると、どのデータが必要かを判断する材料がありません。

行動データの収集範囲と使いどころ

同意の取り方との関係

行動データの収集には、利用者の同意が関わります。
GA4では、2026年6月15日より広告データ共有の可否は同意モードのad_storageのみで決まる形になりました。

Googleシグナルは、レポート上のディメンション表示の可否のみを制御します。
同意モードを実装していない場合、ad_storageはgrantedが既定として扱われます。

同意の扱いは制度側の運用が変わる領域です。
掲載時点の最新の公式ガイドラインで確認してください。

基盤を作るときの順序は、どうなるのか

基盤の整備は、一度にすべてを作ろうとすると止まります。
順序を決めて、段階ごとに使える状態にするほうが進みます。

最初が顧客の一意化です。
これがないと、どのデータを集めても人に紐づきません。

次が商品の束ね直しです。
一意化された顧客と、束ねた商品群があれば、入口カテゴリ別の集計ができます。

3番目が行動の記録です。
顧客と商品が揃った後なら、行動データも判断に使える形で入ります。

この順序を逆にすると、行動データが個々の訪問としてしか残りません。
人にも商品群にも紐づかないデータは、後から結合できないことがあります。

各段階の完了は、使える集計が1つ出ることで判定します。
仕組みが動いたことではなく、判断に使える数字が出たかどうかで見ます。

外部の道具を入れる時期

顧客データの道具を先に導入すると、何を入れるかの議論から始まります。
議論が長引くのは、目的が決まっていないからです。

道具の導入は、一意化と束ね直しの方針が決まってからにしてください。
方針が決まっていれば、必要な機能も絞れます。

小さく始める場合、最初の段階は既存の集計環境でも足ります。
道具を入れる判断は、手作業の負担が実際に問題になってからで構いません。

作った基盤を、どの施策で使うのか

基盤が完成しても、使う施策が決まっていなければ使われません。
使われない基盤は、更新も止まります。

ECで最初に使うのは、入口カテゴリ別の許容獲得単価です。
LTVの計算に顧客の一意化と商品群が必要になります。

2番目が、再購入の施策の投入時期です。
2回目までの日数の中央値が、入口カテゴリごとに出せるようになります。

3番目が、離脱の予兆の把握です。
顧客ごとの購入周期が分かれば、間隔が延びた時点で対応できます。

4番目が、滞留在庫の処理対象の選定です。
その商品を過去に買った顧客が分かれば、配信の対象が絞れます。

これらの施策を、基盤の整備と同時に設計してください。
完成してから考えると、必要なデータが足りないことが分かります。

基盤ができたら最初に使う施策

使われているかの確認方法

基盤が使われているかは、施策の数ではなく判断の数で確認します。
その月に、基盤の数字を根拠に変更した配分がいくつあったかを数えます。

数がゼロの月が続く場合、基盤は使われていません。
原因は、出力が判断の形になっていないことが多くあります。

数字の一覧ではなく、上限や時期という判断の形で出してください。
形が変わるだけで、使われる頻度が変わります。

外部に基盤の構築を任せるとき、何を決めておくのか

基盤の構築を外部に委託する場合、技術的な実装は外部で進められます。
一方で、何を1人の顧客とするかは事業の判断です。

一意化のルールを外部に任せると、一般的な方法が採用されます。
一般的な方法が、自社の販売形態に合うとは限りません。

商品群の定義も同じです。
仕入れの分類をそのまま使う実装になり、配分の判断には使えません。

この2つを決めてから委託すれば、実装の範囲は明確になります。
決めずに始めると、要件の確認に時間がかかり、費用も膨らみます。

あわせて決めるのが、データの保有と移管の条件です。
委託先を変える場合に、蓄積したデータをどう引き継ぐかを契約に入れます。

Testifyが2026年5月14日から18日に実施した調査では、全面委託している企業の8割超が1年以内のインハウス化を計画または検討していました。
移行を想定するなら、データの所在は最初から確認しておく必要があります。

実装の範囲を段階で切る

一度にすべてを実装すると、検収の基準が曖昧になります。
段階ごとに切って、使える集計が出ることを検収の条件にしてください。

第1段階は顧客の一意化で、入口カテゴリ別の顧客数が出れば完了です。
第2段階は商品群で、群ごとの粗利累計が出れば完了です。

段階ごとに区切ると、途中で方針を変えることもできます。
一括で契約すると、途中の変更が追加費用になります。

ECの顧客データ基盤は、何から着手すればいいのか

最初にやるのは、現状の確認です。
過去1年の注文のうち、特定の顧客に紐づいている割合を出します。

割合が高ければ、識別の設計に大きな問題はありません。
低ければ、ゲスト購入やメールアドレスの変更が原因として考えられます。

次に、識別の優先順位と同一世帯の扱いを決めます。
決めたルールを文書に残し、過去の注文も同じルールで引き直します。

その後、商品群を粗利率と購入周期で作ります。
広告の管理構造も、同じ群に対応させます。

最後に、行動の記録を開始します。
段階別の通過と再訪問の有無から始め、範囲は施策が決まってから広げます。

ECの顧客データ基盤に着手する順番

数字は説明のための仮の値です。
過去1年の注文が12万件で、顧客に紐づいているのが8万件であれば、一意化されているのは約67%になります。

この状態でLTVを出すと、顧客数が多く数えられ、実態より低い数字が出ます。
引き直しを行うだけで、上限の計算が変わります。

着手から記録の開始までは、全体で12週間前後が目安です。
各段階で使える集計が1つ出ることを、完了の条件にしてください。

途中で止まらないための設計

基盤の整備は、途中で止まることが多い取り組みです。
止まる理由は、完成するまで何も使えない設計にあります。

段階ごとに使える集計を出す設計にすれば、途中でも価値が出ます。
価値が出れば、次の段階の予算も通ります。

各段階の完了時に、その集計を使った判断を1つ実行してください。
実行の記録が、次の段階を進める根拠になります。

ECサイトの顧客データの整備範囲に迷う場合は、無料相談で現状を見てもらうところから始められます。
商品群と獲得の設計ごと見直す段階ならWeb集客改善サービスもあります。

よくある質問

まとめ