顧客サポートと返金処理

こんにちは WWDCへようこそ Manjeet Chawlaです App Storeの テクニカルプログラム マネージャーです 今回は お客様サポートや 返金処理に役立つ 新機能について お話ししたいと思います こちらはApp内課金に 焦点を当てた ３回のシリーズの ３回目となります “StoreKit 2について”や “サーバにおけるApp内課金の管理”を まだご覧になって いない場合は 後ほど ご覧いただくことを おすすめします このセッションでは まずお客様サポートについて そしてどのように 状況に応じたサポートを 提供するかについて 説明します 返金はサポートの 重要な部分であるため 同僚のJoeが 返金の 取り扱いと プロセスを通知 改善する 新サーバ APIについて説明します まずはお客様 サポートから始めます App Storeでのビジネスの 成長に合わせてサポートを 提供するメリットと 課題についてお話しします Appが自動更新 サブスクリプションを 提供していたり 消耗型や非消耗型など １回限りのApp内購入で あっても 新しいStoreKitと App StoreサーバAPIが カスタマーサポートの 課題を 迅速かつ効率的に解決します これらのAPIはサポートの 提供だけでなく 最初に顧客を獲得した後も 既存顧客との関係を管理し 全体的な リテンションを高め 顧客満足度を向上させ エンゲージメントを高め 解約を減らし 長期的な収益の向上に 役立ちます 現在 顧客がApp内課金に ついて サポートが必要な場合 Appleか 開発者のあなたに 問い合わせが行きます 状況に応じて 顧客はAppleの セルフサービスサイト Report-A-Problemを 利用するか 電話 メールや チャットでAppleサポートに 連絡して問題に対処します または ソーシャルメディア フォーラム App内のライブチャットで 連絡することもあります App内課金についての 顧客からの問い合わせは 主に以下のシナリオに 当てはまります 顧客のApp内課金や 返金の確認 サービスの問題や 障害に対する 補償の提供 サブスクリプションの 管理や 返金申請のアシストなど これらの質問が多くの シナリオをカバーします 各シナリオについて 詳しく説明します まず最初のシナリオですが 顧客が最初にサポートを 求めてきたときに 顧客が購入した商品を どう特定するでしょうか？ App Storeでコンテンツを 購入されたことが ある方は このメールに 見覚えがあるでしょう App内課金を行った 顧客には その購入の請求書が メールで届きます 請求書にはそれぞれ固有の 注文IDが記載されています 顧客はメールや アカウント設定で 購入履歴を確認すると この情報にアクセスできます 顧客からサポートの 連絡が入った際に 請求書に記載されている 注文IDを確認し 新しいサーバ間APIを 使って いただいた請求書から App内課金を 検索することができます 請求書の検証だけでなく APIは その有効性を確認し App内課金に 問題点があるか把握できます 例えば App Storeでの 課金がすでに返金済みか どうか分かるわけです では APIが実際に機能する 様子を見てみましょう 顧客がサポートチームに 連絡した際に 顧客に請求書の 注文IDを尋ねます サーバは請求書 検索APIを呼び出し その応答として App Storeがステータスと JWS形式で署名された トランザクションを返します 最後に この情報を使用して 正しい App内課金の サポートを提供します このAPIをサーバに 実装するには URLに請求書の注文IDを リクエストに AppのApple IDを 指定して lookupエンド ポイントを呼び出します 返り値として JWS形式で署名された その請求書の トランザクションを含む signedTransactions オブジェクトが返されます 各トランザクションの ペイロードを デコードして 購入の詳細を取得できます 新しいステータス フィールドを見てみましょう このフィールドは 請求書の 全体的な ステータスを示します ０は請求書が有効であり この注文IDの トランザクションが 含まれることを意味します １は注文IDが 無効であることを意味し ２は請求書は有効であるが 注文IDに 一致するトランザクションが 無いことを意味します このAPIからの返り値の 利用例を見てみましょう これは顧客が App内課金を行った商品の originalTransactionIdを productIDと 購入日と合わせて 保存している顧客アカウント データベースです このAPIを使用すると 顧客から問題について 連絡が来た際に 請求書の注文IDを 顧客のApp内課金に リンクできます 例えば この顧客が Appでコインを購入して サポートに連絡を 行った場合も 購入したコインの請求書 注文IDを保存できます ある顧客の originalTransactionIdを 使って その顧客の 過去の返金履歴を 調べたい場合を 考えてみましょう 現在は 返金に関する 通知を受け取るために verifyReceipt APIや App Storeサーバ通知を 使っているかもしれません しかし 障害が発生し サーバがApp Storeからの 通知を受け取れない場合 この顧客の過去の返金を どう調べるべきでしょうか？ 当社では顧客が App内課金で 購入した商品の originalTransactionIdで 返金された トランザクションを 検索できる 新しい サーバ間APIを導入します このAPIを使用することで 障害発生時や メンテナンスの際にも 簡単かつ迅速に 返金額を調べて 対応することが可能です さらに このAPIは 顧客のすべての返金履歴を 調べるのにも役立ちます 例えば Appが サブスクリプションと 消耗型の両方を 提供している場合 このAPIはすべての コンテンツタイプに 応じた すべての トランザクションを返します このAPIを サーバに実装するには originalTransactionIDを URLに AppのApple IDを リクエストパラメーターに 指定して リクエストを作成します 返り値として JWS形式で署名された 返金済みトランザクションの 一覧が返って来ます 各トランザクションの ペイロードを デコードすることで 購入に関する必要な すべての情報を取得できます そこでサンプルの顧客 アカウントデータベースで このAPIから返された 情報を元に originalTransaction IDを 使って 返金済みトランザクションを 更新できます

