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

Session概要

サブスクリプション利用者のジャーニーを理解する

• 以前まではサブスクリプション利用者（サブスクライバー）がアクティブかどうかを判断する要素として、プロダクトIDや終了日などレシートフィールドの要素でした
  • 新しいリリースでは、支払い回収の試みと猶予期間を追加
    
    

サブスクリプションのキャンセル

• 例えば、5/1にサブスクリプションサービスを購入したとして、翌月6/1には更新を行うが、6/17にサブスクリプションをキャンセルしたとする
  • キャンセル時点でAppleは開発者にサブスクライバーが自動更新を解除したことをサーバ間通知で送る
• キャンセル後、何も操作しなければサブスクリプションはキャンセルされ、このことはレシートの応答で終了日と期限切れ理由によって示される
  
  

Appleが支払いの回収をユーザからできなかった場合

• 5/1に初回購入の通知後、Appleは次の更新日に支払いを回収できない
  • ユーザはApp Storeの支払い情報の設定で、支払い方法を更新した
  • 6/15の時点でAppleは開発者にサブスクライバーの更新が成功したことを通知し、以降はサービスが再開した15日に更新が行われるようになる
    
    

開発者がユーザにサブスクリプションサービス利用の猶予期間を有効化できたら？

• ↑の例でも、1日に初回購入がありますが、次の更新日に支払いを回収できませんが、16日以内に登録の回復があれば請求期間は中断されません
• 下記のように、更新日自体も次回以降の更新も1日のままとなります
• このように、単にサブスクライバーがアクティブかどうかだけでなく支払い回収の試み、猶予期間中なのか、アップグレード、ダウングレード、クロスグレードなどの基本的なアクションなどの複雑な請求ステータス、サブスクライバーにメッセージを送る機会です
• よりよいユーザ体験を提供し、解約を減らしコンバージョン率を上げることができます
  
  

• ユーザのアクションに適格に反応するには、サブスクライバーの状況を調べる
  • サブスクライバーの状況の識別が購入過程での重要な一歩
  • これは開発者がユーザに提供したい体験の理解を助ける
• サブスクリプションオファーの場合も、返金によりサービスを無効にする場合もサブスクリプションの状況の把握が重要
• レシート情報には、サブスクリプションオファーの情報やフリートライアル情報も含まれる
  
  

複雑な状況とその後のアクション例

リテンション

• サブスクリプションの状況を確認するためには、最新のレシートデータが必要
  • アクティブかどうかだけでなく、ユーザの自動更新状況と登録プロダクトに基づくサブスクライバー維持のためのサブスクリプションオファーがあります
• この例では、レシート情報を見るとサブスクライバーはオファーを提供されています
  • 開発者はフォローアップのオファーでサブスクライバーを維持したいでしょう
    
    

請求の再開

• サブスクリプションは期限切れですが、 支払いの回収が試みられています
  • Appleが更新のために支払いの回収を試みている
• サブスクライバーの支払い情報更新のためにApp Storeアカウントへのリンクである下記のようなバナーを残したいケースがあります
  
  

猶予期間

• 下記の例では、個別のレシートフィールドからサブスクライバーが支払いの猶予期間にいることがわかる
• サービス利用の残り日数をサブスクライバーに提示できます
  • これもApp Storeの支払い情報へのディープリンクです
  • サブスクライバーに支払いの更新を通知します
    
    

休止中のユーザの復帰

• 特別の体験を提供する機会は、休止中のユーザを復活させると時にもあります
• このケースでは、ユーザが休止となっている理由やサブスクリプションの内容を確認することが重要
• そして、再開を促すためにマーケティングオファーのPush通知を送信します
  • アプリ内の適切な支払い画面へのディープリンクでなければならない
    
    

アップグレード

• アクティブ（自動更新オン）、標準サブスクリプションのユーザには、可能なアップグレードの機会をサブスクライバーに提示することでよりよい体験を提供したいでしょう
  • この例のユーザは月更新のプロダクトを購入し、複数回更新を続けています
  • 年間プランへのアップグレードをオファーし、割引価格を提供して忠実なサブスクライバーに報いられます