アプリ内課金のためのApp Store Server APIの詳細

こんにちは 「アプリ内課金のための App Store Server APIの詳細」へようこそ App Store Serverチームのエンジニア Alexです 同じく App Store Serverチームのエンジニア Ianです 本セッションでは App Store Server APIを使った アプリ内課金の仕組みについて お話しします Server APIのユースケースを いくつかご紹介し オンデバイスのコードだけでは 実現できないことが どのように可能になるかをお見せします 私のパートでは App Store Server APIの 新機能について詳しく説明します すでにサーバをお持ちの方にも これから始める方にも 興味深い内容が盛りだくさんです 内容が多岐にわたるため さっそく始めましょう アプリデベロッパであれば App Store Connectは アプリの設定や製品を構成するために 使用することをご存知かと思います また StoreKitを使って アプリ内課金機能をアプリ内に 追加できることもおなじみでしょう これらの2つの技術は不可欠ですが もう1つ アプリ内課金をレベルアップさせるために 利用できるものがあります それがApp Store Serverです

App Store Serverには 3つの重要な要素があります まずはApp Store Server APIです App Store Server APIを使うと サーバから App Store Serverに リクエストを送信できます また クエリを実行して トランザクションの情報を取得できます さらに それらのトランザクションに 関連する情報を送信することもできます 例えば サブスクリプションの更新日を 延長するなどができます

App Store Server APIの エンドポイントのうち4つは トランザクションに関する情報を 取得するためのものです 例えば 顧客のトランザクション履歴を 取得できます さらに 5つのエンドポイントが 返金と顧客満足度に関連しており 例えば 返金決定プロセスに関与するために 消費に関する情報を送信できます 最後の3つのエンドポイントは App Storeサーバ通知用です これらのエンドポイントにより テスト通知のトリガや 通知履歴の閲覧ができます

全部で12個の これらのエンドポイントは Verify Receiptエンドポイントが 2023年に廃止されたことにより これに置き換わり さらに機能が拡張されました 以上 App Storeを呼び出すための エンドポイントについて説明しました App Storeサーバ通知を使えば App Storeがサーバを呼び出せます これにより App Storeは トランザクションの更新について 積極的にサーバに通知することができます

App Storeはサブスクリプションの ライフサイクル内の アップグレードや更新などのイベントを サーバに通知できます 通知は返金ライフサイクルも カバーしており 返金の発生時に通知できます

次は App Store Serverライブラリの説明です App Store Serverライブラリは App Store Server APIと App Storeサーバ通知を 利用するための基盤です App Store Serverライブラリは App Store Serverとの統合の シンプル化を目的としています

App Store Server APIの クライアントを提供し これらのエンドポイントの使用を これまで以上に容易化します

署名付きデータの検証機能が 組み込まれており デバイスApp Store Server API またはApp Storeサーバ通知の データの検証とデコードを可能にします また ライブラリを使用すると 旧形式のレシートから トランザクション情報を抽出できます これにより 非推奨になった Verify Receiptエンドポイントと 従来のStoreKitクライアントの フレームワークから移行できます

さらに プロモーションオファーの署名を 簡単に作成する方法も提供します

昨年Appleは 本番環境対応のバージョン1.0を Java Python Node.js Swiftの 4つの言語でリリースしました App Store Serverライブラリは これらの言語で App Store Server APIを使用する場合の 推奨方法になりました ライブラリの利用を開始するには 各言語に適したパッケージマネージャーから ダウンロードします

このライブラリのもう1つの強みは オープンソースであることです フィードバックやプル要求を ぜひご提出ください GitHubで参加し 利用を始めましょう ライブラリに貢献する デベロッパコミュニティにも ぜひご参加ください

App Store Serverライブラリの使用方法と セットアップに関する詳細は WWDC23のセッション「Meet the App Store Server Library」をご視聴ください 以上 App Store Serverの基礎について 説明しました 次に 本セッションの 3つの主要なトピックに移ります 各トピックでベストプラクティスを共有し その後 Ianから新機能をご紹介します 私が購入ライフサイクルについて説明した後 App Storeサーバ通知の新機能を Ianが説明します 次に コンテンツの配信と このワークフローに対するサーバ側の アプローチについて解説します その後 Ianがこの分野の 機能強化について説明します 最後に サブスクリプションとオファーの 分野における新たな進展を説明し Ianが これらのトランザクションに 利用できる新しいフィールドをご紹介します まずは購入ライフサイクルの説明です