サービスに問題があると 分かりましたが どのようにして 補償を行うのでしょう？ 現在考えられるオプションは いくつかあります ゲームの場合は仮想通貨や コンテンツなどの形で App内補償を 提供することもあるでしょう サブスクリプションの場合は 次回更新時に割引を 提供することもできます サービスの問題については どう補償するでしょう？ iOS 14では サブスクリプション オファーコードという 新機能を導入し 期間限定で 購読料を割引したり 無料で提供することで ユーザーの獲得 維持 回復を支援しています この一意の ワンタイムコードは オンラインやオフラインで 配布出来ます カスタマーサービスの 問題については コードを補償として提供し 離脱を防ぐことができます これを機に 別のサブスクリプションを 提案することもできます 例えば より低価格でお得な 長期プランの提案などです また iOS 14および iPadOS 14以降のお客様は StoreKitで presentCodeRedemptionSheet APIを実装していれば ワンタイムコード 引き換え用のURLを介して App Storeでオファーコードを 引き換えたり App内でも 引き換えることができます では App内の コード引き換えフローの 例を見てみましょう 必要なのは 引き換えフロー 開始用のカスタムUIだけです このUIを違和感なく 提供できる場所として 例えば Appの設定画面や 顧客がサポート担当者と チャットを する際の ライブチャット 機能があります 顧客が引き換え ボタンをタップすると システムは自動的に 次のような コード引き換え画面を 表示して 顧客はコードを 入力してオファーを 受け取ることができます

では スポーツやライブ ビデオなどの ストリーミング系Appに ありがちな 障害発生や イベント中止の 例を見てみましょう これらの障害や 中止イベントにおいて 顧客をどのように なだめるべきでしょうか？ 当社では自動更新型の サブスクリプション用に 新しいサーバ間 APIを導入し 有料サブスクリプションの 更新日が延長可能です このAPIによって 一時的な障害や サービス問題に対する おわびとして 追加の無料サービス期間を 提供することが可能です 顧客のサブスクリプション 更新日を 暦年に２回 それぞれ 最大90日まで延長できます これによりサービスの問題や 障害に対して 柔軟に対応できます なお 延長期間は 85％の収益率を 得るために必要となる １年間の有料利用期間には 含まれません では このAPIを サーバに実装する 方法を見てみましょう このAPIのリクエストには 顧客の サブスクリプションの originalTransactionID 日単位の延長期間 延長の理由コードが必要です 返り値には リクエストで渡された トランザクションID 延長期間のWeb注文項目ID リクエストが成功したか どうかを示すフラグ リクエストが成功した場合は その延長の 発効日が含まれます では このAPIを使用した ２つの異なるシナリオを 見てみましょう 最初のシナリオでは 顧客からサポートチームに 連絡があった場合 このAPIを呼び出して 顧客におわびのしるしとして App Storeで サブスクリプションを 延長し メールで通知します 次のシナリオでは 不測の事態により スポーツイベントが キャンセルされたり ライブストリーミングの イベントが中断されたり した場合に サポート チームがAPIを活用し App Storeで サブスクリプションを 延長し 顧客に メールで通知します

では 顧客が サブスクリプションを 管理したい場合 どのようにすれば 顧客がApp内で サブスクリプションを 管理できるでしょうか？ 当社の新しい StoreKit 2 APIにより サブスクリプションの 管理ページを表示できます これにより顧客を App Storeに リダイレクトすることなく App内で サブスクリプション 管理機能を提供できます オプションとして サブスクリプションの 管理ページを表示する前に お得なオファーを表示したり 解約後にアンケートを行い 理由を尋ねることもできます また このAPIを使って サブスクリプション 購入管理をサンドボックスで テストすることもできます

