【RevenueCat】OfferingなどのRevenueCat独特の構成を理解する
Entitlement、Offering、Package, Productなど、RevenueCat独特の構成?が存在する。
公式ドキュメントにも詳しく図付きで説明してくれているので分かりやすいが、理解するまで少し時間がかかったので自分なりにざっくりまとめてみた。
※より詳細に正しく知りたい方は公式ドキュメントを参照してください。
※この記事の添付画像はAppleのサブスク製品のみが記載されていますが、GooglePlayのサブスク製品も同様の対応です。

RevenueCatのコンソールでいう赤枠部分が対象
全体の構成例

Product

名前の通り「製品 ≒ サブスク製品」のこと。
AppStoreConnectやGooglePlayで作成したサブスク製品を全てRevenueCatのProductsに登録する。
登録する際は、AppStoreConnectやGooglePlayで作成した製品IDを使用することで、RevenueCatと紐づく。

RevenueCatコンソール

AppStoreConnect
Entitlement

ユーザーが受け取れる、アクセス、機能、コンテンツのレベルのこと。
仮に、以下のような課金体系のアプリがある場合、Entitlements定義は2種類必要。
- free版
- pro版(Entitlements:pro)
- premium版(Entitlements:premium)
Productsに登録したサブスク製品を、該当のEntitlementに全てAttachしていく。

RevenueCatコンソール: Entitlements

RevenueCatコンソール: Entitlements > [Entitlement名]
Package

複数プラットフォームの同じレベルの製品をまとめたもの。
アプリが複数のプラットフォームで共有する場合、各プラットフォームの同等の製品を1つのPackageにまとめる必要がある。
※アプリがWeb版も存在して、アカウントを共有する必要があるなら、Stripなども同様の対応をする。
RevenueCatのコンソールにはPackages単体の項目はなく、Offeringの設定の中でそれぞれPackageを作成することになる。
以下のOfferings章を参照。
Offering

アプリの支払い画面などでユーザーに見せる製品一覧のこと。
上記で設定したPackageを組み合わせることで、特定の条件のユーザーに異なる製品一覧を動的に表示することが可能。
詳細はこちらも参照:docs/製品の表示
Offeringsを設定した場合、アプリのアップデートを必要とせずにユーザーに表示する商品をコントロールすることができる。
様々な商品構成に対応できる動的な支払い画面を構築することで、リモートアップデートの柔軟性を最大限に高めることができる。
Best Practices(docs引用)
| Do | Don't |
|---|---|
| ✅ ハードコードされた文字列を最小化または削除して、支払い画面を動的にする | ❌ 特定のプロダクトIDでハードコードされた静的な支払い画面にする |
| ✅デフォルトのPackage typesを使用 | ❌デフォルト・オプションの代わりにカスタム・パッケージ 識別子を使用 |
| ✅ 任意の数の商品を選択できるようにする | ❌一定の商品数のみをサポートする |
| ✅ 異なる無料トライアル期間、または無料トライアルなしをサポート | ❌ 無料トライアルテキストをハードコードする |

RevenueCatコンソール: Offering

RevenueCatコンソール: Offering > [Offering名]

RevenueCatコンソール: Offering > [Offering名] > [Package名]
備考
どの項目はIdentifierは変更できないので、命名規則はプロジェクトで考えてから作成すること注意。
NCDC株式会社( ncdc.co.jp/ )のテックブログです。 主にエンジニアチームのメンバーが投稿します。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください!
Discussion