App内課金とサーバ間通知の使用

(音楽)

(拍手) おはようございます

“In-App Purchases and Using Server-to-Server Notifications”です 私はデイナ･デュボイスです

今日はまず― StoreKitの 追加機能についてお話しします

次にトリが― Server-to-Server Notificationsの ご紹介をします サブスクリプションの最新情報を― バックエンドで確認する方法の解説です

次にマンジートが 請求イベントについて説明します 加えて ユーザの維持と 非自発的解約の削減に 必要なこともお話しします

最初は―

StoreKitの変更点です まず登録オファーを紹介します

春に導入した すばらしい機能です 現在のユーザを 維持するだけでなく― ユーザの呼び戻しにも 活用できます ユーザに― 最大10件のオファーを 提供できる仕組みです 割引価格や無料サービスも 提供可能になります

対象者は アプリケーションから デベロッパが管理します 午後２時より登録オファーの セッションを行いますので― サブスクリプションをご利用の方は ぜひ ご参加ください

他の変更点は？ 新導入するSKStorefrontです ユーザが設定した App Storeのストアフロントを デベロッパに公開するものです

つまりSKStorefrontで ユーザのテリトリを把握し― 適切なコンテンツを 提供することが可能になります 仕組みはApp Storeと同じで― 設定されているストアフロントを APIが知らせてくれます

APIはデバイス固有の キャッシュ値を返しますが― 時間とともに変化する可能性があるため 注意が必要です まずコードをご覧ください

StoreKitにはSKPaymentQueueが 実装されています そこにキャッシュ値を返す― パラメータ取得機能を加えました .storefrontで呼び出します 可能性は低いですが nilになる可能性があります ご自分のアプリケーションで確認を

App Storeのストアフロント情報は ISO標準規格の国名コードで 判別される仕組みになっています ですので正確に マーケットを把握できます マーケットが分かれば ユーザに最適な コンテンツの提供が実現します ただし 値が変化する可能性も コードを詳しく見ていきましょう

製品IDを 使用するコードを例にします メタデータをフェッチして― SKProductsRequestを 呼び出すか決めるのです ここでは バックエンドから メタデータをフェッチし― “このストアフロントは有効か？”と 呼び出しています 製品IDをフェッチする前に shouldShowを呼び出し― trueなら SKProductsRequestのリストに そのIDが追加されます SKProductsRequestの前に 行いましょう その製品を提供しない場合― メタデータをフェッチしないほうが 効率的だからです

ただし 値が変化する場合も あります ユーザは アカウントを変えますし― 同じアカウントで 別のストアフロントを閲覧するでしょう 皆さんもストアフロントを切り替えて 自分のアプリケーションを― 確認されることと思います アプリケーション上に 最新情報が不可欠なのです SKPaymentの トランザクションオブザーバに― paymentQueueDidChange Storefrontを追加しました queue.storefrontで 新しい値を取得してください そして― テリトリによりコンテンツが 異なる場合もありますので― 新しいストアフロントのコンテンツを リロードします

shouldShowを呼び出し― 必要なら 製品情報を フェッチしてください 購入時に何が起きるでしょう？ 通常 コンテンツの売買は 問題なく処理されます しかし ストアフロントが デバイス上の設定と異なると paymentQueueにより 途中で変更されるかもしれません そのため paymentQueueで― メソッドを参照し 確認します 新しいストアフロントで 購買を許可するかの再確認です 再びshouldShowを呼び出します 製品IDと対応テリトリが リスト化されています trueなら購入を認めます ベストな体験をユーザに提供するため paymentQueueの間は― Server側の呼び出しを 避けるようにしましょう テリトリ別の販売対応情報は デバイスにキャッシュしましょう そうすれば 購入の可否を 迅速に回答できます 新しいストアフロントでは 購入ができない場合は― 理由を伝えなくてはいけません

どうするか？ updatedTransacionsを呼び出し― エラーコード storeProductNotAvailableを返します トランザクションの拒否が ユーザに通知されます ここでダイアログを出すか― 購入可能な別のコンテンツを 提示しましょう 警告やUIの更新などを すぐに行ってください

これがSKStorefrontです

続いて別の変更点をご紹介します

