定期購読の難しいところ
システム開発部部長の内原です。
今回はバックエンドエンジニア観点で、定期購読（サブスクリプション）を扱う際に問題となるであろう様々なことについてお話しします。
私は現在システム開発部という部署を担当していますが、以前はDELISH KITCHENのプレミアムサービスチームでバックエンドエンジニアとして働いていたので、その経験を元にして実装や運用で難しさを感じたことについて語ります。
はじめに
DELISH KITCHEN においてもプレミアムサービスという定期購読サービスを提供しています。 内容は以下のようなものです。
DELISH KITCHEN プレミアムサービスとは
機能面
- お気に入り数無制限
- 人気順検索
- プレミアムレシピ（ダイエット、ヘルスケア、美容・健康、作りおき）
- おまかせ献立（1週間ぶんまるごとで献立を提供）
- プレミアム検索（糖質オフ、塩分控えめ、などの検索条件を利用可能）
価格面
- 月480円、半年2,400円、年4,500円
- 初回登録時は1ヶ月無料（キャンペーン時期により2ヶ月無料、3ヶ月無料）
決済システムについて一般的なお話
DELISH KITCHENに限らず、自社アプリに決済機能を設ける場合は、なんらかの外部サービスが提供する決済システムを利用するケースが殆どではないでしょうか。
自前の決済システムを構築するとなると、技術的難易度が上がることもさることながら、それ以上にセキュリティや法律の観点での考慮が重要になりますので、決済システムそのものがコア技術となるようなサービスを開発するのでない限り、費用対効果を考慮して外部が提供している決済システムを利用することが多いと予想します。
DELISH KITCHENでは、決済システムとして以下を利用しています。 そもそも、iOS/Androidについてはアプリ内でデジタルコンテンツを販売する場合はIAP/IABを利用する必要があるため、事実上の標準となっています。
- iOS
- Apple In App Purchase (IAP)
- Android
- Google Play Billing Library (In App Billing / IAB)
- 携帯キャリア (DoCoMo/au/Softbank)決済。DELISH KITCHEN WEBで利用
- 外部決済システム
※クレジットカードや銀行口座、コンビニ払いといった支払い方法には現状対応しておりません
そもそも決済システムは難しい
そもそも、定期購読に限らず消費型（買い切り型）の商品を扱う場合でも、決済システムの構築にはいくつか考慮しなければならない問題があります。
決済プラットフォーム別の調査＆実装が必要である
決済プラットフォーム間でいろいろと仕様が異なる部分が存在します。プラットフォーム間での相違から、必要となるデータが得られないというケースもあり、そうすると差分を埋めるために独自に実装が必要になることも多いです。例えば、IAPでは講読更新ごとに講読更新日時が取得できるが、IABだと初回の講読日時しか取得できないといったケースです。
決済処理は処理のフローが不安定なケースがある
ユーザ側の操作として、（初回は決済方法の指定が必要、など）いったん別画面に遷移したりすることが多いので、途中でユーザが脱落したり、通信エラーが発生したりする頻度も自然と高くなります。さらに、決済部分はアプリ外の挙動であり、課金ボタンはタップしたがその後脱落というケースが多くても、その原因は分からないということが多いです。プラットフォーム側で決済は完了したが、正しく通達できていないというケースのことです。
決済状態と内部システムの同期が必要である
上記問題に対応するため、購入情報の同期を行う機能が必要になります（アプリ内では購入情報の復元と表現されます）。
不具合対応やお客様対応の難易度が高くなりやすい
そもそも不具合が発生すること自体が問題ではあるのですが、金銭的損害が絡まない場合に比べて問題が複雑化＆深刻化する傾向が高いです。また、お客様のお問い合わせ対応において返金作業が別途必要になるなど、他の問題と比較してお問い合わせクローズまでの時間が長くなりやすいです。
購読の状態が複雑
定期購読は、未購読、購読中、定期購読中止（未解約）、解約済、といった状態が時系列で存在しているため、いったん確定した購読状態が時間経過によって変化することになります。 よってこれらの状態変化を正しく認識する必要があります。
以下に購読ライフサイクルの例を挙げます。 特にユーザが操作をしていなくても、時間経過によって購読状態が変化する場合があるのが分かります。
購読、解約
| - | 登録直後 | 0.5ヶ月後 | 1ヶ月後 | 1.5ヶ月後 | 2ヶ月後 | 現在 |
|---|---|---|---|---|---|---|
| 購読中 | 無料期間 | - | 更新1回目 | - | 更新2回目 | 購読中 |
| 購読後解約A | 無料期間 | - | 更新1回目 | 定期購読中止 | 解約 | 解約済 |
| 購読後解約B | 無料期間 | 定期購読中止 | 解約 | - | - | 解約済 |
解約後、再購読
※過去に購読→解約を経験しているため、無料期間が存在しない
| 登録直後 | 1ヶ月後 | 1.5ヶ月後 | 2ヶ月後 | 6ヶ月後 | 現在 |
|---|---|---|---|---|---|
| 無料期間 | 更新1回目 | 定期購読中止 | 解約済 | 更新通算2回目 | 購読中 |
購読後、商品切替(1ヶ月→半年)
※購読している商品の購読期間を変更することが可能
| 登録直後 | 1ヶ月後 | 1.5ヶ月後 | 7ヶ月後 | 現在 |
|---|---|---|---|---|
| 無料期間(1ヶ月) | 更新1回目(1ヶ月) | 購読切替(半年) | 更新2回目(半年) | 購読中 |
分析要件の難しさ
「どのような理由で購読/解約したのか？」、「どのような施策が売上に効いている/効いていないのか？」、「キャンペーン内容は適切であるか否か？」といった様々な観点での分析が必要となります。
前述の通り、購読状態は時間とともに複雑に変化するため、時系列での評価を行わなければならなくなります。
なにを見たいか
- 課金ページ閲覧数、課金数
- 新規購読UU
- 全体購読UU
- 課金転換率
- 無料期間によって対象期間は変わる
- 解約率
- 購読開始してから何日めか、が重要
なんの軸で集計するか
- 購読期間別
- 1ヶ月、6ヶ月、1年
- 無料期間別
- 1ヶ月、2ヶ月、3ヶ月、6ヶ月
- 登録日別
- キャンペーンやプロモーションの影響を分析する
- 訴求内容別
- 献立、ダイエット、ヘルスケア、など
- 上記の組み合わせ
過去の状態を判定
分析観点において、特定ユーザのN日前の購読状態を知りたいというニーズがあったとしても、状態遷移としては購読開始、購読更新×N、定期購読中止（未解約）、解約済、という起点があるだけです。単にN日前のデータを見ただけでは判別ができないということになります。 よって、時系列で購読状態を解釈する必要性があります。
プラットフォーム差異
前述したように、プラットフォームごとに提供される機能やデータ種類に差分がありますが、DELISH KITCHENシステムとしてはなるべくプラットフォーム差異を意識しないで済むようにしたいので、これらの差分を吸収する実装を行う必要が出てきます。 とは言え、そもそもの仕様が異なる関係で、完全に吸収することは難しいものも存在します。
例えば以下のように、IAP/IABでは仕様が異なる部分があり、いずれかに合わせる、または代替となるデータを自前で算出する機構を実装するなどの対応が必要になります。
| - | 価格 | 無料期間 | 購読履歴 | 定期購読中止日 | 購読商品切替時 |
|---|---|---|---|---|---|
| IAP | 価格帯から選択 | 期間帯から選択 | 取得可能 | 取得不可 | 現購読完了後に切替 |
| IAB | 1円単位で指定 | 1日単位で指定 | 取得不可 | 取得化 | 即時切替 |
本番での課金テストの辛さ
検証環境でのテストを十分に行っていたとしても、本番環境での検証を一切しないままだと不安が残ります。 よって、検証環境ほどの作業項目ではないにしても、最低限の動作確認は本番環境でも行っておきたいところです。 ただそれについても困難が伴います。
初回無料に関するテスト
初回無料が有効になるのは、ストアアカウントごとに1回ずつというのがIAP/IABにおける仕様です。 つまり、初回Nカ月無料が本当に正しくシステムで捕捉できているかといったようなテストを行う際は、都度ストアのアカウントを作り直さないといけないということになります。
解約済に関するテスト
いったん購読開始した後、定期購読を中止して解約済になった状態でテストする必要が出てきたとします。
しかし、実際に提供している商品の購読期間は1カ月や6カ月といった単位なので、定期購読中止してもその期間内はまだ購読済みのままです。 解約済み状態にするには最低でも1カ月前には準備しておかなければならないということを意味します。
終わりに
定期購読（サブスクリプション）に関する実装、運用の観点からの難しさについて記述しました。 今後の参考になりましたら幸いです。
