Architecting for subscriptions

ハイライト

Apple は、サブスクリプション許可の判断をサーバー側の資格付与エンジンに集約し、レシート、サーバー間通知、ビジネス コンテキストを使用してユーザー ステータスを計算し、簡略化された資格ペイロードをクライアントに安全に返すことを推奨しています。

主要内容

多くのサブスクリプション システムでは、最初に 1 つの質問のみが行われます。「このユーザーは現在アクセス許可を持っていますか?」一般的に言えば、実装はproduct_idそしてexpires_date。有効期限が未来の場合はロックが解除され、有効期限が過去の場合はロックされます。

このモデルは間もなく無効になります。ユーザーは自動更新をキャンセルできますが、現在のサービス期間は終了していません。控除も失敗する可能性があり、Apple は引き続き請求の再試行で請求を試みます。アプリが猶予期間を有効にした場合、ユーザーは猶予期間中もサービスを受ける必要があります。アクティブか非アクティブかだけを確認すると、保持、支払い修正、アップグレードのプロンプトの機会を逃すことになります。

このセッションで得られる答えは、サーバー側の資格付与エンジンです。これは、レシート、サーバー間通知、サブスクリプション製品、およびビジネス コンテキストを、ユーザーがサービスにアクセスできるかどうか、サービスのステータス、クライアントが表示する必要があるメッセージまたはアクション エントリなどのシンプルな結果に整理します。

この利点は、責任が明確であることです。クライアントは、購入の開始、権利の表示、サーバーから返された資格ペイロードの受信を担当します。サーバーは、受信の確認、通知のマージ、ステータスの維持、ステータスが変化したときのアクセス許可の再計算を担当します。ビジネスに加入した後に新しい製品、新しいオファー、または新しい請求ステータスを追加する場合は、クライアントがリリースされるのを待たずに、最初にサーバー ロジックを変更することもできます。

詳細

サブスクリプションのジャーニーから状態をモデル化する

(01:21) このスピーチでは、まずアクティブ/非アクティブという二分法が解体されます。 5 月 1 日に 1 か月のサブスクリプションを購入した後は、通常どおりに更新することも、自動更新をキャンセルすることも、引き落としに失敗した後にサブスクリプションを復元することも、サブスクリプションは請求の再試行に入ることも、猶予期間内に復元することもできます。各パスは、サーバーが保存する必要がある状態と、クライアントが提供する必要があるエクスペリエンスを変更します。

キーポイント:

• 初回購入により、初回購入のサーバー間通知がトリガーされます。
• 自動更新をオフにした後も、現在の期間は引き続きサービスを利用できますが、将来的には期限が切れます。expires_dateそしてexpiration_intent活発な消耗を示します。
• 請求の再試行は、Apple がまだ支払いを回収しようとしており、クライアントが App Store の支払い情報を更新するようにユーザーを案内するのに適していることを示します。
• 猶予期間内に復元すると、元の請求日の継続性が維持され、アプリはサービスを提供し続け、残り時間を表示する必要があります。

受領書と通知を資格付与エンジンに供給する

(11:43) Apple は、この一連のサーバー側ロジックを資格エンジンと呼びます。入力には、レシート、サーバー通知、アプリ自体が保持するユーザー コンテキストが含まれます。出力は、ユーザー データベースを更新する簡素化された JSON ペイロードであり、デバイスに安全に返すことができます。

キーポイント:

• アプリのレシートは、トランザクションデータを確認するための事実のソースです。最初のステップは、各領収書の信頼性を確認することです。
• 最初のレシートの有効期限が切れた場合、サーバーは App Store に報告する必要があります。verifyReceiptエンドポイントは最新の領収書情報を要求します。
• サブスクリプション データが分散されているlatest_receipt_info、pending_renewal_infoフィールドにある場合、エンジンはそれらを結合して実用的な情報を生成する必要があります。
• サブスクリプションが複数のアプリまたはプラットフォームにまたがる場合、サーバーは、ユーザーが繰り返し販売されたり、誤ってロックされたりするのを防ぐために、受信以外のステータスもマージする必要があります。

ステータスをコホートと資格コードに圧縮する

(15:35) エンジンの中間層は、最初に加入者のコホートを定義し、次に多数の受信フィールドをビジネス ステータスに統合します。スピーチ内の例では、ステータスを数値に割り当てています。正の値はサービスのロックを解除できることを意味し、負の値は製品にサービスを提供しないことを意味します。 substate は、小数部分を使用して、無料トライアルやサブスクリプション オファーなどの製品コンテキストを区別します。

キーポイント:

• コホートにより、サーバーは複雑なフィールドの組み合わせを安定したビジネス信号に変換できます。
• 資格コードはサーバーに保存したり、単純な信号としてクライアントに送信したりできます。
• 同じ正の値は、「ロック解除」を表すだけでなく、無料試用期間中に自動更新がオフになっているなど、より詳細なステータスも表します。
• このコーディング方法は単なる例であり、実際の製品は独自のサブスクリプション層、プロモーション戦略、請求ステータスで拡張できます。

アクションをさまざまな状態にアタッチする

(17:48) 応答オブジェクトにすでに資格情報が含まれている場合、サーバーはステータスに基づいてアクションを添付できます。講演では、いくつかの典型的なシナリオが挙げられました。ユーザーが自動更新をオフにすると、オファーは保持されます。猶予期間中、サービスは引き続きロック解除され、支払いを更新するよう通知されます。請求の再試行では、制限付きアクセスが提供され、請求を修復するように案内されます。有効期限が切れたユーザーは、特典を受け取ります。継続更新のために毎月支払うユーザーには、年次支払いのアップグレードの提案が表示されます。