既にiOS 11や11.2 tvOS 11.2と― macOS 10.13.2で 予約注文を導入しました リリース前からアプリケーションに 注目を集められるため デベロッパに好評です 今年は watchOS 6.0に導入します Watch向けの アプリケーションに― この予約注文を使ってみては？ 今年は さらにもう１つ 予約注文で購入した アプリケーションのレシートに― 目印を付ける予定です そうすれば 予約注文したユーザに― “予約注文ありがとう”と メッセージを送れますよ 得意客限定で コンテンツの提供もできます レシートで 利用可能になる予定です すばらしいことにiOS 11や― iOS 12にも さかのぼれます

(拍手) StoreKitやApp内課金の 変更点をお話ししました 次はトリのプレゼンです Server-to-Server Notificationsの ご紹介をします トリ (拍手)

こんにちは　トリです Server-to-Server Notificationsの ご説明をします Server-to-Server Notificationsの 新機能と― サブスクリプションイベントを 効果的にモニタする方法を話します その前に考えてみましょう Server-to-Server Notificationsとは 何か？ どのような設定が必要なのか？

Server-to-Server Notificationsは POSTメソッドを使用して― JSON形式で送信する仕組みです statusUpdateNotificationsが 以前の名称です 最新のサブスクリプションイベントを 知るのに― 非常に便利な通知です ユーザを呼び戻すためにも 活用できます 受信先のエンドポイントを 決めたら― そのエンドポイントから HTTP状態コード 200を返します 受信完了を報告するためです もしコードを返さなければ― 最高３回まで通知を繰り返します

エンドポイントの決定後 App Store Connectでも設定をします App Informationページの― 登録ステータスURLに記入してください

App Store Connectでの 設定に加え― 通知を確実に受信するために セキュリティ設定も必要です 通信を行う際は App Transport Security つまりATSで行いましょう 要件があります 信頼された認証機関により 発行された証明書

TLSのバージョンは必ず 1.2であること 指定の共通鍵暗号を使用し 証明書は― SHA-256以上のハッシュ関数を使い 署名すること Server-to-Server Notificationsと その設定方法について 簡単にご説明しました 詳しい情報は デベロッパWebサイトに― アクセスしてください

具体的な説明に移ります Server-to-Server Notificationsに 新機能と新たなタイプを導入しました 新しく追加するにあたって― 通知されるレシートのフィールドに 注目しました これまで レシートが含むのは App内課金の最新情報のみでした でも すべてのサブスクリプションの 履歴が記載されれば― さらに有用になりますよね そこでUnified Receiptを追加します (拍手)

Unified Receiptには サブスクリプションの履歴が含まれます この履歴はレシート検証でしか 取得できませんでした 現在 レシートのフィールドは 最新のレシートとその情報の２つで 最新のApp内課金の情報を エンコード デコードしています そして この秋に追加される 新しいフィールドが― unified receiptです レシート検証の ほぼすべてを網羅しています

このフィールドを追加すれば― latest receiptと latest receipt infoは不要です しかし注意すべき点があります レシートは デバイス上のアプリケーションに ひもづいている訳ではありません 既存の購入履歴とは異なります このため 保存先は ローカルではなく Server上になります

Unified Receiptの内容を知るため フィールドを見てみましょう まずlatest receiptです これはエンコードされた unified receiptで レシート検証でご使用いただけます 次にlatest receipt info これはサブスクリプションの履歴で― ユーザの状態を 追跡することもできます そして pending renewal infoです 今後の更新に関する情報を含むため― ユーザのステータスが分かります また レシートのstatusと environmentも含まれる予定です 名称はレシート検証を反映しています パースのロジックの再利用で 移行は簡単にできるはずです ただし latest receipt infoは 直近100件に限られます それ以前の情報は レシート検証で取得してください では既存の４種類の通知を 見てみましょう INITIAL BUYと INTERACTIVE RENEWAL DID CHANGE RENEWAL PREF そして CANCELです さらに４つ追加します DID CHANGE RENEWAL STATUSと DID FAIL TO RENEW DID RECOVERに PRICE INCREASE CONSENTです

(拍手)

