サブスクリプションのためのアーキテクチャ設計 〜パート2〜 WWDC2020

Session概要

サブスクリプションの権利における要素

• サブスクリプションの権利の基礎は、コンテンツへのアクセス権ですが、単なるロック解除による可視領域の範囲増加だけでなく、地理的な可用性や課金状況などサービスレベルに基づいて異なる
• ユーザにプロダクトを提供する前やアップグレード・ダウングレード時に、適正判断が必要です
• 無料トライアルやオファーに対するユーザの適正に応じて、プロダクトの提供方法や時期が変わる
  • App Storeには無料トライアルなどに対し、適正基準があるが、オファーに対する適正はビジネスニーズに応じて調整可能
• ユーザへの通知は、終了日の通知以外にも役に立つ
  • サービスの利用状況に応じて、個々のニーズに合った宣伝や課金に関する通知を送れる
    
    

エンタイトルメント（権利）エンジンの活用

• ユーザのサービスにおける権限を取得したデータから算出し、エンジンはユーザの利用サービスや課金状況における変更をサポートする
  • 具体的には、レシートデータやアプリケーションのインサイトを活用して正確な権利情報を算出する
    
    

エンタイトルメントエンジンのコード化

• レシートやサーバ通知などサブスクリプションのデータをエンジンに送り、JSONペイロードを作成する
• それを権限の付与やデータベース更新に使用する
• アプリのレシートは実績データを調べるソースであり、最初のステップはレシートの正当性を検証する
  • verifyReceiptエンドポイントから最新のレシート情報を取得する
• 複数のアプリをまたぐサブスクリプションの場合、レシートに含まれないサブスクライバーのステータスも加味して不要なロックやサブスクリプションの重複購入を防ぐ
• 次に集めた関連データを統合する
  • 情報をまとめて実用的なインサイトへ変換する
  • 最新のレシート情報の配列や待機中の更新情報の配列など、情報はレシート内や複数の配列に散在している
  • 最終的なレスポンスに含む、データオブジェクトを作成する
  • この段階でキー情報を設定しアタッチすることで、ユーザのサービスの利用状況を判断できる
    • 例えば、サブスクリプションのプロダクトと必須情報からレスポンスを生成し、どんなサブスクリプションサービスでも価値のあるキーデータはプロダクトIDやトライアルの有無、終了日など
  • 次にエンタイトルメントのプロセスに影響を与えるレシート外のインサイトを追加する
    • 例えば、視聴時間や興味がありそうなイベント情報など
• コホートでは、サブスクリプションのあらゆるステートを対象としたコホートを作成すべき
  • ステートごとのコホートを作成することで、サービスの利用状況に基づいたオリジナルの体験を提供可能
• 作成したコホートを使ってエンタイトルメント情報を決定する
  • レシート情報とユーザのステートを合わせて、エンタイトルメント情報を決める
    
    

ユーザの状態によるコホート、レシートデータ、カスタムデータの利用例

リテンション

• 自動更新を無効にされた場合の利用者の維持
  • エンタイトルメントコード4.0とプロダクトを含むステートの場合に契約更新の通知や新たなオファーの送付が可能
    
    

猶予期間

• 課金の猶予期間のステートは継続したサービス利用が可能で、エンタイトルメントコードと猶予期間、さらなるアクションを対象としたロジックを追加することで、ユーザに課金情報の更新を促し、不本意な解約を防ぐことができる
  
  

支払いの試み

• 猶予期間と支払い回収の試みは異なるが、アクセス制限をしながら課金情報を更新させる目的は同じ
  
  

休止中のユーザの復帰

• エンタイトルメント情報を用いて、サービスを解約したユーザにサブスクリプションオファーを提示可能
  
  

アップグレード

• 忠実なサブスクライバーに対しても、コードと更新回数やグループIDを用いて、契約のアップグレードを提案可能
  
  

システムアーキテクチャ内でのエンタイトルメントエンジンの活用法

• 活用することによるメリット
  • 高度なエンタイトルメントエンジンは、変更が生じた瞬間に最新のエンタイトルメント情報を算出し、対応する
  • あらゆるステートでこの機能を有効にすることで、確実にサブスクライバーに適した権限を与えることができる
  • このプロセスは不測の事態に対する安全装置でもある
  • 新たに加わる機能や将来的なビジネス状況の変化にも対応可能
• 通知やストレージを使用しない基本的な実装に対してもサポート可能な機能が多くある
  • サブスクリプションオファーなど
  • サーバ側でエンジンを走らせれば、ロジックのエラー修正や更新が可能でレシートデータを検証した後、すぐにロジックを展開可能
  • クライアントの更新に頼らず、インバウンドリクエストにより適切なアクセス権を与えられる
  • ただし、リクエストで処理するレシートを送信するデバイスは必要となる
• DBなどの永続ストレージに最終的なエンタイトルメント情報とレシートデータを保管すれば、Webやプラットフォーム外を経由してアクセスを許可できる
  • その際、App Storeのサーバ通知を処理するエンドポイントを追加することで、レシートの検証用エンドポイントでポーリングするよりもステータスの変更が瞬時にわかる
  • 通知が受け取れない場合でも、永続ストレージ内のレシートデータにより正確性を維持することが可能