Google Billing LibraryのOfferの検証
はじめに
Google Billing Library 5からSubscription(定期購入)の概念が変わり、Base PlanやOfferといったものが複数紐づけられるようになった。この概念の簡単なまとめとOfferの挙動を調査した結果を示す。
前提知識
定期購入(Subscription)
Google Billing Library 5からSubscription(定期購入)の概念は以下のようなイメージ。
基本プラン(BasePlan)
Subscriptionの請求対象期間、更新の種類(自動更新or前払い)、金額などを設定し示すもの。Subscriptionに対して複数紐づけられるようになっている。
自動更新 | 前払い |
---|---|
オファー(Offer)
Offerはユーザに提供する特典を示す(例:無料試用、割引など)。各Base Planに対して複数紐づけられるようになっている。提供条件としては以下の3つが存在する(2023/10月時点)。
- 新規ユーザの獲得(以下の利用資格が選べる)
- この定期購入を利用したことがない
- 定期購入をまったく利用したことがない
- アップグレード(以下の条件指定が必要)
- 現在の定期購読
- 現在の請求対象期間(1日〜1年)
- 利用上限(1回 or 無制限)
- デベロッパー指定
新規ユーザの獲得 | アップグレード | デベロッパー指定 |
---|---|---|
さらにOfferには最大2つまで段階がつけられる。こちらは実際にどのような特典を付与するのかを示すもの。この段階にも以下3つのタイプが存在する。3つのタイプのいずれかを選択し、提供する期間や価格を下げたりなどの設定ができる。
- 無料試用
- 定期購入ユーザの支払いは、指定期間が発生するまで発生しない
- 1回限りのお支払い
- 定期購入ユーザは、指定期間に対して事前に支払う
- 割引が適応された定期的なお支払い
- 定期購入ユーザは、指定された回数だけ割引料金の支払いを行う
無料試用 | 1回限りのお支払い | 割引が適応された定期的なお支払い |
---|---|---|
Offerの提供条件における挙動調査
1.新規ユーザの獲得
目的
以下のような商品をGoogle Play Console上で作成した時に無料試用期間(オファー)が各プラン(PlanID)に対して反映されるのか、それとも定期購読(ProductID)に対して反映されるのか検証する。前者であれば、3回無料試用期間が使える。後者であれば1回のみ使えるはずである。
商品設計
無料試用(トライアルオファー)設定設定
無料試用1ヶ月のオファー設定は以下の通り。1年、1ヶ月、1週間の各プランに同じ条件のオファーを紐づけている。
特典 | 提供条件 | 新規ユーザの獲得 |
資格 | この定期購読を利用したことがない | |
段階 | タイプ | 無料試用 |
時間 | 1ヶ月 |
特典 | 段階 |
---|---|
結果
Google Play Console上のオファー設定にもあるように特典の提供条件の資格が「この定期購読を利用したことがない」にすると定期購読(ProductID)に対して1回のみとなる。こちらの判定はGoogle Playが行うため、対象であればGoogle Billing LibraryのqueryProductDetails
でオファーを含む商品が返ってくる(スクショ左でFreeとついた商品が無料試用1ヶ月の特典をつけたもの)。
オファーがついた商品を選択することで無料試用期間が提供される。無料試用の特典利用後は1年、1ヶ月、1週間のいずれかの商品の無料試用特典はなくなる(スクショの右のようになる)。queryProductDetails
でもオファーを含まなくなるので無料試用の特典が選べなくなる。
無料試用資格あり | 無料試用資格なし | |
---|---|---|
商品一覧 | ||
商品購入 左は特典付き、右は特典なし |
2.アップグレード
目的
1.新規ユーザの獲得で定期購読プラン1を購読したと仮定する。その上で別の定期購読にアップデートする(ここでは切り替えのニュアンスに近い)時の挙動を調査する。1.新規ユーザの獲得で作成した定期購読プラン1に加えて別プランとしてGoogle Play Console上で以下のような定期購読プラン5を作成する。
商品設計
1回限りのお支払い(割引オファー設定)
こちらのオファーをスタンダード1ヶ月プランに紐づける。設定は以下の通り。
備考 | |||
---|---|---|---|
特典 | 提供条件 | アップグレード | |
現在の定期購入 | test.inappbilling.subscription.plan1 | 指定した定期購入を購読中なら提供条件に合致することになる。この場合は定期購読プラン1から定期購読プラン5へのアップグレードする場合は特典対象条件を満たすことを意味する。 | |
現在の請求対象期間 | 指定なし | 基本プランの方で設定している期間と一致するならば提供条件に合致することになる。指定なしの場合はこの条件はスキップされる。例えば定期購読プランの1ヶ月プランから定期購読5プランへ アップデートする時のみ特典付与したいのであれば、ここを1ヶ月に指定する。 |
|
利用上限 | 無制限 | ||
段階 | タイプ | 1回限りのお支払い | |
時間 | 3ヶ月 | ||
価格のオーバライド | 固定額 |
特典 | 段階 |
---|---|
割引が適応された定期的なお支払い(割引オファー設定)
こちらのオファーをプレミアム1ヶ月プランに紐づける。設定は以下の通り。
備考 | |||
---|---|---|---|
特典 | 提供条件 | アップグレード | |
現在の定期購入 | test.inappbilling.subscription.plan1 | 指定した定期購入を購読中なら提供条件に合致することになる。この場合は定期購読プラン1から定期購読プラン5へのアップグレードする場合は特典対象条件を満たすことを意味する。 | |
現在の請求対象期間 | 指定なし | 基本プランの方で設定している期間と一致するならば提供条件に合致することになる。指定なしの場合はこの条件はスキップされる。例えば定期購読プランの1ヶ月プランから定期購読プラン5へアップデートする時のみ特典付与したいのであれば、ここを1ヶ月に指定する。 | |
利用上限 | 無制限 | ||
段階 | タイプ | 割引が適応された定期的なお支払い | |
時間 | 3ヶ月 | ||
価格のオーバライド | 割引率 |
特典 | 段階 |
---|---|
結果
オファー(特典)の提供条件である定期購読プラン1を購読中であれば定期購読プラン5のオファー(特典)を含む商品ががGoogle Billing LibraryのqueryProductDetails
で返ってくることを確認した(スクショの左のもの)。逆に未購読の場合は提供条件を満たさないのでオファーは返ってこなかった。また「1回限りのお支払い」の特典、「割引が適応された定期的なお支払い」の特典どちらも設定で「無制限」にしていたため、何度でも特典つきの商品は購入できた。
定期購読プラン1購読中 | 定期購読プラン1未購読 | |
---|---|---|
商品一覧 | ||
商品購入 左は特典付き、右は特典なし |
「1回限りのお支払い」の特典付きの商品購入時
また、「1回限りのお支払い」の特典が適応されたかを確認した。3ヶ月を1回支払いとして固定額¥7として設定したので特典ありの商品を購入した時に割引価格の¥7が最初の支払いで確認できた。その後は通常価格の¥8で自動更新されたことが確認できた。
時刻 | 事象 |
---|---|
9:15 | 「1回限りのお支払い」の特典をついた商品を購入 |
定期購読プラン1から5へアプデートしたというメールが届く | |
9:17 | 自動更新されたメールが届く(価格は割引された¥7) |
9:22 | 自動更新されたメールが届く(価格は通常価格¥8) |
9:27 | 自動更新されたメールが届く(価格は通常価格¥8) |
9:32 | 自動更新されたメールが届く(価格は通常価格¥8) |
9:37 | 自動更新されたメールが届く(価格は通常価格¥8) |
9:42 | 自動更新されたメールが届く(価格は通常価格¥8) |
9:47 | 自動更新されたメールが届く(価格は通常価格¥8) |
9:52 | キャンセルされたメールが届く |
「割引が適応された定期的なお支払い」の特典付きの商品購入時
同じく「割引が適応された定期的なお支払い」の特典が適応されたか確認した。内部アプリテストを使用しているため、3ヶ月の割引が効くのであれば、15分(内部アプリテストでは1ヶ月が5分になるので5分x3)は割引額が適応されるかと想定していた。こちらは想定通り3ヶ月分を示す15分間は価格は¥7であった。その後は通常価格である¥9に戻った。
時刻 | 事象 |
---|---|
10:01 | 「1回限りのお支払い」の特典をついた商品を購入 |
定期購読プラン1から5へアプデートしたというメールが届く | |
10:05 | 自動更新されたメールが届く(価格は割引された¥7) |
10:10 | 自動更新されたメールが届く(価格は割引された¥7) |
10:15 | 自動更新されたメールが届く(価格は割引された¥7) |
10:20 | 自動更新されたメールが届く(価格は通常価格¥9) |
10:25 | 自動更新されたメールが届く(価格は通常価格¥9) |
10:30 | 自動更新されたメールが届く(価格は通常価格¥9) |
10:35 | 自動更新されたメールが届く(価格は通常価格¥9) |
10:40 | 自動更新されたメールが届く(価格は通常価格¥9) |
10:45 | 自動更新されたメールが届く(価格は通常価格¥9) |
10:45 | キャンセルされたメールが届く |
デベロッパー指定
デベロッパー指定にした場合、queryProductDetails
で毎回この特典は返ってくる(スクショのdeveloper-offerの商品)。そのため提供条件のロジックをアプリ内部で作成する必要がある。商品一覧を表示する画面でアプリ内部の提供条件に合致する場合はデベロッパー指定の特典を持つ商品を選択可能にし、条件に合致しない場合は選択不可または非表示にするなどが必要と考える。
なお、特典はあくまで「段階」で設定する「無料試用」、「1回限りのお支払い」、「割引が適応された定期的なお支払い」になる。また、利用回数などをGoogle Play Console上で設定しないのでこの辺りのロジックもアプリ内部に持つ必要があると考える。(無料試用に関してはProductIDに対して1回限りの様子)
商品一覧 | デベロッパー指定特典付き商品購入 | デベロッパー指定特典付き商品再度購入 |
---|---|---|
まとめ
オファーの設定による購入時の挙動を確認した。提供条件を新規ユーザ獲得やアップデートなどに絞りGoogle Playに任せるのかデベロッパー指定で自分自身で定義するのかでやることが大きく変わることがわかった。
無料試用期間を提供したい場合はGoogle Playに任せたほうが正確かつコストがかからない可能性がある。またアップデートを使用する場合は商品設計や重要になると感じた。どの定期購読からどの定期購読へアップデートしたした場合に特典の対象になるかをGoogle Playで設定することで実装コストは少なくなりそうだが、管理コストやカスタマイズ性が難点かもしれない。反対にデベロッパー指定の場合はカスタマイズ性があるが実装コストは高い。
どれを使用するかは商品設計やケースバイケースで変わると思う。
*今回使用したコードは以下になります。今回の調査内容はあくまで個人で調査した内容です。
Discussion