それぞれ どのような時に 送信されるのでしょうか DID CHANGE RENEWAL STATUSは 自動更新操作で送信されます Server-to-Server Notificationsを ご利用なら― 既に受信されているはずです DID FAIL TO RENEWは― サブスクリプションの最初の自動更新に 失敗すると送信されます この通知は秋にリリースします

DID FAIL TO RENEWと関連するのが DID RECOVERです DID RECOVERは再試行期間中の 請求の再開時に送信されます こちらも秋にリリースです DID FAIL TO RENEWの後 DID RECOVERを受信したら― 請求を再開したということです Server-to-Server Notificationsを 利用中の方は DID RECOVERとRENEWALの 類似性にお気づきでしょう

しばらくはDID RECOVERとRENEWALを 平行して通知しますが― 最終的にはDID RECOVERのみ 使用していきます 慣れてください

PRICE INCREASE CONSENTは― サブスクリプションの価格が 値上げされる場合に送信されます 価格へのユーザの同意が 必要となるためです これに伴う price increase effective dateは― ユーザが価格の値上げに 同意すべき期日を意味します この通知も秋にリリースです

以上が新しい Server-to-Server Notificationsです では これらの通知を 最大限に活用するためには― どのように処理すれば いいでしょう？ まず既存の通知を 見ていただきましょう INITIAL BUYと INTERACTIVE RENEWAL

DID CHANGE RENEWAL PREFと CANCELです それぞれの通知を 詳しく見てみましょう まずこれらの通知の JSONペイロードに― 共通するフィールドがあります オリジナルのトランザクションIDです サブスクリプション固有のIDとして 見なされるものです これを追跡し最初の購入と それ以後のイベントを連携します

さて 想像してみてください ジョンがサブスクリプションの 購入を考えています ジョンの行動に伴い どんな通知が送られるのか その流れを説明していきます

最初の通知はINITIAL BUYです ジョンが初めてサブスクリプションを 購入すると送信されます この通知を受け取ったら― ユーザのステータスを“アクティブ”や “利用中”にしてください コンテンツの提供も忘れずに この通知には ４つのフィールドがあります まず購入日です ユーザがサブスクリプションを購入した 日にちと時間を表します そしてオリジナルのトランザクションID 先に述べたとおり これは固有のIDを意味し― 追跡することで 最初の購入と 以降の通知を連携できます

そしてWeb注文明細行IDです 各サブスクリプション期間固有の IDを意味します 通知の受領後に レシート検証する際は― レシート検証の配列への エントリに連携します 最後に製品IDです 新たなユーザが 何を購入したかが分かります

しばらく経ってジョンは― アップグレードを考えます フォアグラウンドの更新として― INTERACTIVE RENEWALを通知します

アップグレードすれば 高度なサービスを受けるので― 元々のサービスの CANCELも通知されます ただし ユーザが解約後に サブスクリプションを再開した場合― INTERACTIVE RENEWALのみ 送られます

INTERACTIVE RENEWALにも ４つのフィールドがあります

まず購入日です ユーザがサブスクリプションを 再開した日時― またはアップグレードした 日時を意味します そしてオリジナルのトランザクションID 最初の購入と連携します

加えて Web注文明細行ID 各サブスクリプション期間固有の IDで― レシート検証の配列の エントリに連携します そして製品IDです 再開 またはアップグレードした 製品を示します この後 結局ジョンは ダウングレードしました この場合 DID CHANGE RENEWAL PREFを 送信します 通知を受領後 ユーザのステータスを “標準”にしてください この通知のフィールドを 見てみましょう

まず自動更新環境設定です ダウングレードは 次の更新日に行われるため 更新時に どの製品に 自動更新するかを管理します

そして 最初の購入に連携する― オリジナルのトランザクションIDです

その後 ジョンは窓口に電話して― サブスクリプションの解約をしました この時 CANCELを送ります 前述のとおり ユーザがアップグレードすると― CANCELとINTERACTIVE RENEWALを 受信します この場合のCANCELは 元々のサービスの解約です これらのフィールドを ご覧ください まずキャンセル日です これはユーザが いつ解約したかを意味します 最初の購入に連携する オリジナルのトランザクションIDです

製品IDで解約対象の製品が分かります

既存の通知を見てきましたが― 新しく追加した ４つの通知も見ていきましょう 先ほどの―

