課金ユーザを増やすためのInAppBilling定期購入の 活用事例

課金ユーザを増やすためのInAppBilling定期購入の活用事例を紹介します。

Transcript

1. 課金ユーザを増やすための InAppBilling定期購入の 活用事例 Cookpad.apk #3 @farmanlab
2. README ・山下 拓磨 twitter: @farmanlab ・2018年1月入社 会員事業部 　→有料会員を増やすことを主軸にした部署 ・元鉄道運転士＆ 　電気設備管理者
3. みなさんお金って知ってますか？ Do you know money?
4. お金は超絶便利 ・好きなものが買える ・好きなことができる ・好きなとこに住める 　　　＝人生が豊かになる！！
5. お金を稼げるサービスを作らなきゃいけない ・社員に素晴らしいおちんぎんを払うため ・キレイなオフィスに住まうため ・みんなに最強のパソコンを支給するため ・事業を継続させるため
6. クックパッドの主な収入源 有料コンテンツ 広告
7. 三行まとめ ・有料コンテンツの無料体験の 　バリエーションを増やした話 ・課金ユーザの退会者を 　猶予期間を使って減らした話 ・行あまり
8. 定期購入 （In-app-Billing）
9. In-app-Billing ・Googleが提供するアプリ内課金機能 　（ちなみにAppleはIn-app Purchase） 　 　大きく分けると 　　・使い切りアイテム（INAPP） 　　　→　　魔法石 　　 　　・定期購入アイテム（SUBS） 　　　→プレミアムサービス 　　　　Amazonプライム
10. In-app-Billing ・商品の管理、金額の設定などは 　基本的にGoogle Play Console上で行う ・一つの機能（アイテム）ごとにid(sku)を設定する
11. 導入は2018年3月 開発者ブログにIn-app-Billing導入時の記事があります https://techlife.cookpad.com/entry/2018/03/14/090000
12. 定期購入のいろいろな機能 ・無料試用期間（フリートライアル） 　・3日以上の無料期間が付けられる 　・あらゆるサービスで使われている 30日無料 90日無料
13. こうかは　ばつぐんだ！
14. ここで一つの願望と問題が 生まれます
15. 　　　　　　　　　願望 特定のユーザにだけ多くの無料期間を与える キャンペーンやりたい （誕生日、インストール直後 etc...）
16. 　　　　　　　　　問題 ・同じ商品に複数の無料期間を設定できない 　→商品別にする？ 　　→商品別だから同時購入できる 　　　→二重決済防止の仕組みが必要 　　　　→めっちゃ大変そう 　　　　　→もう少し良い方法はない？ （AppleはGroup内で一つしか有効にならないSubscription Groupというものがある）
17. 解決方法 課金の延期機能を使う (Defer)
18. Defer https://developer.android.google.cn/google/play/billing/billing_subscriptions?hl=JA#Defer Defer＝課金の延期 　→次回の課金のタイミングを遅らせる 　→特定ユーザに付与することが可能 　　ex:商品自体の無料期間30日＋defer30日 　→Google Play Developer APIを使って付与する ・そんなもんよりSubscription Group作ってくれ
19. Defer(pros) ・自前で二重課金防止策を取らずに 　ユーザごとに異なる無料期間を提供できる
20. Defer(cons) ・次の課金タイミングを遅らせるだけなので 　無料体験ユーザには延期分の日数が表示されない ・課金導線でユーザに認知させる工夫が必要
21. Defer適用までの流れ ログテーブル ①課金処理 ②決済情報登録 日時バッチ ④ログ取得 Cookpad 決済基盤 ③Defer適用ログ ⑤Defer適用リクエスト ⑥Defer API 決済情報 テーブル
22. Deferの注意点 ・Deferは次回の課金タイミングの先送り 　→無料期間なし＋defer30日の場合は 　　最初の課金は即時処理されるので注意 ・本来の使用用途ではないので 　二重課金防止の仕組みがすでにあるなら 　素直に複数商品用意したほうが良さそう
24. 課金してくれるユーザもいれば 解約するユーザもいます…
25. 　解約した人数を見る
26. 自発的・非自発的？
27. 自発的解約と非自発的解約 ・自発的解約 　→ユーザやPlay Console、 　　GooglePlay APIから解約されたもの ・非自発的解約 　→なんらかの理由によって 　　支払いができず解約されたもの
28. 非自発的解約の原因 ・クレジットカード期限切れ ・クレジットカード限度額超え ・ギフトカードなどのプリペイド残高不足 etc…(公式で原因の一覧化はされていない)
29. 非自発的解約になるまでのフロー ❌ 課金開始 課金継続 継続失敗 猶予期間 自動解約 （非自発的） 課金再開 課金開始 課金継続 解約(自発的)
30. GooglePlayConsoleから見れる
31. 具体的な数字はお見せできませんが… ・非自発的解約の割合がそれなりに高い 　→ユーザの意図しないタイミングで 　　解約されてそのまま復帰しない 　 　→本来救えたはずのユーザ分だけ 　　機会損失している
32. どうにか非自発的解約を 少なくしたい
33. 対策1:猶予期間伸ばす ・猶予期間を伸ばすだけでも 　非自発的解約者は結構減った 　→コンソールポチだけで効果絶大
34. 対策2:real-time developer notificationsを使う https://developer.android.google.cn/google/play/billing/realtime_developer_notifications ・ユーザの課金ステータスが更新されると 　GCPのCloud Pub/Sub(AWS Kinesis的なやつ) 　へ通知が飛ぶ仕組み ・猶予期間に入ったタイミングも分かる 　→猶予期間中にユーザにアプローチできる
35. 通知タイプ
36. 猶予期間をユーザに通知する流れ Cookpad 決済基盤 ログテーブル 日時バッチ APIサーバ ユーザ テーブル ①課金ステータス　 変更通知 ②Webhook 　(Push) ③通知ログ保存 ④通知ログ取得・ 　ユーザ情報に反映 ⑤猶予期間 　取得
37. 猶予期間状態のユーザに認知させる
38. 実装する上での工夫や注意点① ・通知に含まれる決済関連の情報は 　PurchaseTokenと呼ばれるトークンと商品IDのみ 　→詳細情報をGoogleDeveloperAPIに 　　問い合わせる必要がある ・アプリからGooglePlayの定期購入画面に 　遷移させたい場合、商品IDが必要になるので 　サーバから値を渡せるように設計する必要がある 　 https://play.google.com/store/account/subscriptions?sku=your- sub-product-id&package=your-app-package
39. 実装する上での工夫や注意点② ・ユーザの課金ステータスは 　日時バッチにして更新性をある程度犠牲にした 　 　→行き違いでユーザが復帰してる可能性がある 　　→その旨をユーザに知らせておく 　 　→アプリ側の通知UIはGooglePlayの定期購入画面 　　に遷移したら2、3日表示しない仕様にした
40. まとめ ・有料コンテンツの無料期間提供は効果高い ・ユーザごとに違った無料期間提供したい 　→Defer（課金の延期）を使って実現できた ・退会者の中に非自発的のユーザが比較的多い 　→猶予期間を伸ばすこと、 　　real-time developer notificationを使って 　　猶予期間中ユーザに知らせる仕組みを作った
41. お金は超便利！！
42. ありがとうございました！