はじめに
「定期購入の解約率は何パーセントですか」と聞かれたとき、1つの数字で答えている会社は多いと思います。契約が終わった人を、契約していた人で割る。計算としては自然です。
ただ、この数字には、性質の違う終わり方が混ざっている可能性があります。お客様が自分の意思で辞めた場合と、カードの決済が通らずに終わった場合です。前者は商品や価格、頻度への不満が疑われ、後者は決済まわりの問題が疑われます。打ち手がまったく違うのに、同じ数字に入っていると、効かない施策に手をかけることになりかねません。
この記事では、Shopifyの公式ドキュメントに書かれている契約ステータスの仕様をもとに、終わり方がどう分かれているか、分けないと何を誤るか、そして分けなくてよい会社はどこかを整理します。なお、ここで扱う仕様は英語の公式ページの記述を要約したものです。定期購入アプリによって見え方が違う可能性があるので、自社の管理画面で実際にどう見えるかを確認してください。この記事の内容は、公式ページの記述を読んで整理したもので、自社の環境での動作確認はしていません。
定期購入の「終わり方」は何種類あるか
Shopifyの開発者向けドキュメントでは、定期購入の契約ステータスは5つの値で定義されています（SubscriptionContractSubscriptionStatus）。ACTIVE（継続中）、PAUSED（一時停止）、CANCELLED、EXPIRED、FAILEDです。
このうち「終わった」状態にあたるのは、次の3つです。
- CANCELLED: 計画外の顧客操作による終了
- EXPIRED: 想定どおり、全サイクルを終えた終了
- FAILED: 請求が失敗し、以降の請求試行も予定されていない終了
つまりShopifyの定義上、「終わった」状態は3種類に分かれています。回数が決まったプランを最後まで使い切った人は、解約ではなくEXPIREDです。これを解約に数えると、解約率は実態より悪く見えます。逆に、決済失敗のFAILEDを数え漏らすと、静かに離脱している人が見えなくなります。
さらに、直近の請求失敗には種別が付いています。lastBillingAttemptErrorTypeという項目で、CUSTOMER_ERROR、INVENTORY_ERROR、PAYMENT_ERROR、OTHERの4値です（SubscriptionContractLastBillingErrorType）。名前から読み取れる範囲で言えば、お客様側の問題、在庫の問題、決済の問題、その他に分けて記録できる、ということです。ここまで見えると、「決済失敗」の中にも、カードの問題と、こちらの在庫切れが混ざっていないかを確かめられます。
混ぜると何を誤るか
一般論として、終わり方を混ぜた解約率には2つの危うさがあります。
1つ目は、打ち手が逆になることです。決済失敗で終わった人が多いのに、「解約が多い」と読んで、割引や商品改良、解約防止のクーポンに手をかける。お客様は辞めたかったわけではないので、そこに使った費用は届きません。この場合、先に見るべきは決済まわり（再請求のタイミングや、お客様への通知の仕方など）です。
2つ目は、良い状態を悪く見てしまうことです。全サイクルを終えたEXPIREDは、想定どおりの終了です。ここを解約と混ぜると、「うちの定期は続かない」と判断してしまい、商品設計の見直しに進むかもしれません。
どちらが多いかは、自社のデータを分けて数えるまで分かりません。この記事では、割合の例を挙げません。業種や商品、決済手段で大きく変わるはずで、他社の数字は自社の判断に使えないからです。見るべきは、自社の終了した契約が、3つの終わり方にどう分かれているかという内訳です。
GA4のデータだけで解約を追うのが難しい理由は、別の記事で書いています（GA4では定期購入の解約が見えない話）。契約の状態は、ショップ側のデータに持たせないと見えません。
Shopify標準で見えるものと、見えないもの
ここからは、公式ドキュメントとヘルプから確認できた範囲です。確認できなかったことは、確認できなかったと書きます。
見えるもの（仕様上、取れる情報）は、先ほどの契約ステータスと、請求失敗の種別です。
見えないもの、または確認できなかったものは次のとおりです。
- 解約日: SubscriptionContractオブジェクトには、解約専用の日時の項目が見当たりませんでした。確認できた日時系の項目は、作成日時（createdAt）と更新日時（updatedAt）だけでした（SubscriptionContract）。updatedAtを解約日の代わりに使えるかどうかは、未検証です。契約の更新は解約以外でも起きうるので、安易に代用すると「いつ辞められているのか」がずれる可能性があります。
- 解約の理由: ヘルプには、解約理由を記録する機能の記載が見当たりませんでした。
- 契約一覧のエクスポート: これもヘルプに記載が見当たりませんでした。
- 取り消し: 契約のキャンセルは取り消せず、再購読には新しい契約が必要、とヘルプにあります（契約の管理）。つまり、いったん辞めて戻ってきた人は、新しい契約として数えられます。「解約した人の数」と「去ったままの人の数」は一致しません。
- レポート上の見え方: 定期購入のデータは、一部のレポートで「購入オプション」の列やフィルターを足したときだけ見える、とあります（定期購入の注意事項）。売上レポートでは、購入オプションの列かフィルターを足さないと、定期の動きが見えないことがあります。
特に「いつ辞められているか」を知りたいという問いには、解約日が確認できない点が効きます。契約の作成日からどれだけ続いたかを出すには、日付の持たせ方を自社で決める必要があります。たとえば、ステータスが変わった日を毎日記録して残しておく、という方法です。これは仕様から導いた考え方で、自社の定期購入アプリで可能かどうかは別に確認が要ります。
やらなくてよい場合
分けて数える作業は、全社に必要なものではありません。次のような場合は、手をかけるより先にやることがあります。
- 定期のお客様が少数で、契約の一覧を月に1度、目で見られる規模であれば、管理画面で個別に確認するほうが早く、費用もかかりません。1件ずつ「なぜ終わったか」を見られるなら、集計の仕組みを作る意味は薄いです。
- 決済失敗がほとんど起きていないと、すでに分かっている場合。自社の管理画面で失敗の件数を確認して、気にならない水準なら、分ける優先度は下がります。
- 解約を減らす施策をまだ打っていない段階。答えたい問いが「解約が増えたか減ったか」だけなら、まず従来の1つの数字で十分なことがあります。内訳が必要になるのは、「どの施策に費用をかけるか」を決める時点です。
逆に、定期の件数が増えてきて、目視では追えなくなったとき、そして解約防止に広告費や割引を使い始めるときが、分けて数える目安になります。
自社で進めるか、任せるか
自社で進める場合の最初の一歩は、仕組みを作る前の確認です。
- 使っている定期購入アプリの管理画面で、終了した契約を「自分で辞めた」「決済失敗」「期間満了」に区別できるか確かめる
- 解約日にあたる日付が取れるか、取れないなら何で代用できるかを確かめる
- 一覧を取り出す方法（画面のエクスポートか、データ連携か）があるかを確かめる
ここまでで足りない部分が見つかれば、契約の状態を毎日記録して、別の場所に溜める仕組みが要ります。費用は、定期購入アプリの仕様、連携の方法、契約の件数、必要な期間で変わるので、一律には言えません。見積もりの前に、上の3点の確認結果を手元に用意しておくと、話が早くなります。
実装の側から知りたい場合は、技術編としてGA4とBigQueryで解約の予兆を追う方法を書いています。
ここまでを自社でやるのが難しければ、データの置き場所の設計から手伝えます。まずは今のデータで何が分かって何が分からないかを一緒に確認するところからで構いません。データ基盤の相談はこちら、お問い合わせはこちらのフォームから受け付けています。