DID CHANGE RENEWAL STATUSと DID FAIL TO RENEW DID RECOVERに PRICE INCREASE CONSENTです 共通して存在するフィールドは オリジナルのトランザクションIDです 前述のとおり サブスクリプション固有のIDとなり― すべての通知と連携します

さて ジョンは― サブスクリプションの 自動更新を再びONにしました こういった場合の通知が DID CHANGE RENEWAL STATUSです 自動更新をOFFにした時も この通知を送信します この通知を受けたら― デベロッパ側で ユーザのステータスを更新できます ユーザの維持に この通知を活用することも可能です

４つのフィールドに ご注目ください まずユーザの自動更新ステータスの 変更日時を示す― 自動更新ステータス変更日です 次に 自動更新ステータス これは自動更新トグルを 意味します 自動更新ステータスが trueなら― 自動更新がONに戻っています 継続的な更新が予測できます ここでも オリジナルの トランザクションIDを 確認しましょう 製品IDからは どの製品の自動更新ステータスが 変更されたか分かります

自動更新期間に ジョンに請求を行ったら― 残念ながら失敗しました この場合の通知は DID FAIL TO RENEWです サービスを止めるなどの 対応をお考えください フィールド値を参照の上 ユーザのステータスを― “請求再試行”などにしてください 確認すべき最初のフィールドは 再試行フラグです 値は“０”か“１”で 積極的に支払いを促すか否かを示します 値が“１”の場合― 請求再試行期間に 支払いを促すことを意味します 最初の購入と連携する オリジナルのトランザクションIDです 次に有効期限です 自動更新を試みた日時と 失敗した日時を示します

幸い 請求再試行期間に― ジョンは支払いの問題を解決し 請求が再開されました この場合 DID RECOVERが通知されます 今後 RENEWALから 切り替えていく予定です この通知を受け取ったら サービスを再開しましょう ユーザのステータスを “アクティブ”や― “利用中”などに更新してください この通知のフィールドを 見ましょう まず購入日です 請求再開の日時を意味します オリジナルのトランザクションIDです 請求が再開された サブスクリプションが この固有のIDで分かります 最後に有効期限です 新たなサブスクリプション期間の 有効期限を意味します こうして 再び自動更新が開始されます

価格を値上げするケースを 考えてみましょう 週更新の場合は ７日前に値上げの確認をします 月更新なら10日前― 年更新なら30日前に行います 値上げが確認できたら― PRICE INCREASE CONSENTが 送信されます ユーザのステータスを “値上げ”などに更新してください App内のメッセージを 送ることもできますし― App Storeからも値上げ同意依頼の メールやプッシュ通知を送ります

見ていただきたいフィールドは― 価格の同意ステータスです ユーザが値上げに 同意したかを示します ただ 値上げを確認した直後に 通知を送るので― ほとんどの場合 値は“０”で 同意に至ってません

次に最初の購入と連携する オリジナルのトランザクションIDです 最後に有効期限です サブスクリプション期間の 有効期限を意味します 有効期限までに 同意に至る必要があります

Server-to-Server Notificationsの 変更点と― 通知の処理などを 説明しました 次はマンジートが サブスクリプションのライフサイクルと 解約削減について説明します (拍手)

App Storeコマースの マンジート･チャウラです 改良した新しい Server-to-Server Notificationsの― 活用法を 知っていただきたいと思います ユーザのステータスに 影響を及ぼす請求イベントを― 特定できるようになりますよ

サブスクリプションの ライフサイクルとは？

何よりもまず 新規顧客の獲得です 顧客に通常価格を適用する前に― お試し価格などを提供するでしょう

次にユーザの維持 そして 解約数の削減です

コンテンツを随時更新して ユーザの維持に努めます

このライフサイクルには 多くのユーザが経験する― 請求イベントがあります

請求イベント変更の確認時― レシート検証を 呼び出していませんか？

サブスクリプションビジネスが 成長する中― それは非効率です

Server-to-Server Notificationsの 改良に伴い― イベント変更をレシートに 依存する必要はありません 新しい Server-to-Server Notificationsで イベントを検知し 最適なユーザ体験を実現しましょう

まずは最初の購入です 最初に購入されると 一定期間 コンテンツの提供を行います