このAPIの実装は 非常に簡単で １行のコードで済みます StoreKit 2から showManageSubscriptions() を呼び出すだけで 購読管理のページが開きます では Appで サブスクリプションの 管理UIを見てみましょう アカウント設定では ユーザーに対して サブスクリプション管理の オプションを追加できます 顧客がこのボタンを タップするとApp Storeに 既存のサブスクリプション 管理ページが 表示され アクティブな サブスクリプションと 更新の オプションが表示されます こちらはApp Storeの アカウント設定の サブスクリプションの管理に アクセスして サブスクリプションの表示 アップグレード ダウングレード キャンセル を行う際と同じものです ここでサブスクリプションの キャンセルを選択すると 解約の詳細と サービスの 有効期限が記載された 確認画面が表示されます ユーザーがこのページで 実行するアクションに対し 皆様のサーバに App Storeサーバ 通知が送られ 新しいStoreKit 2 APIを 実装していれば Appにも通知されます 最後に 顧客が購入した 商品に満足できず 返金を希望する場合も App内から サポートが可能です では 顧客がApp内で 返金を要求するには どうすれば 良いのでしょうか？ 現在 beginRefundRequestと 呼ばれる 新しいStoreKit 2 APIが 導入され Appから直接App内 課金の返金を要求できます 返金が承認されると Appに通知され 皆様のサーバには App Storeから 返金通知が届きます または 返金が 拒否された場合 新しいREFUND-DECLINED 通知がサーバに送られます 今回初めて このAPIを使用して App内のサンドボックスで 返金を要求する テストが可能になりました このAPIを実装するには 購入商品の トランザクションIDを 指定して beginRefundRequest メソッドを呼び出します リクエストが送信された後 do-catch文を使用して エラーを処理できます 例えば 返金済みの トランザクションに 対する重複した リクエストの場合や その他の理由でリクエストが 失敗した場合 エラーコードに返金要求の ステータスが反映されます Appの返金要求UIの サンプルです ヘルプページに 返金をリクエストするという 新しいオプションが 追加されました 選択すると 顧客が返金を 要求するための 購入履歴が表示されます 例えば購入したPower Surgeが期待通りに 動作しなかった場合 顧客はその購入を タップして返金要求シートを 呼び出せます こちらに詳細と返金理由の リストが表示されます リクエストが送信されると App Storeは App内の確認画面の他に 顧客にAppleから “問題を報告”リンクが 記載されたメールが送信され 返金の状況を 確認できるようになります 新しいAPIを使用することで 状況に応じたApp内課金の サポートを Appや その他のサポートチャネルを 介して シームレスに 提供可能となります 優れたサポートの提供により 全体的な定着率が高まり 顧客満足度を向上させ エンゲージメントを 高めることで 最終的に良い評価や レビューを獲得できます 誰に対しても より良い体験を提供できます 新しい返金リクエスト APIを使って 顧客が返金を要求する方法を 紹介しましたが リクエストの送信後にも 多くの流れが存在します そこで同僚のに 返金の処理と 返金の決定に関する 新たな処理について 説明してもらいます ありがとう Manjeet こんにちは Joe Maniです App Storeのプログラム マネージャーです 返金はデリケートな トピックであり App Storeでは 真剣に受け止めています トランザクションの一部が 関係しているものの その影響を私たちは 理解しています では WWDC20で発表された 返金通知について 簡単におさらいしていきます 次に 返金の取り扱いに ついて説明します 最後に 返金プロセスの通知と 改善に役立つ 新機能について説明します WWDC20では 新しい通知タイプ REFUNDを発表しました 顧客に返金が行われた後 App Storeは REFUND 通知をお客様の サーバに送信します AppStore Connectでサーバ URLを設定している場合 すでにREFUND 通知を 受信している場合もあります サーバでこの通知を 受け取ったら HTTPステータスコード 200で応答してください その後 それに応じて 返金に対する 適切な措置を 講じることができます REFUND 通知の開始以来 フィードバックを いただいており ベストプラクティスを少し ご紹介します お客様のビジネスモデルに 最適な 対応策を講じてください 例えば ユーザーが ゲーム内通貨を購入した後に 返金を要求した場合 サーバがREFUND 通知を 受け取った後に アカウントから残高を 差し引くことができます サブスクリプションの場合は 返金が行われ キャンセル された時点で サービスへの アクセスを取り消せます 対応策を検討する際には ゲームデザインへの 影響を考慮してください マーケティングや 販促ツールを使用して 顧客との関係を修復し 行った行動に対して コミュニケーション チャネルを通じて 常に明確なメッセージを 提供してください

