Save Offerを1アカウント1度きりにした理由 — 退会引き留め施策の落とし穴

「退会しようとしたら50%オフのオファーが出てきた」という体験、したことあるか。自分はあれを**PiloTube(パイロチューブ)**に実装した。そして実装した翌日に「あ、これ穴がある」と気づいた。

Save Offerとは何か、なぜ入れたか

SaaS(月額課金型のWebサービス)の世界に「Save Offer」という施策がある。退会やダウングレードを選択したユーザーに対して、その直前に「今なら50%オフで継続できます」というオファーを出す仕組みだ。

数字で言うと、業界標準でこのオファーを受け入れるユーザーは**15〜30%**いる。退会しようとしていたユーザーの4〜6人に1人が「それなら続けよう」と思い直す計算になる。チャーン(解約率)対策として、これほどコスパの良い施策はそうない。

PiloTubeはYouTubeチャンネル運営者向けのSaaSで、自分が一人で開発・運営している。ユーザーが退会ボタンを押したとき、ただ「残念でした」で終わらせるのはもったいない。そう思って実装を進めた。

実装してすぐ気づいた「抜け穴」

コードを書いて、動作確認をして、「よし完成」と思った翌日。ふと考えていたら背筋が冷えた。

「これ、退会→再登録→退会→再登録を繰り返せば、ずっと50%オフで使い続けられるんじゃないか」

そうなのだ。Save Offerの仕組みを「退会操作のたびに発動する」設計にしてしまうと、抜け穴が生まれる。賢いユーザーなら気づく。気づいたら使う。それは責められない。自分でも使う。

月額1,000円のプランを50%オフで500円にして、それを毎月繰り返されたら、実質的に「500円プラン」を提供していることと変わらない。値引きが永続化する。

これは「引き留め施策」ではなく「実質値下げ」だ。

解決策はシンプルだった

詰まるほど複雑な問題ではなかった。答えは明快だった。

「1アカウントにつき、Save Offerは生涯1回だけ」

これだけ。

退会操作を行ったとき、そのアカウントがすでにSave Offerを使ったことがあるかどうかをチェックする。使ったことがあれば、オファーは出さずにそのまま退会処理へ進む。使ったことがなければ、50%オフのオファーを表示する。

データベース側では、Save Offerを受け入れた履歴をユーザーアカウントに紐づけて保存する。フラグ一つ追加するだけの話だ。実装のコスト自体は小さい。ただ「最初からそう設計しておく」という判断が重要だった。

実際の実装で意識したこと

技術的な詳細を少し書いておく。

PiloTubeはSupabaseをバックエンドに使っている。ユーザーテーブルにsave_offer_usedというboolean型のカラムを追加し、オファーを受け入れた時点でtrueに更新する。

退会フローの入り口で、このカラムを参照する。

if (save_offer_used === true) {
  // オファーなしで退会処理へ
} else {
  // Save Offerを表示
}

ロジックはこれだけだ。ただし「オファーを表示したが断られた場合」と「オファーを受け入れた場合」は別扱いにした。断られた場合はフラグを立てない。あくまで「オファーを受け入れて割引を使った」場合にのみフラグを立てる。

理由は、オファーを断って退会したユーザーが数ヶ月後に戻ってきたとき、また退会しようとしたらオファーが出ても良いと思ったから。一度も恩恵を受けていないユーザーにはチャンスを残す。恩恵を受けたユーザーには出さない。この線引きが自然だと判断した。

「1度きり」にすることで生まれる副次効果

これは想定外のメリットだったが、「1度きり」という制約はオファーの価値を高める。

ユーザー視点で考えると「このオファーは今しか使えない」という感覚が生まれる。希少性だ。「また退会すれば使えるんでしょ」という感覚がなくなる分、受け入れ率が上がる可能性すらある。

自分自身も、何かのサービスで「このオファーは今回限りです」と言われると、少し真剣に考える。「次もあるなら今回は断ろう」という先送りが起きにくくなる。

施策の健全性と、ユーザーへの訴求力が同時に上がる。一石二鳥だった。

教訓と、これを読んでいる人へのヒント

Save Offerは強力な施策だ。チャーン対策として間違いなく効く。ただ、設計を甘くすると「値引き永続化」という穴が生まれる。

自分が今回学んだことをまとめると、こうなる。

① 施策を設計するとき、「悪用したらどうなるか」を先に考える

ユーザーを疑うのではなく、システムの抜け穴を先につぶす。抜け穴があれば使う人は必ず出る。それは設計の問題であって、ユーザーの問題ではない。

② 「1度きり」という制約は、施策の価値を下げない

むしろ希少性を生む。「いつでも使える」より「今しか使えない」のほうが、人は真剣に向き合う。

③ 実装コストが小さくても、設計判断は早めに固める

フラグ一つの話だが、後から追加するとデータの整合性(過去ユーザーへの対応など)が面倒になる。最初から入れておくのが正解だった。

SaaSを一人で作っていると、こういう「小さいけど大事な設計判断」が山ほど出てくる。誰かに相談する前に自分で気づかなければいけないし、気づいたら即対応しなければいけない。

それが一人開発の現実だし、正直それが面白いとも思っている。

PiloTube 開発日誌

退会→再登録ループで永遠に50%オフ、気づいちゃった