顧客が 初めて購入をすると トランザクションと連携した― レシートをStoreKitから受信します

この時 同時に― INITIAL BUYの通知を受信します この通知を使えば― 初めてサブスクリプションを 購入した人を特定できます

INITIAL BUYの通知を管理して― 同時に安全な接続法で Serverにレシートを送信します そしてレシートの内容を検証します

App Storeの応答から レシート内容を確認し ユーザデータベースを更新します 最新の購入情報にしてください

最終的に保存された通知を― レシート検証の応答と 連携することができます その際は オリジナルのトランザクションIDと Web注文明細行IDが必要です

更新可能な状態になれば― App Storeが 自動的に更新を行います ユーザがアプリケーションを 起動すると― 新しいトランザクションと レシートを受信します

そしてBASE64でエンコードした レシートをServerに送信します

ユーザが 別のプラットフォームにいて― アプリケーションを 起動しない場合もあるでしょう この場合も― 保存した最初の購入時のレシートを Serverに送ってください

そしてレシート検証し 更新用のトランザクションを確認します

返された応答で 最新更新を確認し― サブスクリプションのデータを基に 有効期限を更新します

更新が無事終了し サービス提供を続けます

Server-to-Server Notificationsは この間ありません トランザクションの確認のため 最初の購入時の情報を使い― レシート検証を行うのです

ではユーザが 標準のサービスを気に入り― アップグレードしたいケースを 考えてみましょう

この場合App Storeは CANCELを通知します

そのコンテンツには― App Storeが元のサブスクリプションを 解約した日が記されています

その後 INTERACTIVE RENEWALが Serverに送信されます

この通知を使いユーザデータベースを 更新してください こうすることで そのユーザが― アップグレードしたことに 気づけます

最後に ユーザがコンテンツを 使用できるようにしましょう

しかし その後― ユーザの気が変わり 解約を希望することもあります デバイス上で 自動更新を OFFにするのです

現状 レシートで最新の 更新ステータスを確認しているのでは？ 最新情報の取得をするために― レシート検証していませんか？

トリが紹介した 新しい通知を使えば― ステータス変更のためにレシート検証を 呼び出す必要はありません

DID CHANGE RENEWAL STATUSは― ユーザが自動更新ステータスを 切り替えるたびに送られます

ユーザ側が自動更新を解除して― 更新ステータスをfalseにする際に このイベントを用います 情報更新に役立ててください

サブスクリプション期間の終わりまで このユーザに関して― 何の通知も来ませんでした その場合 ユーザは何の問題もなく― サブスクリプション期間を 終えたということです

ユーザのステータスを “解約”などに更新しましょう

時間とともに ユーザの数も減るかもしれません その場合 無料トライアルなどを提示し― 再開を呼びかけると思います

登録オファーをお使いください 割引や無料トライアルを 提示できます ユーザの維持や呼び戻しに 役立ちますよ 本日 登録オファーの実装や― 活用についての セッションを予定しています ユーザ維持に役立つ 活用事例も紹介しますよ

続いて ユーザに解約の意思は ないものの― サブスクリプションの再開や更新が できないケースを考えましょう クレジットカードが無効の時や 残高不足の時ですね

この場合App Storeは DID FAIL TO RENEWを送ります この通知から― 請求の問題が起こり 更新が失敗したと分かります ユーザのステータスを “解約”などに更新しましょう

App内のメッセージ機能を使い 期限切れを通知してください

請求の問題が発生した場合― App Storeは自動的に 数回にわたって更新を試みます その結果 無事に支払いがされたら― DID RECOVERが送られます 通知の受領後― ユーザのステータスを 更新してください 新たな有効期限の更新も お忘れなく

サービスを再開できました

今 申し上げた更新を試みる App Storeのサービスは― 自動的に行われるものです

このサービスを うまく活用し― 非自発的解約を 減らしませんか？

昨年“Engineering Subscriptions”の セッションで― 更新を促すために 請求再試行期間を 延長するロジックを説明しました

請求に問題がある ユーザ向けの施策です

その後 アップデートを繰り返し― 再開戦略に 効果を見せています また機械学習モデルにも 目を向け― 再開を促す施策の改善に 取り組んでいます