アプリ内課金には様々な種類があるので 簡単に概要を説明します 非消耗型製品は 一度購入すれば 生涯を通して利用できる製品です 消耗型製品は その名の通り使い切ることができ 顧客は必要に応じ再購入できます 消耗型製品の例は ゲーム内アイテムの購入に使用できる 100個の宝石のパックです

非自動更新サブスクリプションは 消耗型製品に似ています 期間が終了すると顧客が 再購入することができるものです 自動更新サブスクリプションは 標準的なサブスクリプションであり スケジュールに基づき更新されます 更新や解約の際に 再購入することもできます 以上がアプリ内課金の種類の概要です 次に 購入ライフサイクルについて 詳しく説明するために 消耗型製品の購入例を見ていきます ワークフローは 顧客がアプリ内で 消耗型製品を購入する時に始まります

顧客のデバイスが 署名付きトランザクションを受信し アプリはそれを デベロッパのサーバに送信して トランザクションを検証し コンテンツを提供します さらに App Store Serverは 同じ署名付きトランザクションについて ONE_TIME_CHARGE通知を デベロッパのサーバに送信します 購入のライフサイクルは 通常はここで終了し 顧客は 次の消耗型製品を 購入できるようになります しかし 顧客が購入に対して 返金を要求した場合はどうなるでしょうか

この段階で App Store Serverは サーバに対し CONSUMPTION_REQUEST通知を 送信することができます これは 顧客の製品使用に関する情報の 提供を求めるものです この情報を提供するためには Send Consumption Information エンドポイントを呼び出します 送信された情報は Appleの返金決定プロセスにおいて 考慮されます

Appleが返金を承認または拒否すると REFUND通知か REFUND_DECLINED通知が送信され デベロッパのサーバに結果が通知されます

このワークフローの後半部分は 最初は複雑に感じられがちですが App Store Serverライブラリが解決します App Store Serverライブラリを使用して 消費リクエストワークフローを 実装する方法の例をお見せします この例ではJavaを使用していますが このライブラリは NodeやPythonのほか Swift on Serverでも利用できます

まず SignedDataVerifierと AppStoreServerAPIClientを作成します ここでは引数は省略しています 次に 最近通知を受け取っており 署名付きのペイロードが文字列として signedNotification変数に 保存されていると想定します ほかの通知と同様に SignedDataVerifierを使用して ペイロードを検証およびデコードし デコードされたオブジェクトを notification変数に保存します

この場合 NotificationTypeが CONSUMPTION_REQUESTであるかを確認し そうであれば その型に適したロジックを実行します

通知のデータオブジェクトから signedTransactionInfoを取り出し Stringに保存します その後 SignedDataVerifierを使用して 署名付きトランザクションを 抽出して検証し transactionIdを変数に保存します 次は エンドポイントに送信する ConsumptionRequestオブジェクトの構築です このオブジェクトの適切な値を 決定する方法は サーバの実装と 実行するトランザクションによって異なります

この例で記述したサンプルの値は サンプルのコンテンツが顧客に提供され そのコンテンツがAppleプラットフォームで 消費されたことを示します

ConsumptionRequestオブジェクトを 構築したら 先ほど作成したapiClientを使用して Send Consumption Information エンドポイントを呼び出します transactionIdと consumptionRequestを渡します 例外がスローされなければ データは正常に送信されています 以上が App Store Serverライブラリを使った 消費リクエストワークフローの 処理方法です では次に 新機能のアップデートを 説明してもらえますか わかりました 購入と返金処理を強化する 素晴らしい新機能があります 最初のアップデートは 消耗型製品の購入フローのところで Alexが紹介した ONE_TIME_CHARGE通知です この新しい通知タイプは 一度きりの アプリ内課金に対して送信されます これにより アプリで 消耗型および非消耗型の製品や 非自動更新サブスクリプションが 購入された時に サーバが通知を受け取ることができます