キーポイント:

• 資格応答は単なるブール値ではなく、メッセージ、オファー、または次のアクションを伝えることもできます。
• 猶予期間と請求の再試行は、支払いを修復するという同様の目的を持っていますが、サービス権限が異なります。
• ウィンバック プッシュには、アプリ内の適切な支払いページへのディープ リンクが必要です。
• アップグレードの提案を更新回数とサブスクリプション グループ ID と組み合わせて、忠実な月払いユーザーに年払い製品を推奨できます。

ステートレスリクエストから永続化システムまでのアーキテクチャの反復

(19:55) Apple は、ステータスの変更が発生したときに最新の権限をすぐに計算できるように、権限付与エンジンを高可用性サービスにすることを推奨しています。最小限の実装では、まず、デバイスがリクエストを行うたびに、処理のためにサーバーにレシートを送信できます。このバージョンは、多くのサブスクリプション機能をサポートし、ストレージの例外や通知が見逃された場合のフォールバック パスとしても使用できます。

キーポイント:

• エンジンをサーバーに配置した後、レシートまたは疑似レシート データを使用して権限ロジックのエラーをテストし、直接デプロイしてエラーを修正できます。
• ステートレスなリクエストのみを行う場合、デバイスは毎回レシートを送信する必要があります。永続的なレシート データがなければ、Web または他のプラットフォームからのアクセスをサポートするのは困難です。
• 永続ストレージを追加すると、サーバーはレシート データと資格情報を保存し、Web およびオフプラットフォーム アクセスをサポートできるようになります。
• App Store サーバー通知エンドポイントを追加すると、サブスクリプション ステータスが変更されたときにサーバーに通知できるため、verifyReceiptエンドポイントポーリング。
• クライアントが資格データを要求した場合、講演では、データが独自のサーバーからのものであることを証明するために JSON Web 署名の使用を検討することを推奨しています。

重要ポイント

• サブスクリプション ステータス コンソール: 機能: 各ユーザーのサブスクリプション状態、サブステート、最近の受信フィールド、およびカスタマー サービス、運用、エンジニアリング チーム向けのサーバー通知タイムラインを表示します。実行する価値がある理由: Session は、ステータスが複数の受信フィールドとユーザーの行動から得られることを繰り返し強調しています。コンソールを使用すると、「ユーザーがロックされている理由」のトラブルシューティングのコストを削減できます。開始方法: 最初に押してくださいlatest_receipt_info、pending_renewal_info通知イベントを含む読み取り専用のタイムラインを生成し、成人が読み取ることができるステータス ラベルに資格コードをマップします。
• 支払い修復ポータル: 対処方法: 請求の再試行と猶予期間に別の支払い修復プロンプトを表示します。実行する価値がある理由: Billing Retry は支払い情報の更新をガイドするのに適しており、Grace Period にはサービスの残り時間も表示されます。開始方法: エンタイトルメント応答に請求アクション、サービスが引き続きオープンされるかどうか、猶予期間の残りの情報を含めてから、クライアントを App Store アカウントの支払い設定にディープリンクします。
• 更新キャンセル後の保持オファー: 対処方法: まだ有効期間内であるが自動更新をオフにしているユーザーを特定し、保持オファーまたはその後のサブスクリプション オファーを表示します。実行する価値がある理由: 講演で挙げた保持の例では、自動更新ステータスと現在のサブスクリプション製品を使用して保持を実現しています。開始方法: 資格エンジンで自動更新をオフにして保持メッセージをアクティブ コホートに追加し、ペイウォールがこの状態でのみ表示されるようにします。
• 忠実なユーザーに対する年払いアップグレードの推奨事項: 対処方法: 複数の期間でサブスクリプションを更新した月​​払いユーザーを年払いサブスクリプションに誘導します。実行する価値がある理由: Session では、更新回数とサブスクリプション グループ ID を使用して忠実なユーザーを特定し、割引アップグレードを提供することを推奨しています。開始方法: サーバー側で同じサブスクリプション グループの更新数を集計し、しきい値に達した後、資格ペイロードに年次アップグレード アクションを追加します。
• クロスプラットフォーム資格ラッパー: 対処方法: iOS、Web、およびその他のプラットフォームすべてが同じサーバー側資格エンドポイントを要求できるようにします。実行する価値がある理由: 講演では、受信データが保存されて初めて Web およびオフプラットフォームへのアクセスがサポートされ、通知が見逃された場合に保存されたデータを使用して精度を維持できることが指摘されました。開始方法: まず、デバイスからレシートを送信するためのステートレス インターフェイスを実装し、次にレシート ストレージ、通知エンドポイント、データベース同期プロセスを徐々に追加します。

関連セッション

• アプリ内購入の新機能 - 払い戻し、App Store サーバー通知、領収書、サブスクリプション ステータスを補足する 2020 年の更新。
• Xcode での StoreKit テストの紹介 - まず、StoreKit、受信およびサブスクリプションのシナリオをサンドボックスを使用してローカルで検証し、次にサーバー側の資格付与ロジックを接続します。
• App Store Connect の新機能 — App Store Connect のアプリ内購入、サブスクリプション、管理ツールの更新について説明します。
• App Store Connect API による自動化の拡張 — App Store Connect の管理、レポート、分析プロセスを自動化し、サブスクリプション ビジネスのバックエンド リンクを補完します。