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

こんにちは　WWDCへようこそ “サブスクリプションのための アーキテクチャ設計” 皆さん　ご視聴ありがとうございます マイケル･ガルガスです App Storeコマースチームの テクニカルアドボケイトです 今日は新しいコンセプトを紹介します プラットフォームで― サブスクリプションのサービスを ビルドし維持する方法です ビジネスとエンジニアリングだけでなく サーバサイドとデータ分析にも 役立ててください すでにサブスクリプションを提供している方にも 始めたばかりの方にも― エンタイトルメントの構成の作成に関する 重要な情報をお伝えします サーバサイドのシステムを 構築または再構築して Appleが提供する新機能を 活用する方法を紹介します サブスクリプションのプラットフォームを ビルドするには サブスクライバーがたどる道を 理解することが重要です そこからサブスクリプションの エンタイトルメントを定義し カスタムロジックを作ります エンタイトルメントエンジンを利用して サブスクライバーに特別の体験を提供し すべてを実現します

ここからはサブスクライバーがたどる道と アクションごとの複雑な状況を詳しく見ましょう

以前はアクセスを与える根拠として 使っていたのは プロダクトIDや終了日など １つか２つのレシートフィールドでした つまりサブスクライバーが アクティブかどうかです 新しいリリースでは 支払い回収の試みと 猶予期間を追加しました レシートフィールドの組み合わせは より複雑になり その理解にはレシートの深い知識が必要です

サブスクリプションの例を カレンダーで見ましょう 期限が１ヵ月のプロダクトを ５月１日に購入しています サブスクライバーのアクションが その状況に与える影響を見ましょう ベーシックなサブスクリプションで ５月１日に購入があり Appleはデベロッパにサーバ間通知を送ります 初回購入があった通知です サブスクライバーによる 他のアクションがなければ サブスクリプションは 翌月１日に継続的に更新されます しかしサブスクライバーが キャンセルを決めたとします

翌月１日に サブスクリプションは更新されましたが サブスクライバーはApp Storeの サブスクリプションの管理で キャンセルを選びました この時点でAppleはデベロッパに サーバ間通知を送ります サブスクライバーが 自動更新を解除したと知らせます その後 他のアクションがなければ このサブスクライバーは自発的に サブスクリプションを終了します このことはレシートの応答で終了日と 期限切れの理由によって示されます

この例は― Appleが支払いの回収を ユーザからできなかった場合です １日に初回購入の通知があります しかしAppleは 次の更新日に 支払いを回収できません ユーザはApp Storeの支払い情報の設定で 支払い方法を更新しました この時点で Appleはデベロッパに サブスクライバーの更新が 成功したことを通知します 今後は サービスが再開した15日に 更新が行われます しかしデベロッパが猶予期間を有効化できたら？ この例でも １日に初回購入がありますが 次の更新日に支払いを回収できません しかし猶予期間が有効です 16日以内に登録の回復があれば― 請求期間は中断されません ご覧のとおり― Appleは今後も１日に更新を続けます サブスクライバーがたどる道は それぞれ違うという理解が重要です そのため理解すべきなのは すべてのレシートフィールド サブスクライバーのアクションにより Appleが送る通知 異なる状況は 特定のサブスクライバーの アクションの結果かもしれないことです

これらの例のように サブスクリプションの状況は アクティブかどうかだけではありません アップグレード ダウングレード クロスグレードなどの基本的なアクションや 支払い回収の試み 猶予期間などの 複雑な請求のステータスも サブスクライバーにメッセージを送る機会です よりよい顧客体験を提供し 解約を減らし コンバージョン率を上げることができます

過去のセッションでも サブスクリプションのサービスを向上する― ツールや機能を紹介してきました 支払処理を助けるStoreKitのフレームワーク サーバ間通知や改善されたレシートデータ これらは魅力あるサブスクリプションを 作るための土台を築いています

これらのセッションを ぜひ見てください 既存の機能と新機能の最新情報が得られ アプリケーションの統合に役立ちます

顧客のアクションに適格に反応するには サブスクライバーの状況を調べます

サブスクライバーの状況の識別が 購入過程での重要な一歩です これはデベロッパが ユーザに提供したい体験の理解を助けます サブスクリプションオファーの場合も 返金によりサービスを無効にする場合も サブスクリプションの状況の把握が重要です

サブスクリプションの状況では サブスクライバーのこれまでと今 そして今後どんなイベントがあるかを 知ることが重要です

レシート内のデータの深い知識が サブスクリプションの状況の把握に重要です レシートの更新イベントは静的エントリーで サブスクライバーの現状を示しています

状況はレシートフィールドの値の 組み合わせから推測できます これらの状況から サブスクライバーそれぞれの体験を作り 体験内で関連あるアクションを取れます

さらによく見ると サブスクライバーの状況は さまざまだと分かります いろいろなレシートの値の組み合わせです 今後予定される期日の値や 自動更新がオンになっていることを示す アクティブの値などです

ユーザが利用しているオファーを示す― 下位の状況も定義しました 無料トライアルや サブスクリプションオファーです

