
定期の管理システムが、課金の処理のために作られているからです。
次回の請求日は分かっても、その人がいつ離れるかの手がかりは残りません。
なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。
現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。
今月の無料診断は残り4社です
広告からLPまで、まとめて見ます。オンラインで30分から対応しています。
目次
目次
- D2Cの顧客データが、解約の予測に使えないのはなぜか
- 何が足りないかを先に特定する
- 獲得の情報を、どう会員につなぐのか
- 記録の設定を入れる時期
- 解約の予兆は、どのデータから分かるのか
- 予兆への対応を自動にするか
- 定期の顧客で、行動のデータはどこまで取るべきか
- 同意の扱いとの関係
- 基盤を作る順序は、どうなるのか
- 外部の道具を入れる時期
- 作った基盤を、定期のどの施策で使うのか
- 使われているかの確認方法
- 定期の基盤の構築を外部に任せるとき、何を決めておくのか
- 実装の範囲を段階で切る
- D2Cの顧客データ基盤は、何から着手すればいいのか
- 途中で止まらないための設計
- よくある質問
- まとめ
定期の管理システムが、課金の処理のために作られているからです。
次回の請求日は分かっても、その人がいつ離れるかの手がかりは残りません。
D2Cの顧客データが、解約の予測に使えないのはなぜか
定期の管理システムが、課金の処理のために作られているからです。
次回の請求日は分かっても、その人がいつ離れるかの手がかりは残りません。
D2Cの定期の管理システムは、課金と出荷を正確に行うために作られています。
会員の状態、次回の請求日、配送先が記録されます。
この構造では、離脱の予兆が記録されません。
周期の変更、スキップ、問い合わせの履歴が別の場所にあるためです。
別の場所にあるデータは、同じ人のものとして結合されていません。
結合されていないと、予兆を組み合わせて見ることができません。
もう1つの問題が、獲得の情報です。
どの経路のどの訴求で入ったかが、会員の情報に残っていないことが多くあります。
残っていないと、集団ごとの継続の比較ができません。
比較ができなければ、獲得の質も判断できません。
必要なのは、獲得の情報と行動の履歴を、会員の情報につなぐことです。
つながった時点で、予兆の把握も集団の比較もできるようになります。
何が足りないかを先に特定する
基盤の整備を検討するとき、最初に決めるのは使う目的です。
目的が決まらないうちに範囲を広げると、作るだけで数年かかります。
D2Cで最初に必要なのは2つです。
獲得の情報を会員につなぐことと、周期の変更やスキップの履歴を残すことです。
この2つができれば、集団ごとの比較と予兆の把握ができます。
細かい閲覧の記録は、その後の段階で構いません。
定期の管理システムは課金の処理のために作られています。獲得の情報と行動の履歴を会員につなぐところから着手してください。
獲得の情報を、どう会員につなぐのか
初回の購入の時点で、経路とオファーを会員の属性として記録します。
後から遡って付けることは、ほとんどの場合できません。
獲得の情報は、購入の時点でしか取れません。
後から遡って、どの広告から来たかを特定することはできません。
そのため、記録の設定を先に入れる必要があります。
設定が入るまでの期間の獲得は、経路が不明のまま残ります。
記録する項目は3つです。
流入の経路、訴求の内容、適用したオファーです。
このうちオファーは、注文の情報から特定できることもあります。
初回の価格や特典の内容が記録されていれば、分類は可能です。
流入の経路は、購入の直前の参照元だけでは足りません。
複数回の訪問を経て購入する場合、最初の接点が記録されないからです。
厳密な把握は難しいため、最後の接点で1つに寄せる方法で足ります。
重要なのは精度ではなく、同じ方法で継続して記録することです。
会員につなぐ獲得の情報
| 項目 | 取得の時点 | 使う場面 | 取れない場合の代替 |
|---|---|---|---|
| 流入の経路 | 初回購入時 | 集団ごとの比較 | 注文の参照元 |
| 訴求の内容 | 初回購入時 | 訴求の検証 | 着地ページの種類 |
| 適用したオファー | 初回購入時 | オファーの評価 | 注文の価格から分類 |
| 定期への移行の時点 | 移行時 | 引き上げの評価 | 会員の状態の履歴 |
| 初回の商品 | 初回購入時 | 入口の評価 | 注文の明細 |
記録の設定を入れる時期
記録の設定は、早いほど価値が出ます。
蓄積に時間がかかるため、判断に使えるのは数か月後です。
基盤の整備の計画を待たずに、設定だけを先に入れてください。
設定そのものは、短い期間で終わります。
入れた後は、月次で未記録の割合を確認します。
未記録が増えていれば、設定が崩れています。
獲得の情報は購入の時点でしか取れません。基盤の計画を待たずに、記録の設定を先に入れてください。
解約の予兆は、どのデータから分かるのか
周期の変更、スキップ、問い合わせの3つが主な予兆になります。
いずれも解約の申し出より前に起きます。
解約は、突然起きるわけではありません。
その前に、いくつかの行動が現れます。
1つ目が、周期を延ばす変更です。
余っている状態を示しており、次に止める判断が来る可能性があります。
2つ目が、配送のスキップです。
1回止めた人は、そのまま解約に進むことがあります。
3つ目が、問い合わせです。
使い方や解約の方法に関する問い合わせは、直前の行動になります。
この3つを記録し、会員の情報に結びつけます。
結びつけば、予兆が出た時点で対応ができます。
対応の内容は、状況によって変えます。
周期の変更なら量の提案、問い合わせなら内容への回答が先になります。
予兆への対応を自動にするか
予兆が出た全員に同じ配信を送ると、逆効果になることがあります。
まだ止めるつもりのない人に、解約を想起させるからです。
送る内容は、解約の話題を避けてください。
使い方の提案や、周期の変更の案内にとどめます。
効果は、予兆が出た人のその後の継続率で測ります。
対応した群としない群を比べると、効果が判定できます。
予兆は周期の変更とスキップと問い合わせに現れます。対応の内容から、解約の話題は外してください。
定期の顧客で、行動のデータはどこまで取るべきか
定期の状態の変化と、問い合わせの内容までで足ります。
サイト内の閲覧の記録は、D2Cでは使う場面が限られます。
行動データの収集は、範囲を広げるほど費用と手間が増えます。
使わないデータを集めても、管理の負担だけが残ります。
D2Cで判断に使うのは、定期の状態の変化です。
周期の変更、スキップ、金額の変更、解約の申し出が含まれます。
もう1つが、問い合わせの内容です。
購入前に足りなかった情報や、使い方のつまずきが分かります。
サイト内の閲覧の記録は、商品数が少ないと情報量が限られます。
商品ページを見た回数からは、判断の材料が多く出ません。
ただし初回購入の前の行動は、獲得の検証に使えます。
どの情報を見てから購入したかは、訴求の設計に反映できます。
収集の範囲は、使う施策が決まってから広げてください。
先に集めると、どのデータが必要かを判断する材料がありません。
定期の顧客で行動データを取る範囲
| データ | 使う場面 | 優先度 | 取得の負担 |
|---|---|---|---|
| 定期の状態の変化 | 解約の予兆 | 高い | 低い |
| 問い合わせの内容 | 獲得と継続の改善 | 高い | 中 |
| 初回購入前の閲覧 | 訴求の検証 | 中 | 中 |
| 配信の開封と反応 | 接点の時期の検証 | 中 | 低い |
| サイト内の回遊 | 商品数が多い場合 | 低い | 中 |
同意の扱いとの関係
行動データの収集には、利用者の同意が関わります。
GA4では、2026年6月15日より広告データ共有の可否は同意モードのad_storageのみで決まる形になりました。
Googleシグナルは、レポート上のディメンションの表示可否のみを制御します。
同意モードを実装していない場合、ad_storageはgrantedが既定として扱われます。
同意の扱いは制度側の運用が変わる領域です。
掲載時点の最新の公式ガイドラインで確認してください。
行動データは定期の状態の変化と問い合わせの内容までで足ります。範囲は使う施策が決まってから広げてください。
基盤を作る順序は、どうなるのか
獲得の情報の記録、定期の状態の履歴、問い合わせの結合の順です。
順序を変えると、集めたデータが人につながりません。
基盤の整備は、一度にすべてを作ろうとすると止まります。
順序を決めて、段階ごとに使える状態にするほうが進みます。
最初が、獲得の情報の記録です。
これがないと、集団ごとの比較ができません。
次が、定期の状態の履歴です。
周期の変更やスキップが、時系列で残る形にします。
3番目が、問い合わせの結合です。
顧客対応の記録を、会員の情報に紐づけます。
この順序で進めると、各段階で使える集計が出ます。
1段階目で集団ごとの継続の比較、2段階目で予兆の把握ができます。
段階の完了は、仕組みが動いたことではなく、集計が出たことで判定します。
出ていない場合は、次に進まないでください。
外部の道具を入れる時期
顧客データの道具を先に導入すると、何を入れるかの議論から始まります。
議論が長引くのは、目的が決まっていないからです。
道具の導入は、記録する項目が決まってからにしてください。
決まっていれば、必要な機能も絞れます。
最初の段階は、既存の集計環境でも足りることがあります。
道具を入れる判断は、手作業の負担が実際に問題になってからで構いません。
整備の順序は獲得の情報、定期の状態の履歴、問い合わせの結合です。各段階は集計が出たことで完了を判定してください。
作った基盤を、定期のどの施策で使うのか
集団ごとの許容獲得単価と、予兆への対応に使います。
使う施策を先に決めておかないと、作っても運用されません。
基盤が完成しても、使う施策が決まっていなければ使われません。
使われない基盤は、更新も止まります。
D2Cで最初に使うのは、集団ごとの許容獲得単価です。
経路とオファーごとの累計粗利から、上限を出します。
2番目が、引き上げの案内の時期です。
初回から定期への移行までの日数の分布から、時期を決めます。
3番目が、予兆への対応です。
周期の変更やスキップが出た時点で、提案を送ります。
4番目が、解約の理由と獲得の訴求の照合です。
特定の訴求で入った集団に、特定の理由が多くないかを見ます。
これらの施策を、基盤の整備と同時に設計してください。
完成してから考えると、必要なデータが足りないことが分かります。
定期の基盤ができたら最初に使う施策
| 施策 | 必要なデータ | 見る数字 | 着手の時期 |
|---|---|---|---|
| 集団ごとの上限の設定 | 獲得の情報と購買履歴 | 経過月ごとの累計粗利 | 記録の開始から3か月後 |
| 引き上げの案内の時期 | 移行までの日数 | 引き上げ率 | 記録の開始から3か月後 |
| 予兆への対応 | 定期の状態の履歴 | 予兆後の継続率 | 履歴の整備後 |
| 訴求と解約理由の照合 | 獲得の情報と解約の理由 | 理由の構成比 | 両方の結合後 |
| 復帰の対象の絞り込み | 解約の理由と経過日数 | 復帰率 | 解約の記録の蓄積後 |
使われているかの確認方法
基盤が使われているかは、施策の数ではなく判断の数で確認します。
その月に、基盤の数字を根拠に変えた設定がいくつあったかを数えます。
数がゼロの月が続く場合、基盤は使われていません。
原因は、出力が判断の形になっていないことが多くあります。
数字の一覧ではなく、上限や時期という判断の形で出してください。
形が変わるだけで、使われる頻度が変わります。
使う施策を整備と同時に設計してください。基盤が使われているかは、数字を根拠に変えた設定の数で確認します。
定期の基盤の構築を外部に任せるとき、何を決めておくのか
記録する項目と、集団の分け方を社内で決めてから渡します。
この2つを外部に決めさせると、事業の判断と合わない分類になります。
基盤の構築を外部に委託する場合、技術的な実装は外部で進められます。
一方で、何を記録し、どう分けるかは事業の判断です。
記録する項目を外部に任せると、一般的な設計が採用されます。
D2Cで必要な獲得の情報や、定期の状態の履歴が抜けることがあります。
集団の分け方も同じです。
月ごとに分けるだけでは、経路とオファーの比較ができません。
この2つを決めてから委託すれば、実装の範囲は明確になります。
決めずに始めると、要件の確認に時間がかかり、費用も膨らみます。
あわせて決めるのが、データの保有と移管の条件です。
委託先を変える場合に、蓄積したデータをどう引き継ぐかを契約に入れます。
Testifyが2026年5月14日から18日に実施した調査では、全面委託している企業の8割超が1年以内のインハウス化を計画または検討していました。
移行を想定するなら、データの所在は最初から確認しておく必要があります。
実装の範囲を段階で切る
一度にすべてを実装すると、検収の基準が曖昧になります。
段階ごとに切って、使える集計が出ることを検収の条件にしてください。
第1段階は獲得の情報の記録で、集団ごとの継続率が出れば完了です。
第2段階は定期の状態の履歴で、予兆の一覧が出れば完了です。
段階ごとに区切ると、途中で方針を変えることもできます。
一括で契約すると、途中の変更が追加費用になります。
記録する項目と集団の分け方は社内で決めてから渡します。実装は段階で切り、集計が出ることを検収の条件にしてください。
D2Cの顧客データ基盤は、何から着手すればいいのか
獲得の情報が会員に記録されているかを確認するところからです。
記録されていなければ、設定を先に入れます。
最初にやるのは、現状の確認です。
既存の会員のうち、獲得の経路とオファーが分かる割合を出します。
割合が低ければ、記録の設定を先に入れます。
設定が入るまでの期間の獲得は、経路が不明のまま残ります。
次に、定期の状態の変化が履歴として残っているかを確認します。
残っていなければ、その記録の設定も追加します。
その後、問い合わせの記録を会員に結合します。
外部に委託している場合は、結合できる形式での納品を求めます。
最後に、集団ごとの累計粗利と継続率を出す集計を作ります。
この集計が、上限の設定と施策の判断に使われます。
D2Cの顧客データ基盤に着手する順番
| 順番 | やること | 関わる部門 | 期間の目安 |
|---|---|---|---|
| 1 | 獲得の経路とオファーが分かる割合を確認する | マーケとシステム | 1週間 |
| 2 | 獲得の情報の記録の設定を入れる | システム | 3週間 |
| 3 | 定期の状態の変化を履歴として残す | システム | 3週間 |
| 4 | 問い合わせの記録を会員に結合する | 顧客対応とシステム | 3週間 |
| 5 | 集団ごとの累計粗利と継続率の集計を作る | マーケとシステム | 3週間 |
| 6 | 上限の設定と施策の判断に使う | マーケティング | 継続 |
数字は説明のための仮の値です。
既存の会員5万人のうち、獲得の経路が分かるのが2万人であれば、4割しか集団の比較に使えません。
残り3万人は不明の区分として集計します。
記録の設定を入れた後に獲得した会員から、比較が可能になります。
着手から集計の完成までは、全体で12週間前後が目安です。
判断に使える蓄積が出るのは、記録の開始から3か月後になります。
途中で止まらないための設計
基盤の整備は、途中で止まることが多い取り組みです。
止まる理由は、完成するまで何も使えない設計にあります。
段階ごとに使える集計を出す設計にすれば、途中でも価値が出ます。
価値が出れば、次の段階の予算も通ります。
各段階の完了時に、その集計を使った判断を1つ実行してください。
実行の記録が、次の段階を進める根拠になります。
着手点は獲得の情報が記録されているかの確認です。記録の設定は、基盤の計画を待たずに先に入れてください。
D2Cブランドの顧客データの整備範囲に迷う場合は、無料相談で現状を見てもらうところから始められます。
獲得と継続の集計ごと見直す段階ならWeb集客改善サービスもあります。
よくある質問
定期の管理システムのデータだけでは足りませんか
課金と出荷を正確に行うために作られているため、離脱の予兆が記録されません。周期の変更やスキップ、問い合わせの履歴が別の場所にあり、同じ人のものとして結合されていないことが多くあります。
獲得の経路は、後から調べられませんか
後から遡って特定することは、ほとんどの場合できません。購入の時点でしか取れないため、記録の設定を先に入れてください。設定そのものは短い期間で終わるため、基盤の整備の計画を待つ必要はありません。
解約の予兆は、どのデータから分かりますか
周期を延ばす変更、配送のスキップ、問い合わせの3つが主な予兆です。いずれも解約の申し出より前に起きます。ただし対応の内容から解約の話題は外してください。まだ止めるつもりのない人に想起させます。
行動データはどこまで集めるべきですか
定期の状態の変化と、問い合わせの内容までで足ります。商品数が少ないD2Cでは、サイト内の閲覧の記録から出る判断の材料は限られます。収集の範囲は、使う施策が決まってから広げてください。
基盤の構築を外部に任せる場合、何を先に決めますか
記録する項目と、集団の分け方です。どちらも事業の判断であり、外部に任せると一般的な設計が採用されます。あわせて、委託先を変える場合のデータの保有と移管の条件も契約に入れてください。
まとめ
- 定期の管理システムが、課金の処理のために作られているからです。次回の請求日は分かっても、その人がいつ離れるかの手がかりは残りません
- 初回の購入の時点で、経路とオファーを会員の属性として記録します。後から遡って付けることは、ほとんどの場合できません
- 周期の変更、スキップ、問い合わせの3つが主な予兆になります。いずれも解約の申し出より前に起きます
- 定期の状態の変化と、問い合わせの内容までで足ります。サイト内の閲覧の記録は、D2Cでは使う場面が限られます
- 獲得の情報の記録、定期の状態の履歴、問い合わせの結合の順です。順序を変えると、集めたデータが人につながりません
- 集団ごとの許容獲得単価と、予兆への対応に使います。使う施策を先に決めておかないと、作っても運用されません
- 記録する項目と、集団の分け方を社内で決めてから渡します。この2つを外部に決めさせると、事業の判断と合わない分類になります
- 獲得の情報が会員に記録されているかを確認するところからです。記録されていなければ、設定を先に入れます