はじめに
定期購入型のECを運営していると、必ずと言っていいほど「解約率がいくらなのか、正確に答えられない」という壁にぶつかります。売上が落ちてから気づくのではなく、日々の解約状況を数字で追いたい。そう考えて担当者に「GA4で見られないのか」と聞くと、「コホートのレポートならあります」という答えが返ってくることがあります。
ところが、そのレポートを開いても、知りたかった解約率にはたどり着けません。出てくるのは「初回訪問から何週間後にどれだけのユーザーが戻ってきたか」という表で、誰がいつ定期購入をやめたのかは書かれていないからです。ここで多くの経営者が「うちの担当者の使い方が悪いのでは」と考えてしまうのですが、これは使い方の問題ではありません。GA4というツールの守備範囲の外にある情報を、GA4に求めてしまっているだけです。
この記事では、GA4のコホートレポートが実際には何を計測しているのか、なぜそれが「解約」とイコールにならないのか、そして解約率を本当に把握したいときに何が必要になるのかを整理します。
GA4の「コホート」レポートが見ているのは再訪問であって解約ではない
GA4には「ライフサイクル > 保持」の中に、コホート形式でユーザーの動きを見られるレポートがあります。名前だけ見ると「これで顧客の継続・離脱が分かりそうだ」と期待してしまいますが、GA4公式ヘルプの説明を確認すると、このレポートが計測しているのは「あるタイミングに初回訪問（または初回イベント）をしたユーザーが、その後の各期間にどれだけサイトやアプリに戻ってきたか」という再訪問の割合です（コホートについてのGoogleヘルプ）。
さらにコホートデータ探索の仕様を見ると、「登録条件」と「リピート条件」という2つの条件を自分でイベントとして指定する形式になっており、GA4があらかじめ「購入」や「解約」という概念を持って集計しているわけではないことが分かります（コホートデータ探索の仕様）。つまりコホートレポートは、あくまで「指定したイベントが、指定した期間内にどれだけ繰り返されたか」を数えるための汎用的な枠組みであって、契約状態や解約という業務上の概念を判定する機能ではありません。
これは重要な違いです。「再訪問しなくなった」ことと「定期購入を解約した」ことは、似ているようで別の事実です。定期購入は自動更新される仕組みが多く、サイトに一度も来なくても契約は継続していることがあります。逆に、頻繁にサイトを訪れているのに、次回の配送だけキャンセルし続けている顧客もいます。GA4のコホートレポートでは、この2つを区別できません。
「解約」はGA4に最初から存在する概念ではない
もう一段掘り下げると、そもそもGA4には、契約の解除・キャンセルという業務上の状態を判定する標準機能がありません。GA4が扱っているのは、ページビューやクリック、購入といった「行動イベント」であり、それらを組み合わせて算出する予測指標にしても、行動が途絶えそうかどうかを推測するものであって、「いつ・誰が定期購入を解除したか」という契約上の事実を記録するものではありません。解約という業務上の出来事をGA4上に表示させたいなら、事業者側で「解約手続き完了」「定期便停止」といったカスタムイベントを自分で定義し、該当する画面や処理が実行されたタイミングでGA4に送信する必要があります。
言い換えると、GA4を導入しただけでは解約率は出てきません。解約という概念を「教える」作業を、事業者側でやって初めて、GA4の集計対象に入ってくるということです。ここが抜けていると、担当者がどれだけGA4の画面を探しても、解約率にたどり着けないのは当然の結果になります。
したがって「GA4を見ているのに解約率が分からない」という状況に遭遇したとき、原因を担当者のスキル不足や運用の怠慢に求めるのは的外れです。多くの場合、単純にその定義がまだ存在していないだけです。
経営として何が変わるのか
ここまでの話を経営判断に落とすと、選択肢は大きく2つに分かれます。
一つは、GA4側に解約に関するカスタムイベントを追加で定義し、送信する設計を作ることです。「定期便を停止した」「解約手続きを完了した」といったタイミングでイベントを発生させれば、GA4の中である程度の傾向は追えるようになります。ただしGA4はあくまで行動ログの分析ツールであり、契約や請求といった正確な状態管理を目的に作られたものではないため、これで完全な解約率が出せるとは限りません。
もう一つは、購買・契約データを別のデータ基盤（BigQueryなど）に集約し、そちらで解約日を確定させる方法です。契約の開始日・終了日・解約理由といった情報は、決済や定期便管理のシステム側にすでに存在していることが多く、GA4を経由させるよりもそちらを正とするほうが実態に近い数字になります。GA4の行動ログをさらに補助情報として組み合わせれば、「なぜ辞めたか」の手がかりも得られます。実際にGA4の行動ログと購買データをBigQueryで結合し、解約の予兆をスコアリングするところまで踏み込みたい場合は、定期購入ECの解約予兆をGA4行動ログから検知するBigQueryモデルで具体的な手法を解説していますので、実装段階に進む際の参考にしてください。
どちらを選ぶにしても、まず考えるべきは「その解約率を、いくらまでかけて把握する価値があるか」という判断です。GA4にカスタムイベントを数個追加するだけであれば、既存の計測設計を見直す範囲の作業で収まります。一方で、複数システムのデータを日次で突き合わせて正確な解約日を確定させる基盤を作るとなると、対象システムの数や連携方式によって規模が大きく変わってきます。ここを決めずに「とりあえず解約率が見たい」と発注すると、見積もりの幅が広すぎて判断できません。まず自社が持っている契約・決済データがどこにあり、GA4とどう突き合わせられそうかを棚卸しすることが、費用の見積もりより先に必要な作業です。
やらなくてよい場合
一方で、すべての定期購入事業者が今すぐ解約率の基盤整備に着手すべきかというと、そうとは限りません。
まず、「解約率を知りたい理由」がはっきりしていない段階では、基盤を作る前にそこを言語化するほうが優先です。解約率を追う目的は大きく分けて、引き止め施策のトリガーにしたいのか、単に経営指標として月次で眺めたいのかで、必要な精度もスピードもまったく変わります。前者であれば「解約しそうな兆候をリアルタイムに近い形で捉える」設計が要りますが、後者であれば月次で契約データを集計するだけで十分なことも多く、GA4はほとんど関与しません。
また、解約件数がそもそも少なく、決済システムの管理画面を数分見れば全件を目視で把握できる規模であれば、データ基盤を組む労力のほうが大きくなります。この場合は、まず手元のシステムでどこまで把握できているかを確認し、それで足りているなら無理に投資する必要はありません。「解約率が分からない」という感覚が先行しているだけで、実は既存の管理画面に答えがある、というケースは珍しくありません。
自社の計測がそもそもどこまで正しく取れているか不安がある場合は、まず無料で使えるGA4無料ツールでイベント名の命名ルールなどを確認してみるのも一つの手です。その上で、解約という概念をGA4にどう組み込むべきか、あるいは別基盤に切り出すべきかを相談したい場合は、GA4の計測設計・実装のページから相談内容を整理できます。
まとめ
GA4のコホートレポートは、ユーザーの再訪問を追うための機能であり、解約や契約状態を判定する機能ではありません。解約という概念は、事業者が自らカスタムイベントとして定義しない限り、GA4上には現れないというのがこの記事の要点です。これは担当者の運用ミスではなく、ツールの設計上の守備範囲の話です。
まずは「なぜ解約率を知りたいのか」を明確にした上で、GA4側の計測を補うのか、購買データを別基盤に集約するのかを判断してください。自社だけでは判断が難しい場合は、お問い合わせから現状の計測状況を含めて相談していただければ、必要な範囲を一緒に整理します。