この通知は既存の通知タイプ すなわち 新規購入や 自動更新サブスクリプションの更新の 通知に加えて送信されます これらとONE_TIME_CHARGE通知を 併用することで 顧客がアプリ内で行うすべての購入を サーバが常に把握している状態を 維持できます

この新しい通知は サンドボックス環境で すでに利用可能であり 今すぐ テストを開始できます

今年後半には 本番環境でも利用可能になります

これは デコードされた ONE_TIME_CHARGE通知の例です notificationTypeは ONE_TIME_CHARGEです

デコードされたトランザクション情報には アプリ内課金の関連データが すべて含まれています

この例では 顧客が消耗型製品の 100個の宝石のパックを購入しています 購入時にappAccountTokenが 提供されている場合は この行に表示されます この値を使用すれば サーバ上の どの顧客アカウントが購入を行ったかを 把握できます これにより 通知に含まれるデータだけを使用して 購入されたコンテンツを すぐに顧客に提供できます これで App Store Server APIの呼び出しも デバイスからの呼び出しの待機も 不要になります 購入ライフサイクルの重要な部分の一つに 返金があります Alexが説明したように CONSUMPTION_REQUEST通知は 消耗型製品へのアプリ内課金に対し 返金リクエストが行われた際に送信されます これに Send Consumption Information エンドポイント呼び出しで応答できることは Alexが先述した通りですが アプリで自動更新サブスクリプションを 提供している場合はどうでしょうか Appleでは デベロッパのみなさんの 返金決定プロセスへの関与を促進しており 自動更新サブスクリプションに対する 返金要求にも CONSUMPTION_REQUEST通知を 送信するようにしました

さらに 新しいフィールドである consumptionRequestReasonが すべてのCONSUMPTION_REQUEST通知に 含まれるようになりました このフィールドは 顧客の申告に基づく アプリ内課金の返金リクエストの 理由を示します

これは 自動更新サブスクリプションに対する CONSUMPTION_REQUEST通知の例です

新しいフィールド consumptionRequestReasonは 顧客が返金をリクエストした 理由を示します この例では 顧客が 意図せず購入したと示されています

また CONSUMPTION_REQUEST通知に対する 応答プロセスにもアップデートがあります Send Consumption Informationを 呼び出すと 購入者の製品使用に関する コンテキスト情報が提供されます しかしAppleは 意思決定プロセスに関しても デベロッパのより強い関与を望んでいます そのため Send Consumption Informationを 呼び出す際 返金を承認するか または拒否するかの希望を デベロッパが送信できるようにしました

CONSUMPTION_REQUEST通知の 新しいフィールドである consumptionRequestReasonを使用して この希望を指定します 送信された希望とその他の消費データは 返金の最終判断プロセスで考慮されます では Alexのコードを元に App Store Serverライブラリと組み合わせた これらの新機能の使用方法を解説します 通知をデコードして トランザクション情報を取得するコードには 変更はありませんが 新しいConsumptionRequestReasonが 通知データに含まれるようになりました

返金を承認するか拒否するかの 意見を表明したい場合 自身の独自のロジックに従って 意見を決定できます 例として ここでカスタムメソッド determineRefundPreferenceを 呼び出しています このようなメソッドでは 消費リクエストの理由やこのようなメソッドでは およびその他のデータを 考慮する場合もあります

最後に ConsumptionRequestオブジェクトで refundPreferenceを設定し 先ほどと同様に それをApp Store Serverに送信します これで完了です App Store Serverライブラリを使用すると 新機能の統合は ほんの数行のコードで済みます