状況と下位の状況の背景にある複雑さを これで理解できるでしょう これらの現実世界での現れ方を見ましょう そして どんなアクションやメッセージを デベロッパが結果として望んでいるかも 複雑な状況とその後のアクションを ５つの例で見ましょう サブスクライバーの状況を確認するためには 最新のレシートデータが必要です

終了日だけ見ると “アクティブ”と表示されています サブスクライバーの状況を見極めるためには 最新のレシートデータを見る必要があります 終了日しか使わないと “アクティブ”とだけ表示されます

しかし もう少し深く見てみましょう ユーザの自動更新状況と 登録プロダクトに基づく― サブスクライバー維持のための サブスクリプションオファーがあります この例では サブスクライバーは オファーを提供されています デベロッパは― フォローアップのオファーで サブスクライバーを維持したいでしょう

ここも深く見てみましょう サブスクリプションは期限切れですが 支払いの回収が試みられています つまりAppleが― 更新のために支払いの回収を試みています サブスクライバーの支払い情報更新のために App Storeアカウントへのリンクである― このバナーを残しておきたいでしょう

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

特別の体験を提供する機会は 休止中のユーザを復活させる時にもあります ここで確認するのは ユーザが休止した理由や 利用していたサブスクリプションです そして再開を促すために マーケティングオファーの プッシュ通知を送信します

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

５つの状況と下位の状況を見ましたが アクティブと非アクティブの状況は ありませんでした サブスクライバーのアクションに基づく結果は さらに多くあります サブスクリプションのエンタイトルメントの 定義には これが重要です エンタイトルメントについては ギャレットから説明します App Storeのソリューションエンジニア ギャレット･コックスです マイケルが説明したとおり サブスクライバーは― サービス利用中に さまざまなステートを通過します そのステートを基に エンタイトルメントのプロセスを作ります サブスクリプションのエンタイトルメントを 構成する要素を見ましょう

エンタイトルメントの基礎は コンテンツへのアクセス権ですが アクセス権の範囲は広範囲に及びます 単なるロック解除ではなく アクセス権は地理的な可用性や課金状況 サービスレベルに基づいて異なります ユーザにプロダクトを提供する前に 適性判断が必要です アップグレードやダウングレードを 行う場合も同様です 無料トライアルやオファーに対する ユーザの適性に応じて― プロダクトの提供方法や時期が変わります

App Storeには無料トライアルなどに対し 適性基準がありますが― オファーに対する適性は ビジネスニーズに応じて調整可能です また ユーザへの通知は― 終了日の通知以外にも大いに役立てられます サービスの利用状況に応じて 個々のニーズに合った― 宣伝や課金に関する通知を送れるのです このエンタイトルメントの定義を 考慮しながら サブスクリプションに関する あらゆるデータを利用し サーバ側のロジックを組み立てます ではエンタイトルメントエンジンから 説明します ユーザのサービスにおける権限を 取得したデータから算出します エンジンはユーザの利用サービスや 課金状況における変更をサポートします

具体的には レシートデータや アプリケーションのインサイトを活用して 正確なエンタイトルメント情報を算出します

それでは実際に サブスクリプションの開発者が― エンジンをコード化する方法を説明します Node.jsの本セッションの記事の中で サンプルコードを提供しています エンタイトルメントエンジンの構築を 始めるのに役立つはずです それでは エンジンを構築する 各ステップを説明していきます

これはエンジンを使ったプロセスを さらに詳しく示した図です レシートやサーバ通知など サブスクリプションのデータをエンジンに送り JSONペイロードを作成します それを権限の付与やデータベース更新に使います

アプリケーションのレシートは 実績データを調べるソースです 最初のステップは レシートの正当性を検証することです

App Storeの verifyReceiptエンドポイントから― 最新のレシート情報を取り込みます 必ず最新情報に基づいた エンタイトルメントの決定を行ってください

またレシートから得られない サブスクライバーの特徴や関連データを― 我々のシステムから取り込めます

複数のアプリケーションをまたぐ サブスクリプションの場合 レシートに含まれない サブスクライバーのステータスも加味して 不要なロックや サブスクリプションの重複購入を防ぎます 次に 集めた関連データを統合します

エンジンの原動力となるフェーズです 手に入れた情報をまとめて 実用的なインサイトへ変換します

最新のレシート情報の配列や 待機中の更新情報の配列など― 情報はレシート内や複数の配列に 散在しています そこでエンタイトルメントに関する フィールドを徹底的に調べます

データをロジックでイテレートし 最終的なレスポンスに含む データ･オブジェクトを作成します ここでキー情報を設定し アタッチすることで― ユーザのサービスの利用状況を 判断できます 例えば サブスクリプションのプロダクトと 必須情報からレスポンスを生成します どんなサブスクリプションサービスでも 価値のあるキーデータは― プロダクトIDやトライアルの有無 終了日などです コードについては また後で触れます

