顧客維持率を改善するには、まず誰を、いつからいつまで「維持」と数えるかを固定します。その上で獲得時期や商品別のコホートを追い、初期設定、価値到達、サポート、契約・決済など離脱が起きる工程を改善します。全顧客を一つの平均で見ないことが重要です。
1. 顧客維持率とは
一定期間の開始時点にいた顧客のうち、終了時点にも継続している顧客の割合として扱うのが基本です。新規顧客を分子から除くか、休会や無料利用を含むかを明記します。
2. 計算式
仮定の例では、期間末の顧客数から期間中の新規顧客数を引き、期間初めの顧客数で割ります。これは仕組みを理解するための式で、事業により契約、購入、利用の定義は異なります。
3. 期間を揃える
月次、四半期、年次では結果が変わります。契約周期や購入周期に合う期間を選びます。異なる長さの期間を同じ表で直接比べません。
4. コホートで見る
Google Analytics公式はコホートを共通の特性でまとめた利用者群と説明しています。初回日、プラン、獲得経路などで分け、同じ経過日数の維持を比較します。
5. 顧客とユーザーを分ける
Webの再訪、アプリ利用、契約継続、再購入は別の指標です。ログインしなくても契約中の場合や、複数ユーザーを持つ法人顧客を考慮します。
6. 初期離脱
登録直後に価値へ到達できない原因を探します。設定、データ移行、権限、説明、初回配送などを確認します。利用開始までの必須操作を減らします。
7. オンボーディング
顧客の目的別に、最初に完了すべき行動を案内します。機能をすべて説明せず、価値に直結する最短経路を示します。支援が不要な顧客へ強制しません。
8. 継続価値
初回だけでなく、利用を続けることで得られる価値を確認します。商品品質、更新、コンテンツ、サポートが約束と合っているかを見ます。
9. 利用上の障害
ログイン、速度、在庫、決済、配送、予約、権限などを分けます。顧客の意欲不足と決めつけず、エラーと問い合わせ履歴を確認します。
10. サポート
初回回答時間だけでなく、解決、再発、引き継ぎを測ります。解約直前だけ優遇せず、通常利用中の問題を早く解消します。
11. 価格と契約
更新価格、請求日、条件変更、解約方法を分かりやすくします。解約を難しくして見かけの維持率を上げる方法は、信頼と規制対応の面で避けます。
12. 離脱理由
選択式と自由記述を使い、回答しない選択も認めます。回答者だけで全離脱者を代表すると判断しません。運用上の記録と合わせます。
13. 予兆
利用減少、エラー、未完了、支払い失敗などを確認します。予兆から個人の意図を断定せず、役立つ支援を選択可能な形で提示します。
14. セグメント
プラン、商品、利用目的、獲得経路、地域など、改善に使える区分で見ます。少数グループの個人が特定されないよう表示範囲を管理します。
15. 施策の優先順位
影響人数、問題の重大性、改善可能性で決めます。値引きより、利用不能、説明不足、請求誤りなど根本問題を先に直します。
16. 実験
対象と期間を決め、一度に一つの主要変更を試します。維持率だけでなく、利用、問い合わせ、苦情、売上への影響も見ます。
17. GA4で確認できること
Google Analytics公式のRetention overviewは、新規・再訪ユーザー、コホート別リテンション、エンゲージメント、LTVなどを案内しています。契約継続とは別なので、CRMや請求データと区別します。
18. データ品質
顧客ID、契約状態、開始・終了、統合、返金を確認します。追跡設定変更による見かけの変化を施策効果と誤認しません。
19. 組織の役割
商品、サポート、マーケティング、請求が同じ定義を使います。維持率目標が解約妨害や不要な連絡を生まないよう監査します。
20. 改善チェック
定義、期間、コホート、初期体験、価値、障害、サポート、契約、理由、実験を確認します。外部平均を根拠なく目標にしません。
異常値への対応
急な変化が出たら、施策より先に計測、データ欠損、商品・価格変更、障害を確認します。定義変更時は過去との比較が切れることを記録します。
まとめ
顧客維持率は、固定した定義と同じ経過期間のコホートで測ります。初期体験から契約・サポートまでの離脱原因を分け、顧客の自由を損なわない改善を続けてください。
計算例を正しく扱う
仕組みを理解する仮定として、期首顧客が100、期間中の新規が20、期末が90なら、期末から新規を除いた70を期首100で割ります。ただし、この数字は実在事業の水準ではありません。休会、再契約、無料顧客を含むかで結果は変わります。
顧客数が少ない場合、一件の増減で率が大きく動きます。割合だけでなく分子と分母を併記します。母数が異なるセグメントを、率だけで優劣判断しません。
契約型と購入型を分ける
契約型では更新状態、購入型では一定期間内の再購入を維持と定義する方法があります。購入周期が長い商品に短い判定期間を使うと、正常な顧客を離脱として数えてしまいます。商品特性ごとに観測窓を決めます。
Web再訪は契約維持の代替ではありません。ログインせずサービスを利用する顧客や、契約者と利用者が別の法人があります。分析ツールのユーザーと顧客台帳の顧客を無理に一致させません。
初期価値への到達を測る
登録、設定、初回利用、成果確認までの各段階を定義します。「オンボーディング完了」を動画視聴だけで数えず、顧客の目的に必要な行動が完了したかを見ます。利用方法が複数ある場合は一つの経路を強制しません。
途中離脱には、技術エラー、権限不足、データ不足、説明不足、社内承認など別の原因があります。イベントデータ、問い合わせ、担当者記録を合わせ、顧客の意欲を推測だけで判断しません。
請求と更新の運用
更新日、価格、支払方法、失敗時の扱いを事前に説明します。支払い失敗を自発的な解約と同じ原因へ入れず、技術的離脱として分けます。再試行は重複請求を防ぎ、顧客が支払方法を安全に更新できるようにします。
値上げ後の維持率を見る場合、通知時期、対象プラン、既存契約の扱いを記録します。価格だけでなく、同時期の機能、品質、サポート変更も確認します。
施策の副作用を測る
利用を促す通知で維持率が上がっても、配信停止や苦情が増える場合があります。値引きは短期継続を増やしても粗利を下げる可能性があります。主要指標と安全指標をセットで置きます。
顧客を維持した件数だけで担当者を評価すると、解約処理の遅延や強い引き止めが起きます。解約完了時間、苦情、規約順守も監査し、顧客の選択を守ります。
データ更新と再現性
指標のSQLや集計条件、タイムゾーン、締め時刻、除外条件を記録します。ダッシュボードの数字が更新のたびに過去分まで変わる場合、遅延データや顧客統合の影響を確認します。
定義変更は適用日を残し、旧定義と新定義を混ぜません。経営会議、商品チーム、マーケティングが同じ数字を参照できるよう、データの正本と更新責任者を決めます。
改善の終了判断
一時的な変化ではなく、複数コホートで同じ傾向が続くかを確認します。改善が見られない場合、施策対象、実装、観測期間、データ品質を見直します。都合のよい期間だけを選びません。
施策を全体へ広げる前に、サポート負担、システム容量、顧客への不利益が許容できるか確認します。終了・巻き戻しの条件も実験前に決めます。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。