消費に関する情報を送信すれば 返金プロセスで より大きな役割を果たすことができます しかし デベロッパが果たすべき 最大の役割は シームレスな購入体験の提供です 返金リクエストを 発生させないようにすることが重要です そのための一つの方法は アプリのユーザーが 購入したコンテンツを すぐに利用できるようにすることです この点についてアドバイスはありますか いい質問ですね では コンテンツ配信に関する ベストプラクティスをご紹介します まず サーバを利用する コンテンツ配信ワークフローの流れを 理解することが重要です すべては 顧客による アプリ内製品の購入から始まります その後 アプリは 署名付きのトランザクション情報を サーバに送信します この時点で ユーザーに 製品へのアクセス権が付与されます 例えば 消耗型製品の場合 サーバ上でユーザーのゲーム内通貨の残高を 更新します デバイス上のアプリにシグナルが送信され トランザクションのコンテンツが 付与された旨が通知されます それを受け アプリはトランザクションを 完了としてマークします トランザクションを 完了としてマークすることで コンテンツが付与済みであり 顧客は次の購入を行えることが App Storeに伝達されます

コンテンツ付与のステップに 注目してみましょう サーバでのコンテンツ付与に関する ベストプラクティスがあります サーバは完全に デベロッパの管理下にあるため サーバは 顧客がアクセスできる 信頼できる唯一の情報源であるべきです 顧客がシステム内に所有する コンテンツに関して デバイスが情報源となるのは不適切です 未署名のデータは デバイスやサーバでの 保存時や移動時に変更の可能性があるためです さらに コンテンツ付与の責務は サーバのみが有するため どのコンテンツが 付与されたかについても サーバが信頼できる情報源であるべきです サーバがオンデバイスのトランザクションの コンテンツを付与したら アプリは完了としてマークし App Store Serverにシグナルを送ります しかし トランザクションの 完了ステータスを コンテンツが配信された証拠と 見なしてはいけません コンテンツの付与の重複や漏れの 原因となる可能性があります

署名付きトランザクションの 取得場所に関わらず コンテンツを付与する前に 署名を検証しましょう 先述の通り App Store Serverライブラリを 使えばこの検証は簡単です すべてのコンテンツを付与する責務は サーバにあるため 最高の顧客体験を提供するには 新規または更新のトランザクションを 迅速に検出することが重要です サーバにトランザクションを漏れなく 検出させるための方法は多数あります デバイスからサーバに 新規および更新の トランザクションをすべて送信しましょう アプリにおいて App Storeサーバ通知の バージョン2を有効化しましょう これにより すべての購入が通知され 顧客がアプリを使用していない間に 発生したと思われる更新なども カバーされます 顧客による購入を デバイスに依存せずに 把握できるようになります StoreKitを使用して 購入時にサーバが生成する appAccountTokenを設定しましょう 購入に対する App Storeサーバ通知を 受け取った際に この値を使用すれば 通知内のトランザクションデータを デバイスを必要とせずに 顧客にリンクできます または 購入を見逃したと思われる場合に App Store Server APIの Get Transaction Historyエンドポイントを 使用して 顧客の履歴を取得し 見逃している更新トランザクションがないか 確認できます

この例で示しているのは App Store Serverライブラリを使用して getTransactionHistoryエンドポイントを 呼び出す方法です ここでは 先ほどと同様に apiClientを使用します また 顧客に属する transactionIdがあると想定します 顧客の任意のtransactionIdを使用して その顧客のすべての トランザクション履歴を取得できます

次に リクエストを構築します このエンドポイントには 幅広いフィルタとソートを適用できます ここでは 最終更新日で 昇順に並べ替えたトランザクションを 指定します エンドポイントからの応答を保持する HistoryResponse変数と 署名付きトランザクションを保存するListと リビジョンを保持するStringを作成します 初めてこのユーザーの エンドポイントを呼び出すので revisionはnullのはずです このユーザーの履歴を 以前にも取得している場合 revisionに 最新のHistoryResponseの値を指定し 新たに更新された トランザクションのみを取得できます

リクエストを行うには transactionIdと 存在する場合 以前のリクエストから 返されたrevisionと requestオブジェクトを渡します 署名付きのすべてのトランザクションを 応答から出力リストに追加します 次に revision変数を更新して 次のトランザクションセットを 取得する準備をします

このエンドポイントは ページ分割されているため 応答のHasMoreフィールドがfalseになり 応答にトランザクションがなくなるまで エンドポイントを 呼び出すコードをループします