現在までの成果はどうか？ 請求に問題が生じ 更新に失敗したケースの 77％以上を再開できました

サブスクリプションの再開により― 全体的な非自発的解約率が ２％以下になりました (拍手) 私たちが取り組んできた 請求再試行戦略により―

4600万件以上の再開を 実現したのです (拍手) ユーザの意思に反して― 解約されるはずだった数字です ユーザはサービスの継続を 望んでいました 半数以上は 現在も サブスクリプションを継続中です

どうやって60日間で 再開を成し遂げたのか？

請求の問題が生じていた サブスクリプションのうち― 77％以上が 60日の間に再開しました

そのうち80％以上が 最初の16日間で再開しています

サブスクリプションの再開後に すべきことは？

トリも説明しましたが まずはサービスの再開です ユーザが再アクセスした時 サービスを再開します

再開日から 新しい請求サイクルが始まります

利益配分の引き上げまでの 有料サービスの日数の加算は 再開日に再開します

つまり ここで問題が生じます 請求再試行の開始から 再開までの間 サービスを提供しても その期間の収益は発生しないのです

改善が必要ですね

今秋リリースの新機能を使えば― 支払いの猶予期間を提示できます その間 ユーザは引き続き― 有料サービスを 楽しむことができます 皆さんの利点は この期間に 収益が発生することです (拍手) 解約の意思がなく 自然と サブスクリプションを再開する― ユーザに対して よりよい体験を提供できます 一時的に支払いができなかったユーザの 再開率も上がるでしょう

どうやって実装するのか？ 簡単です ３段階で実装していきます まずApp Store Connectで 猶予期間の構成を オプトインします 先ほどの 再開のデータを基にして― 週更新は６日間 その他は16日間とする予定です

次に 通知やレシート検証における 新しいフィールド― つまり 最新の有効期限を意味する フィールドを確認します

この期間 サービスを続けましょう

支払いの猶予期間を― オプトインするのは なぜでしょう？

利点があります ユーザが解約の意思を 示していなければ サービスを継続して利用できます

また 支払いの猶予期間内に 再開すれば これまでの請求サイクルを 維持できます

デベロッパの皆さんにも―

その期間も収益が発生するという 利点があります

先ほどお話ししたとおり より速やかに― 利用日数が加算され 利益配分率が85％に引き上げられます

ローンチ後 猶予期間の設定を 取り入れてはいかがでしょうか

さて 猶予期間以外で 非自発的解約を削減し― 再開率を向上する施策は 何でしょうか？ その答えはユーザに送信する― App内メッセージの活用です 請求問題による更新失敗を 知らせることができます

猶予期間を提供する場合は― App内メッセージで通知しましょう メッセージの詳細は 各自で決められます プレミアム機能を提供している場合は 猶予期間が終わる頃に― 使用できなくなる機能を 強調するのもいいでしょう サブスクリプションの再開を 促すことができます

この“Foodvisor”は 請求再試行期間に― プレミアム機能の 残りの利用可能日数を表示しています

支払い情報セクションへのリンクを メッセージに貼れば― ユーザが すぐ確認できます

最近 支払い方法の管理ページを 更新しました 最大10種類の支払い方法を 登録できます

利点を得るのは ユーザだけではありません 支払い方法が充実することで 解約率が低下すれば― App Storeの利益になります

たくさん説明しましたが― まとめましょう

最近 導入したばかりの 登録オファーは― 割引や無料サービスを 提示する機能です 自発的解約の削減にご利用ください デイナが説明した SKStorefrontは― 適切なコンテンツの提供を 可能にします

また 予約注文が分かるよう― レシートに目印を付ける予定です ユーザにお礼も言えますよ Server-to-Server Notificationsを ぜひご活用いただき App Storeから請求イベントの通知を 受け取ってください 請求問題を抱えた ユーザに対して― 支払いの猶予期間を提供し 再開率の向上に役立ててください

再開率を上げるのに App内のメッセージも有効です

より詳しい情報やビデオは セッション302でお探しください 午後のセッションに― “Subscription Offers Best Practices”があります 登録オファーと ユースケースを学び― 自発的解約の削減に 生かしてください 何か質問があれば ラボにお越しください

ありがとうございました (拍手)