ゲーム内通貨として コインを提供している Appの返金例を 時系列でご紹介します 顧客がコインを 100枚購入した後 直ちにゲーム内でコインを 使うことができます 顧客が新しい 返金リクエストAPIや Apple Supportに連絡して 返金を要求したと想定します 返金が承認されると App Storeが 返金を行い お客様の サーバに返金通知を送り 顧客にも通知されます これは通常 48時間 以内に行われます では 返金が リクエストされて App Storeで 決定が下るまでの 流れをご紹介します 大まかに言うと 各返金リクエストは 当社の返金判定システム 経由で決定されます 返金判定システムには 問題となった 取引や 顧客の購入履歴 返金履歴など さまざまな情報が 集約されています 返金の決定について もっと 積極的に関与したいと いう声もあり 返金プロセスの改善と 情報提供に 役立つ新機能を ご紹介したいと思います 新しいConsumption APIでは 顧客の App内課金に関する情報を App Storeと共有できます 顧客がApp内で購入した 消耗型の返金を要求すると App Storeは お客様のサーバに CONSUMPTION-REQUESTという 新しい通知が送信されるので 消費データを返信します 多くの場合 顧客は 購入後すぐに コンテンツを 消費し始めるので この情報を知っておくと 返金の決定 プロセスに役立ちます 返金の判断材料とするため App Storeから CONSUMPTION-REQUESTを 受け取ってから 12時間以内に消費情報を 返信してください では 消費データに含まれる 項目について見てみましょう 消費ペイロードには 以下のデータが含まれ 各データが返金の 判断材料となります

まず App内課金の 元となる トランザクションIDを リクエストURLに含めます Appleが意思決定にデータを 使用するため ユーザーが要求された 消費APIデータを Appleに送信することに 同意した場合 customerConsentedを “true”に設定します consumptionStatusは 重要です ユーザーがApp内課金を 一部消費したのか 完全に消費したか まったく 消費していないかを示します 例えばAppにアイテムを 交換できる プラットフォームがあったり 他のアカウントから 転送できる場合は 消費されたと見なされます 消費プラットフォームは Appがクロス プラットフォームかどうか どこで消費したか特定します sampleContent フィールドを使用して ユーザーに無料サンプルや トライアルを提供したか ユーザーがApp内で同様の 購入をしたか示します 代わりに このフィールドを使って ユーザーが購入前に App内課金や 想定されるゲームプレイや 仕組みに関する 情報を提供されたかも 示せます deliveryStatusフィールドで App内購入物が 顧客に正常に 配信され 正常に 機能したことを示します appAccountTokenは StoreKit 2で新たに導入されました これが購入を行い コンテンツの 消費を開始したユーザーの アカウントに 紐づいたUUIDになります 残りのフィールドには ユーザーの アカウント保有期間 Appでのプレイ時間 総利用金額 アカウントの現在の状態 などの情報が含まれます 返金リクエストに 関しては ３つの関係する サーバ通知があります 新しいCONSUMPTION-REQUEST 通知は 消耗型の App内課金に対して 返金要求があった際に 通知されます すべてのコンテンツ タイプにおいて 顧客に返金が行われると REFUND 通知が届きます すべてのコンテンツタイプで Store Kit APIを通して 開始された返金要求が 拒否されると REFUND-DECLINEDが 通知されます では 返金の 時系列に戻ります 顧客が消耗型に関する App内課金の 返金を要求した場合 App Storeサーバが お客様のサーバに 消費リクエスト通知を 送信するようになりました 返金の判断材料にするため 12時間以内に消費データを App Storeの サーバに返信してください 承認されると App Storeから REFUND 通知が送信され お客様のサーバから HTTP OKレスポンスが 送信されると 返金のための 適切な処置が行われます

また Consumption APIは 本日より本番環境でも サンドボックスのテスト 環境でも ご利用可能です では 新しい Consumption APIを使って Appleに情報を送る メリットについて説明します これらのデータを 取得することで 透明性を高め返金プロセスを 改善できます その結果 顧客に対しても より良い 結果がもたらされます 新しいREFUND通知により 顧客との接点が増え 全体的な コミュニケーションが 向上します では同僚の Majeetに引き継ぎ 重要ポイントの おさらいをしたいと思います 本日はたくさんの トピックを取り上げました このセッションの重要な ポイントを見ていきましょう 新しいStoreKit APIにより 顧客が返金を要求した際の カスタムヘルプUIや サブスクリプションの場合は App内で管理する方法が 実装されました 新しいサーバ間APIの 実装により カスタマーサポートを見直し 最適化できます 例えば 請求書検索APIを使って 顧客のApp内課金を特定し 検証できます まだお済みでない場合は App Storeからの 返金や消費要求 その他のステータス 更新通知を 受信できるよう サーバを 設定してください Appのビジネスモデルに 最適な対応策を 策定し 返金時の 対応を行ってください 最後に App Storeからの 消費要求通知に対して 最新の消費データを 送信することで Appleの返金決定システムに 通知できるようになりました 本日の内容は 以上となります 新しいStoreKit 2 APIの詳細については “StoreKit 2について” をご覧ください App内課金の サーバサイドの ロジックに関しては “サーバにおける App内課金の管理”を

ご視聴ください ありがとうございました [軽快な音楽]