ループが終了すると 顧客のすべての トランザクションのリストが完成します これで 先に見たように SignedDataVerifierによる デコードが可能になります 次に リストを確認して 新規と更新のトランザクションをチェックし コンテンツを配信するなどの 適切なアクションを実行します 以上が App Store Serverライブラリとともに Get Transaction Historyを使う方法です 素晴らしいですね つまり 実際にそのエンドポイントで 全トランザクションを取得できるのですか 正確にはそうではありません このエンドポイントが返す 消耗型製品の トランザクションは 返金や取り消しの対象か デバイスで未完了のもののみです しかしこれは エンドポイントが最初に 導入されて以来変わっていません アップデートが必要なようですね Get Transaction Historyの 新しいバージョンをこのたびリリースします この新しいバージョン2は 個々の顧客の すべてのトランザクションを返します 製品タイプや払い戻しステータス 完了ステータスは問いません これにより 顧客のトランザクションの 全履歴が提供され 新しいユースケースが可能になります 例えば 顧客が自身の 全購入履歴を確認できるようにするとか 個々の顧客の サーバ側の購入エントリを更新するなどの ユースケースが可能です サーバ上の消費可能な残高を 監査して すべての支出を 最新の状態に維持することもできます

新しいバージョンの Get Transaction Historyは 元のバージョンと同じデータに加えて 追加のデータも返します V2のリリースにより 旧バージョンは現在非推奨になっています

新しいエンドポイントは旧バージョンと 基本的には類似しているので 移行は簡単です URLパスのバージョンをV2に更新し 消費可能な完了済みトランザクションに対し サーバを準備すれば すぐに移行できます App Store Serverライブラリと 併用すれば 新しいバージョンの Get Transaction Historyは 簡単に使用できます

Alexのコードを見直すと エンドポイントの 呼び出しのみが変更されています

新しいバージョンのパラメータを使えば 呼び出すエンドポイントを選択できます

以前と同じようにトランザクションの リストを応答から生成できますが 署名付きトランザクションのリストには すべての消耗型製品が 含まれるようになります

以上がトランザクション履歴に関する 最新情報です しかし トランザクション履歴が 1つもないと 意味がありませんよね トランザクションを増やす一つの方法は アプリで自動更新サブスクリプションを 提供することです 新しい登録者を引きつけ 既存の登録者を維持するには 継続的な努力が必要ですが それだけの価値があります サブスクリプションを提供する方法を 教えてもらえますか わかりました サブスクリプションとオファーについて 私からご説明します オファーを利用して サブスクリプション製品に顧客を引きつけ 維持する方法もご紹介します まずは 自動更新サブスクリプションで 利用できる 3つの決済モードについて説明します

オファーを作成する際に設定できる 様々な決済モードがあります 顧客への無料トライアルの提供は 有効なオプションの1つです 無料トライアルは 顧客に 支払いを決める前に まずサービスを試すことを促す 優れた手段です または 都度払いのモデルで 割引価格を提供することもできます 例えば 2か月間の半額キャンペーンなどです

最後に 顧客に 前払いオファーを提供することもできます これは 一定期間分の料金を 割引価格で前払いできるオファーです 各種の決済モードについて説明しました 次に 様々なオファーの種類について 説明します まずはお試しオファーです このオファーは サブスクリプショングループの 新規登録者に対して提供されます オファーの利用資格と配信は Appleが管理し 顧客が以前に当該のオファーを 利用済みでないことをAppleが確認します 次はオファーコードの説明です 配布されたオファーコードを アプリ内で引き換えると 顧客はオファーを利用できます Appleは コードが所定の回数のみ 引き換えられるように管理しますが コード配布対象の顧客は デベロッパが決めます

次はプロモーションオファーです これは 既存顧客の維持や 解約した登録者の再登録を 目的として使用できるオファーです これらはデバイス上で提供され 利用資格の判定は デベロッパに全面的に委ねられます

最後に説明するのは 新しいウィンバックオファーです これは 解約した登録者に対して表示され 再登録を促すものです

この新しいオファータイプの詳細については WWDC24のセッション「Implement App Store Offers」をご覧ください

