顧客をサポートし、払い戻しを処理します
App Storeでビジネスを成功させるには、優れたカスタマーサポートが不可欠です。アプリ内購入を行う顧客に摩擦のないサポートエクスペリエンスを提供する方法をご覧ください。これには、顧客が自動更新可能なサブスクリプションを簡単に管理またはキャンセルしたり、アプリ内から直接払い戻しをリクエストしたりできるAPIが含まれます。払い戻しを処理するためのベストプラクティスと、顧客をより適切にサポートするのに役立つ追加のAPIについて説明します。
こんにちは、WWDCへようこそ。
私の名前はAppStoreのテクニカルプログラムマネージャーであるManjeetChawlaです。
お客様をサポートし、払い戻しを処理するのに役立ついくつかの新機能についてお話しできることをとてもうれしく思います。
これは、アプリ内購入に焦点を当てた3部構成のシリーズの3番目のセッションです。
また、「Meet StoreKit 2」や「サーバーでのアプリ内購入の管理」をまだご覧になっていない場合は、このセッションの後で全体像を把握することをお勧めします。
このセッションでは、最初にカスタマーサポートと、顧客にコンテキストサポートを提供する方法について説明します。
また、払い戻しはサポートの重要な部分であるため、同僚のJoeが、払い戻しの処理と、払い戻しプロセスを通知して改善するための新しいサーバーAPIについて説明します。
App Storeでビジネスが成長するにつれて、顧客のサポート、スケーラブルなサポートを提供することのメリットと課題から始めましょう。
アプリが自動更新サブスクリプションを提供する場合でも、消耗品や非消耗品などの1回限りのアプリ内購入を提供する場合でも、カスタマーサポートの問題をタイムリーかつ効率的に解決するのに役立つ新しいStoreKitおよびAppStoreサーバーAPIを導入しています。
これらのAPIは、サポートを提供するだけでなく、最初に顧客を獲得した後、既存の顧客との関係を管理するのに役立ちます。
全体的な定着率を高め、顧客満足度を向上させます。
これにより、エンゲージメントが高まり、解約率が低下して長期的な収益が増加します。
現在、顧客がアプリ内購入についてサポートを必要としている場合は、Appleまたは開発者であるあなたに連絡することができます。
また、シナリオに基づいて、お客様はAppleのセルフサービスWebサイト「Report-A-Problem」を使用するか、電話、電子メール、またはチャットでAppleサポートに連絡して問題に対処することができます。
または、ソーシャルメディア、フォーラム、またはアプリ内のライブチャットを介して連絡する場合もあります。
また、アプリ内購入について連絡があった場合、問題はこれらのシナリオのいずれかに該当する可能性があります。
顧客のアプリ内購入または払い戻しの特定から、サービスの問題や停止に対する補償の提供、サブスクリプションの管理や払い戻しのリクエストの支援まで、これらの質問はほとんどのサポートシナリオをカバーしています。
ここでは、各シナリオについて説明します。
もっと詳しく。最初のシナリオから始めましょう。
顧客が最初にサポートを求めてあなたに連絡したときに、顧客が行った購入をどのように識別しますか？
これで、App Storeでコンテンツを購入した場合は、すでにこのメールを見たことがあるかもしれません。
現在、顧客がアプリ内購入を行うと、その購入の請求書がメールで届きます。
この請求書には注文IDが含まれています。
これは請求書ごとに一意です。
また、顧客は電子メールを介して、またはアカウント設定で購入履歴を確認することにより、これにアクセスできます。
そして今、顧客がサポートを求めてあなたに連絡したとき、あなたは彼らの請求書の注文IDを顧客に尋ね、新しいサーバー間APIを使用して、顧客によって提示された請求書のアプリ内購入を検索することができます。
このAPIは、請求書の検証に加えて、アプリ内購入に関する問題を特定するのにも役立ちます。
たとえば、請求書にAppStoreによってすでに払い戻された購入が含まれている場合です。
それでは、このAPIがどのように機能するかを見てみましょう。
だから今、顧客があなたのサポートチームに連絡すると、顧客に請求書注文IDを要求すると、サーバーは請求書ルックアップAPIを呼び出すことができ、それに応じて、AppStoreはJWS形式で署名されたその請求書のステータスとトランザクションを返します。
そして最後に、この情報を使用して、正しいアプリ内購入のサポートを提供できます。
このAPIをサーバーに実装するには、URLに請求書注文IDを、リクエストにアプリのApple IDを使用して、ルックアップエンドポイントを呼び出すことができます。
応答には、JWS形式で署名された請求書のトランザクションを含むsignedTransactionsオブジェクトが含まれます。
各トランザクションのペイロードをデコードできます。
購入の詳細を取得します。
それでは、新しいステータスフィールドを詳しく見てみましょう。
このフィールドは、請求書の全体的なステータスを識別します。
可能な値は0で、請求書が有効でこの注文IDのトランザクションが含まれていることを意味し、1は注文IDが無効であることを意味し、2は請求書が有効であることを意味しますが、この注文IDに一致するトランザクションが見つかりませんでした。
それでは、このAPIからの応答を使用する方法の例を確認しましょう。
これは、各顧客のアプリ内購入のoriginalTransactionIdを、productIDおよび購入日とともに保存する可能性のあるサンプルの顧客アカウントデータベースです。
このAPIを使用すると、顧客が問題について連絡したときに、請求書の注文IDを顧客のアプリ内購入にリンクできます。
たとえば、この顧客がアプリでコインを購入し、サポートについて連絡があった場合、購入したコインの請求書注文IDを保存できます。
ここで、顧客のoriginalTransactionIdがあり、過去の払い戻しを検索するシナリオを考えてみましょう。
現在、払い戻しに関する通知を受け取るために、verifyReceiptAPIまたはAppStoreサーバーの通知に依存している可能性があります。
ただし、停止が発生し、サーバーがAppStoreから通知を受信しなかった場合はこの顧客の過去の払い戻しをどのように検索しますか？
アプリ内でのアプリ内購入の元のトランザクションIDを使用して、顧客の払い戻し済みトランザクションを検索するための新しいサーバー間APIを導入しています。
このAPIを使用すると、いつでもすばやく簡単に払い戻しを検索することで、停止や定期メンテナンスを処理できます。
さらに、このAPIは、アプリの顧客の払い戻し履歴全体を特定するのにも役立ちます。
たとえば、アプリがサブスクリプションと消耗品の両方を提供している場合、このAPIは、すべてのコンテンツタイプにわたって返金されたすべてのトランザクションを返します。
このAPIをサーバーに実装するには、URLに元のトランザクションIDを、リクエストパラメータにアプリのAppleIDを使用してリクエストを作成します。
応答には、JWS形式で署名された返金済みトランザクションのリストが含まれています。各トランザクションのペイロードをデコードすることで、購入に必要なすべての情報を取得できます。
したがって、サンプルの顧客アカウントデータベースに戻ると、このAPIによって返された情報を使用して、元のトランザクションIDを使用してこの顧客の返金されたトランザクションを更新できます。
さて、サービスの問題があったことを確認した後、どのように顧客に補償しますか？
今日、考慮すべきいくつかの異なるオプションがあります。
ゲームの場合、仮想通貨またはコンテンツの形で何らかの形のアプリ内報酬を提供している可能性があります。
または、サブスクリプションの場合は、次回の更新時に割引を提供することをお勧めします。
では、サービスの問題についてサブスクライバーにどのように補償しますか？
iOS 14では、サブスクリプションオファーコードと呼ばれる新機能が導入されました。
これは、サブスクリプションを割引価格または期間限定で無料で提供することにより、サブスクライバーを取得、保持、および取り戻すのに役立ちます。
これらの一意のワンタイムコードを配布できますオンラインまたはオフラインチャネルを使用します。
また、カスタマーサービスの問題については、問題の補償としてオファーコードを提供できます。
これにより、保持が向上します。
また、これを別のサブスクリプションを提案する機会として使用することもできます。
たとえば、より低価格でより多くの価値を提供する、より長い期間のプラン。
また、iOS14およびiPadOS14以降のお客様は、StoreKitにpresentCodeRedemptionSheet APIを実装している場合、1回限りのコード引き換えURLを介して、またはアプリ内でAppStoreでオファーコードを引き換えることができます。
それでは、アプリ内のサンプルコード償還フローを見てみましょう。
作成する必要がある唯一のカスタムUIは1つです償還フローを開始します。
このUIを提供する自然な場所がいくつかあります。
たとえば、アプリの設定画面や、顧客がサポートエージェントとチャットしているときのライブチャット機能内などです。
顧客が引き換えボタンをタップすると、システムは、顧客がコードを入力してオファーを引き換えるために、ここに示されているような一連のコード引き換え画面を自動的に提供します。
次に、停止が発生したか、イベントがキャンセルされたシナリオを見てみましょう。
これは、スポーツ、ライブTV、ビデオなどのストリーミングベースのアプリでより一般的である可能性があります。
これらの停止またはキャンセルされたイベントに対して、どのように顧客をなだめることができますか？
有料のアクティブなサブスクリプションの更新日を延長するために、自動更新可能なサブスクリプション用の新しいサーバー間APIを導入しています。
このAPIを使用すると、追加の期間、顧客に無料のサービスを提供できます。
これは、一時的な停止やサービスの問題の緩和策として使用できます。
顧客のサブスクリプションの更新日は、暦年に2回、それぞれ最大90日先まで移動できます。
サービスの問題や停止を解決する柔軟性を提供します。
延長期間は、85％の収入率を受け取るために必要な1年間の有料サービスにはカウントされないことに注意してください。
それでは、このAPIをサーバーに実装する方法を見てみましょう。
このAPIのリクエストには、顧客のサブスクリプションの元のトランザクションID 、延長期間（日数）、および延長の理由コードが必要です。
応答には、リクエストで渡されたトランザクションID 、延長更新のWeb注文ラインアイテムID 、リクエストが成功したかどうかを示す成功フラグ、および延長の発効日が含まれます。
リクエストが成功した場合。
それでは、このAPIを使用できる2つの異なるシナリオを見てみましょう。
最初のシナリオでは、顧客がサービスの問題または停止についてサポートチームに連絡したときに、このAPIを呼び出すことで顧客をなだめることができ、それに応じて、App Storeはサブスクリプションを延長し、電子メールで顧客に通知します。
または、2番目のシナリオでは、予期しない状況が原因でスポーツマッチがキャンセルされたり、ライブストリーミングイベントが中断されたりした場合、サポートチームはこのAPIを積極的に使用できます。
これに応じて、AppStoreはサブスクリプションを延長して通知します。
電子メールを介して顧客。
さて、顧客がサブスクリプションを管理したいシナリオの場合、アプリ内で顧客がサブスクリプションを管理できるようにするにはどうすればよいでしょうか。
サブスクリプションの管理ページを表示する新しいStoreKit2 APIを導入します。
これにより、顧客をApp Storeにリダイレクトすることなく、アプリ内でサブスクリプション管理機能を提供できます。
オプションで、サブスクリプションの管理ページが表示される前に保存オファーを提示したり、キャンセル後にキャンセル理由を取得するために終了調査を提示したりすることもできます。
また、このAPIを使用すると、サンドボックス環境でサブスクリプション購入の管理をテストすることもできます。
このAPIは実装が非常に簡単で、1行のコードが必要です。
StoreKit 2でshowManageSubscriptions（）メソッドを呼び出すだけで、サブスクリプションの管理ページが表示されます。
それでは、アプリのサブスクリプションUIの管理のサンプルを見てみましょう。
アカウント設定で、ユーザーがサブスクリプションを管理するためのオプションを追加できます。
顧客がこのボタンをタップすると、App Storeには、現在アクティブなサブスクリプションと更新オプションを含む既存のサブスクリプションの管理ページが表示されます。
これは、AppStoreのアカウント設定でサブスクリプションの管理にアクセスしたときに顧客がよく知っているビューと同じです。
サブスクリプションを表示、アップグレード、ダウングレード、またはキャンセルできる場所。
これで、顧客がサブスクリプションのキャンセルを選択した場合、キャンセルの詳細とサービスの有効期限が記載された確認画面が表示されます。
また、ユーザーがこのページで実行する可能性のあるアクションについては、サーバーにApp Storeサーバー通知が送信され、新しいStoreKit 2APIを実装した場合はアプリに通知されます。
最後に、顧客が購入に不満を持っていて、払い戻しをリクエストしたい場合、助けを得るためにアプリを離れる必要はありません。
では、どうすれば顧客がアプリ内で払い戻しをリクエストできるようにすることができますか？
現在、beginRefundRequestと呼ばれる新しいStoreKit 2 APIを導入しています。
これにより、顧客はアプリ内から直接アプリ内購入の払い戻しをリクエストできます。
また、払い戻しが承認されると、アプリに通知され、サーバーはAppStoreから払い戻し通知を受け取ります。
または、払い戻しが拒否された場合、サーバーは新しいREFUND-DECLINED通知を受け取ります。
また、このAPIを使用して、アプリ内でサンドボックスで払い戻しを開始およびテストできるようになりました。
このAPIを実装するには、その購入のトランザクションIDを使用してbeginRefundRequestメソッドを呼び出すだけです。
そして、リクエストが送信された後、do-catchステートメントを使用してエラーを処理できます。
たとえば、これがすでに返金されたトランザクションの重複リクエストであった場合、またはリクエストが他の理由で失敗した場合、エラーコードは返金リクエストのステータスを反映します。
これがアプリの払い戻しリクエストUIのサンプルです。
ヘルプページに、「払い戻しをリクエストする」という新しいオプションが追加されました。
選択すると、アプリはその顧客が払い戻しをリクエストするための購入を表示します。
また、電力サージの購入が期待どおりに機能しなかった場合、顧客はその購入をタップして、購入の詳細と顧客が選択する理由コードのリストを含む返金要求シートを呼び出すことができます。
リクエストが送信されると、アプリ内の確認画面に加えて、App Storeは顧客にAppleの「問題の報告」へのリンクを記載したメールを送信し、そこで払い戻しのステータスを確認できます。
そのため、新しいAPIを使用すると、アプリ内および他のサポートチャネル全体で、アプリ内購入に対してコンテキストに応じたシームレスなサポートを提供できるようになります。
優れたサポートを提供することで、全体的な定着率が高まり、顧客満足度が向上します。
これにより、エンゲージメントが高まり、最終的にはより肯定的な評価とレビューが得られます。
言い換えれば、それは誰にとってもより良い経験です。
今、私たちはあなたが顧客に方法を提供する方法について話しました新しい払い戻しリクエストAPIを使用して払い戻しをリクエストしますが、リクエストの開始後に発生する払い戻しにはさらに多くのことがあります。
そこで、同僚のジョーを招待して、払い戻しの処理と、払い戻しの決定に関する新しい機会について詳しく説明します。
ありがとう、マンジート。
こんにちは。
私の名前はJoeManiです。
AppStoreのプログラムマネージャーです。
払い戻しはデリケートなトピックであり、ここAppStoreでは真剣に受け止めています。
トランザクションのごく一部に影響しますが、アプリへの影響は理解しています。
WWDC20で開始された払い戻し通知の簡単な要約から始めたいと思います。
次に、払い戻しの処理方法についていくつかの洞察を提供します。
最後に、払い戻しプロセスの通知と改善に役立つ新機能について説明します。
WWDC20では、REFUNDと呼ばれる新しい通知タイプを発表しました。
顧客に返金が発行された後、AppStoreはREFUND通知をサーバーに送信します
。App Store ConnectでサーバーURLを構成している場合は、すでにREFUND通知を受信している可能性があります。
サーバーがこの通知を受信したら、成功したHTTPステータスコード200で応答します。
その後、応答として払い戻しに対して適切なアクションを実行できます。
REFUND通知の開始以来、私たちはあなたのフィードバックを聞く機会がありました。
そして私はあなたといくつかのベストプラクティスを共有したいと思います。
ビジネスモデルに最適な対応戦略を見つけてください。
たとえば、ユーザーがゲーム内通貨を購入してから払い戻しをリクエストした場合、サーバーが払い戻し通知を受け取った後、アカウントから残高を差し引くことができます。
一方、サブスクリプションの場合、サブスクリプションが払い戻されてキャンセルされると、サービスへのアクセスを取り消すことができます。
応答戦略を特定するときは、ゲームデザインへの影響を考慮してください。
マーケティングおよびプロモーションツールを使用して顧客に再度働きかけ、常に明確なメッセージを顧客に提供しますあなたがとった行動に関するあなたのコミュニケーションチャネル。
ゲーム内通貨としてコインを提供するアプリのサンプル払い戻しタイムラインを見てみましょう。
顧客が100枚のコインを購入すると、すぐにそれらのコインをゲーム内で使用できます。
その後、お客様が新しいリクエスト払い戻しAPIを使用するか、Appleサポートに連絡して、払い戻しをリクエストした場合。
また、払い戻しが承認されると、App Storeは払い戻しを発行し、サーバーに払い戻し通知を送信し、顧客にも通知します。
そして、これは通常48時間以内に発生します。それでは、払い戻しがリクエストされた後、AppStoreが決定を下す前に何が起こるかを見てみましょう。
大まかに言えば、各払い戻しリクエストは通過します決定を下すための返金決定システム。
返金決定システムには、問題のトランザクションに関する情報と、顧客の購入や返金履歴などの他の要因が含まれています。
払い戻しの決定においてより積極的な役割を果たしたいとのご意見をいただきましたので、払い戻しプロセスを改善して通知する新機能を発表できることをうれしく思います。
新しいConsumptionAPIを使用すると、顧客のアプリ内購入に関する情報をAppStoreと共有できます。
顧客が消耗品のアプリ内購入の払い戻しをリクエストすると、AppStoreはサーバーにCONSUMPTION-REQUESTという新しい通知を送信します。
あなたが消費データで返答するために。ほとんどの場合、顧客は購入後すぐにコンテンツの消費を開始します。
この情報を知っていると、払い戻しの決定プロセスに役立ちます。
消費情報は、払い戻しの決定を通知するために使用できるように、CONSUMPTION-REQUESTを受信してから12時間以内にAppStoreに送信してください。
それでは、消費データに含まれるフィールドを見てみましょう。
消費ペイロードには、次のデータポイントが含まれています。
各データポイントは、払い戻しの決定を通知するのに役立ちます。
まず、アプリ内購入の元のトランザクションIDをリクエストURLに含めます。
Appleが決定にそのデータを使用できるように、ユーザーが要求された消費APIデータをAppleに送信することに同意した場合は、customerConsentedフィールドを「true」に設定します。
消費ステータスフィールドは重要です。
これを使用して、ユーザーがアプリ内購入を部分的に消費したか、完全に消費したか、まったく消費していないかを示します。
たとえば、アプリに物々交換のある交換プラットフォームがある場合、またはアプリ内購入が1つのアカウントから別のアカウントに転送された場合、そのアプリは消費されたと見なされます。
消費プラットフォームフィールドは、アプリがクロスプラットフォームであり、どこで消費されたか。
sampleContentフィールドを使用して、無料のサンプルまたは試用版をユーザーに提供したかどうか、
またはユーザーにアプリ内で同様のアプリ内購入が与えられたかどうかを示します。
または、このフィールドを使用して、購入前にアプリ内購入と予想されるゲームプレイまたはメカニズムに関する情報がユーザーに提供されたかどうかを示します。
deliveryStatusフィールドを使用して、アプリ内購入が顧客に正常に配信され、正しく機能したことを示します。
appAccountTokenは、StoreKit 2で導入された新しいフィールドです。
これは、作成するアプリのユーザーアカウントに関連付けられたUUIDになります。
つまり、購入を開始し、購入のためにコンテンツを消費します。
残りのフィールドには、ユーザーがアカウントを持っている期間、アプリでプレイした時間、合計費用、アカウントの現在のステータスに関する情報が含まれます。
払い戻しリクエストには、3つの関連するAppStoreサーバー通知があります。消耗品のアプリ内購入に対して払い戻しリクエストが開始されたときに通知する新しいCONSUMPTION-REQUEST通知です。
すべてのコンテンツタイプについて、REFUND通知は、顧客に返金が発行されたときに通知します。
また、すべてのコンテンツタイプについて、REFUND-DECLINED通知Store KitAPIを使用して開始されたリクエストの払い戻しが拒否されたときに通知します。
それでは、払い戻しのタイムラインに戻りましょう。
顧客が消費可能なアプリ内購入の払い戻しをリクエストすると、AppStoreサーバーはサーバーに消費リクエスト通知を送信します。
サーバーは12時間以内に消費データをAppStoreサーバーに返信し、それが決定に使用されます。
承認されると、App StoreはREFUND通知を送信し、サーバーがHTTP OK応答で応答した後、その払い戻しに対して適切なアクションを実行できます。
また、消費APIは、本番環境とサンドボックスでのテストの両方で利用できます。
それでは、新しいConsumptionAPIを使用してAppleに情報を送信することの利点のいくつかを取り上げましょう。
これらのデータポイントを取得すると、透明性が高まり、全体的な払い戻しプロセスが改善されます。
これにより、顧客により良い全体的な結果がもたらされます。
また、新しいREFUND通知を使用すると、顧客に連絡する機会が増え、全体的なコミュニケーションが向上します。
それでは、同僚のManjeetに返送して、これまでに取り上げたすべてのことからいくつかの重要なポイントを共有したいと思います。
それで、今日はたくさんのトピックを取り上げました。このセッションの重要なポイントを見ていきましょう。
新しいStoreKitAPIを使用すると、顧客が払い戻しをリクエストしたり、アプリ内でサブスクリプションを管理したりするためのカスタムヘルプUIをアプリに実装できるようになりました。
新しいサーバー間APIを実装することにより、カスタマーサポートジャーニーを確認して最適化します。
たとえば、請求書検索APIを使用して、顧客のアプリ内購入を識別および検証します。
また、まだ行っていない場合は、App Storeから払い戻し、消費リクエスト、その他のステータス更新通知を受け取るようにサーバーを設定します。
最も効果的な対応戦略を特定するアプリのビジネスモデルが払い戻し時にアクションを実行するため。
そして最後に、最新の消費データを送信してApp Storeからの消費要求通知に応答することで、Appleの返金決定システムに通知できるようになりました。
つまり、これは「顧客をサポートし、払い戻しを処理する」ということでした。
新しいStoreKit2 APIの詳細については、「Meet StoreKit 2」をご覧ください。
アプリ内購入のサーバー側ロジックの構築の詳細については、「サーバーでのアプリ内購入の管理」をご覧ください。
本日はお聴きいただきありがとうございます。残りのWWDCをお楽しみください。
【打楽器】
コメント