次にエンタイトルメントのプロセスに 影響を与える― レシート外のインサイトを追加します 例えば視聴時間や 興味がありそうなイベント情報などです これでデータの落とし込みが完了し サブスクライバーごとのコホートを作成できます サブスクリプションのあらゆるステートを 対象としたコホートを作成すべきです ステートごとのコホートを作成することで― サービスの利用状況に基づいた オリジナルの体験を提供できます

マイケルが列挙した各ステートに― サブスクライバーを識別していきましょう

この例では簡単に各ステートに 重複しない値を割り振ります サブスクリプションのニーズに合わせて 調整してください “サブスクリプションのサブステート” プロダクトの独自性を高めるために― サブステートに対しても 同様に値を割り振ります

この２つを組み合わせることで 幅広いコホートを作成できます 簡単なアプローチとしては 正の値はアクセスが許可された状態を示し 負の値はプロダクトID保有者に サービスを提供していない状態を表します

正と負の値で汎用アクセスを 定義づけていますが― 固有のコホートを活用して エンタイトルメントのプロセスを強化できます

値を組み合わせれば― プロダクトのステートを示すコードが完成します この値をクライアントに送ったり サーバで保管します コードが正の値の場合 ロックを解除するシグナルとなります また この値を カスタムアクションとして使えます 固有のインサイトが― 無料トライアル中の自動更新を無効にしている サブスクライバーを示すからです

作成したコホートを使って エンタイトルメント情報を決定していきます ここで重要なのは― 固有のコホートに適した追加データを アタッチすることです

すると それぞれのコホートに応じた ビジネスアクションを起こせます 説明します

必要なキー情報を含む responseオブジェクトを作成し エンタイトルメントに関する値を持つキーを 読み込みました この結果とステートメントを用いれば― 複合的なステートを対象とした 権限の付与が可能です

自動更新を無効にされた場合の 利用者の維持の例です

エンタイトルメントコードの“4.0”と プロダクトを含むステートメントの場合に― 契約更新の通知や新たなオファーを送付できます 課金の猶予期間のステートは 継続したサービス利用が可能です しかし固有のコードを使って さらなるアクションを対象とした ロジックを追加すれば― ユーザに課金情報の更新を促し 不本意な解約を防ぐことができます 猶予期間と支払い回収の試みは異なりますが アクセスを制限しながら 課金情報を更新させる目的は同じです

この例ではエンタイトルメント情報を用いて サービスを解約したユーザに オファーを提示できます 忠実なサブスクライバーに対しても コードと更新回数やグループIDを用いて 契約のアップグレードを提案できます

これで必要なエンタイトルメント情報が すべてそろいました

このデータをデータベース更新に生かし ユーザのステートと正確に同期させます ユーザのデバイスが エンタイトルメント情報を求めた場合 算出データを安全にデバイスに送ります JSON Web Signatureを付けると データ送信元を証明できます エンタイトルメントエンジンの ロジックの続いて― システムのアーキテクチャ内での エンジンの活用法を説明します

必須条件を確認しましょう

高度なエンタイトルメントエンジンは 変更が生じた瞬間に― 最新のエンタイトルメント情報を算出し 対応します あらゆるステートで この機能を有効にすることで― 確実にサブスクライバーに 適した権限を与えることができます

正確な対応はミッションであり このプロセスは不測の事態に対する 安全装置でもあります

最後に我々が構築するエンジンは― 新たに加わる機能や 将来的なビジネス状況の変化にも対応できます

サブスクリプション状況を認証し 適した権限を与える― エンジンの構築方法を説明しました これはサーバアーキテクチャ内で エンジンを最大限に活用する概要です

サブスクリプション事業を始めたばかりでも 有効なアプローチです

通知やストレージを使わない 基本的な実装に対しても― 我々がサポートできる サブスクリプション機能は多くあります サブスクリプションオファーもそうです サーバ側でエンジンを走らせれば ロジックのエラー修正や更新が可能で レシートデータを検証した後 すぐにロジックを展開できます クライアント側の更新に頼らず― インバウンドリクエストにより 適切なアクセス権を与えられます ただしリクエストで処理するレシートを 送信するデバイスは必要です レシートデータを保管しなければ― ウェブやプラットフォームの サポートはできません しかし この方法なら ストレージに問題がある場合や― App Storeの通知が処理できない場合に サービスの開始や限定的運用ができます イテレートも簡単にできます 永続ストレージを追加して 最終的なエンタイトルメント情報と レシートデータを保管しておけば― ウェブやプラットフォーム外を経由して アクセスを許可できます その際 App Storeのサーバ通知を処理する エンドポイントを追加すべきです そうすれば verifyReceiptエンドポイントで ポーリングするよりも― ステータスの変更が瞬時に分かります さまざまな障害へのサポート方法もあります 通知が処理されない場合は― 永続ストレージ内のレシートデータにより 正確性を維持します 保管データに誤りがあっても ロジックの更新は可能です その場合 ストレージの問題が解決するまで― データを直接 エンジンに送り 権限の付与を行います このセッションは いかがでしたか？ 応答性の高いエンタイトルメントの プロセスを構築すれば― 複雑なサブスクライバー体験にも 個々に対応できます そして より充実したサポートを提供できます

最後までご視聴ありがとうございました