以上のうち プロモーションオファーが 最もサーバロジックに依存しています 配信に署名が必要であり 利用資格の判定は デベロッパのロジックに基づくためです プロモーションオファーの仕組みを 詳しく確認しましょう

これは プロモーションオファーの ワークフローの例です サブスクリプションの自動更新を 無効にしている 既存顧客がいると想定してください この顧客のサブスクリプションは まもなく解約されます

App Store Serverは その旨をデベロッパに 通知しますが 通知のタイプは DID_CHANGE_RENEWAL_STATUSで サブタイプはAUTO_RENEW_DISABLEDです この時点で 顧客に対し サブスクリプションの継続を促すために プロモーションオファーを提供できます

デベロッパが顧客に 特定のオファーを 利用させたいと判断したら サーバにおいて プロモーションオファーの署名を作成し 顧客のデバイスに送信する必要があります アプリは署名をStoreKitに提供し 顧客にプロモーション価格で 製品を購入するオプションを提示します

この引き換えが行われた場合 SUBSCRIBED通知か OFFER_REDEEMED通知で デベロッパに知らされます

このワークフローで 最も複雑な部分の一つは プロモーションオファーの署名の作成です しかし App Store Serverライブラリの リリースにより この課題は解消されました App Store Serverライブラリによる 署名作成プロセスについて説明します

これは プロモーションオファーの 署名を作成するコードです

PromotionalOfferSignatureCreatorの インスタンス化が最初の手順です

アプリのプライベートキーと keyIdおよびbundleIdを渡します これらの値はプロモーションオファーの 署名に使用され プロモーションオファーが デベロッパ側の同意なしに 引き換えられないようにします

次に productIdおよびオファーのIDと 顧客のapp_account_tokenを指定します nonceを作成し 現在のタイムスタンプを記録します nonceは App Storeがオファーを 複数回引き換えることを 防ぐためのものです

これらのパラメータを signatureCreatorに渡し Base64にエンコードされた 署名を受け取ります これは後ほど 顧客のデバイスに送信します 以上がApp Store Serverライブラリにより プロモーションオファーに署名する方法です しかし オファーの対象者は どうやって決めればよいでしょうか これに関連するアップデートはありますか はい プロモーションオファーでは 作成するオファーの種類や 提供する対象など 様々な事項を考慮する必要があります Appleでは サブスクリプションと オファーに関する情報を より多く提供できるよう努めることで デベロッパを支援し ビジネスと 顧客のためのより良い判断を可能にしています

その取り組みの一環として 2023年後半に サーバのAPIとデバイス上のStoreKitで 提供される トランザクションデータの 新しいフィールドを追加しました 新しいpriceとcurrencyフィールドは 顧客が購入した時点の 表示価格と通貨を表します 適用されるオファーも反映されます これらのフィールドを使用する際は App Store Connectのレポートが 財務と会計のための 信頼できる 情報源になることに留意しましょう 購入にオファーが適用される場合 新しいofferDiscountTypeフィールドは そのオファーの決済モードを示します FREE_TRIAL、PAY_UP_FRONTか PAY_AS_YOU_GOのいずれかです

これは デコードされた サブスクリプション購入の トランザクション情報の例です 新しいpriceとcurrencyのフィールドは 購入時の製品の表示価格を示しています 価格は通貨のミリ単位で表示されます この例では 4990は 米ドルで4ドル99セントを示しています

既存のフィールドである offerIdentifierとofferTypeを参照し ユーザーが引き換えたオファーと そのタイプを確認できます 新しいofferDiscountTypeフィールドを見ると オファーがPAY_UP_FRONTであるとわかります

これらのフィールドは 様々な時点で アプリ内で行われた購入の 価格ポイントを理解する上で 有用な基準点になります これで 顧客の トランザクション履歴を確認し 製品価格が変更された場合も含め 支払われた価格を 把握できるようになりました

サブスクリプション購入での 新しいフィールドの 機能を例で確認します 最初の期間のトランザクション情報を 見てみると この購入にPAY_UP_FRONTオファーが 適用されていることがわかります トランザクションの表示価格は 4.99米ドルです

2か月のプロモーション期間終了時 サブスクリプションが 自動更新されます 顧客は現在 通常価格の9.99米ドルを支払っています

APIは 各顧客のサブスクリプションの 更新情報も提供するため 次回の自動更新時に適用される 条件を把握できます

更新情報にも 新しいフィールドが3つ追加されました renewalPrice、currency offerDiscountTypeです これらの新しいフィールドを利用することで 次回のサブスクリプション更新時の 想定表示価格と オファーの決済モードを把握できます

これは デコードされた サブスクリプションの更新情報の例です

renewalPriceとcurrencyのフィールドは App Store Serverが次回の更新時に 購入価格として8.99米ドルが表示されると 想定していることを表します

既存のフィールドである offerIdentifierとofferTypeは App Store Serverで 次回更新時の購入に適用される オファーとオファータイプを示しています

新しいofferDiscountTypeフィールドは App Store Serverが次回更新時の購入に PAY_AS_YOU_GOオファーが適用されると 想定していることを示しています

前払いオファーの例に戻り これらのフィールドの機能を確認しましょう 初回プロモーションの期間中 更新情報には プロモーション期間終了後の 通常期間に関する情報が含まれます 更新時には 9.99米ドルの 通常価格が適用されることがわかります

最初の更新後は 更新情報には 次回の更新時に適用される 条件が反映されます 現在 通常のサブスクリプション価格が 適用されているため フィールドは変更されません

次に 都度払いオファーの例を見てみましょう 初回のプロモーション期間中 更新情報には最初の更新時に想定される 購入条件が反映されます offerDiscountTypeフィールドは 次の購入では引き続き 都度払いオファーが 適用されることを示しています 更新価格は2.99米ドルで オファーの割引が適用されています

最初の更新後 更新情報には 2回目の更新に関する情報が含まれます renewalPriceは サブスクリプションが 通常価格の 4.99米ドルに戻ることを示しています

2回目の更新後も 更新情報は変更されません ターゲットを絞った プロモーションオファーは サブスクリプション製品に顧客を引きつけ 維持するための強力なツールです App Store Server APIにより 取得できるデータを利用すれば これらのプロモーションオファーの サーバ側の資格要件ロジックを 各デベロッパの固有の ニーズに基づき調整できます 例えば ある顧客にオファーを宣伝する前に そのアプリで以前にオファーを引き換えた 履歴がないか確認できます または 購入の履歴が 低価格帯の購入のみの顧客に 高価格帯の製品を一定期間 割引価格で試すことができる オファーを作成して提案できます

新しいフィールドをオファー戦略の構築に お役立ていただければ幸いです では 本セッションでご紹介した 新機能を簡単に振り返ります 新しいONE_TIME_CHARGE通知は 一度限りの購入を通知します これを利用すれば アプリ内で行われた すべてのアプリ内課金を App Storeサーバ通知を使って追跡できます

CONSUMPTION_REQUEST通知は 消耗型製品に加えて 自動更新サブスクリプションの 返金リクエストも通知可能になりました これらの通知には 新しいフィールド consumptionRequestReasonが含まれます

このフィールドおよび その他のサーバ側のデータを使用して Send Consumption Information エンドポイントを呼び出す際に 返金を許可するかどうかの意見を デベロッパが表明できます

新しくアップデートされた Get Transaction Historyエンドポイントは 個々の顧客がアプリ内で行った すべての購入のトランザクションを返します これにより オンデマンドで 包括的なデータを取得できます

最後に 新しいフィールドである price currency offerDiscountTypeなどを 利用すれば サブスクリプションと トランザクションをより詳細に分析できます 私からは以上です 最後に補足などありますか 本セッションでご紹介した 機能に関するフィードバックや App Store Serverの未来に関する ご要望をお寄せください App Store Serverへの 機能リクエストやフィードバックは フィードバックアシスタントから ご送信ください 改めてお伝えしますが 本セッション全体を通して使用した App Store Serverライブラリは オープンソースです GitHubで参加して問題を報告したり 貢献することができます App Store Serverの詳細については 過去のセッションをぜひご覧ください ご視聴ありがとうございました