App Storeの返金: 開発者が返金による収益損失を防ぐ方法

App Storeの返金: 開発者が返金による収益損失を防ぐ方法

たいていは経理部門から始まります。誰かがApp Storeの支払額がdashboardの数字と合わないことに気づき、調べ始めます。明確な間違いは見つかりません。ただ、6週間前の購入の一部が、いつの間にかAppleへ戻っていただけです。

ただ、そのお金自体は、実は問題の中で最も重要ではない部分です。返金は、あなたのスタックを通過する途中で5つも6つもの他のシステムに影響を及ぼしますが、どのシステムも手を挙げて知らせてはくれません。だからこそ Appleの返金対策はサーバー通知を軸に構築する必要があります。月次レポートではありません。それでは手遅れです。

決めるのはAppleです。それだけです。どんなツールもそれを変えることはできず、私たちのツールも例外ではありません。しかし「Appleが決めた」と「3週間後にあなたが知った」の間には大きな余地があり、避けられたはずの損失のほぼすべてがそこにあります。

重要ポイント

● App Storeの返金はすべてAppleが承認または却下します。開発者の役割は、情報を提供し、結果を記録することだけです。

● Apple自身のドキュメントによれば、顧客が返金をリクエストすると、あなたのサーバーにCONSUMPTION_REQUESTが送信されます。回答期限は12時間です。

● V2通知のエンドポイントを設定していなければ、通知は届きません。想定より少ない支払額が、最初の手がかりになってしまいます。

● Appleは消費データを判断の「インプット」と呼んでいます。繰り返しますが、インプットであって、特定の結果を約束するものではありません。

● REFUND、REFUND_DECLINED、REFUND_REVERSEDは互換性のあるものではありません。これらを同じように扱うコードは、有料顧客を締め出す結果になります。

● サブスクリプションが返金されると、失うのは1回分の課金だけではありません。すでに見込んでいた将来の更新もすべて失われます。

App Storeの返金とは?

簡単に言えば、App Storeの返金とは、アプリであれアプリ内課金であれ、Appleが顧客にお金を返すことです。同じ金額があなたの収益から消えます。Appleが審査し、Appleが決定し、最終的に(すぐではないこともありますが)サーバーイベントを通じてあなたのシステムに伝わります。ただし、実際に受信する仕組みがあればの話です。

返金と混同されがちなものが2つあり、正直なところ間違えやすい点です。キャンセルは今後の更新を止めるだけで、すでに支払われた分はそのままです。チャージバックはまったく別物で、カード発行会社に対して起こされる異議申し立てであり、Appleとは無関係です。返金はそのどちらでもなく、それぞれが個別の通知を発生させます。

App Storeの返金プロセスはどのように進むのか?

顧客はreportaproblem.apple.comから、またはStoreKitの返金リクエストAPIをアプリに組み込んでいればアプリ内から手続きを開始します。Appleが申請内容を確認します。利用状況データが必要な場合、あなたのサーバーにはかなり短い期限内での提出が求められます。その後決定が下され、通知としてあなたに届きます。顧客側には24〜48時間以内に連絡があると案内されています。

じっくり考えると印象的なのは、この流れのほとんどがあなた側の人間を一切介さないことです。エスカレーションするキューもなければ、主張を述べるケースもありません。あなたが見ていようといまいと、Appleのシステムが淡々と処理を進めるだけです。

Appleのドキュメントはここを明確にしています。顧客が返金をリクエストすると、製品タイプにかかわらず、V2エンドポイントにCONSUMPTION_REQUESTが送信されます。ただし、そのエンドポイントが実際に設定されている場合に限ります。設定を省略すると、返金が発生しても、素っ気ないREFUNDイベントしか残りません。それだけです。それ以上は何も得られません。

表1: 返金の各段階と開発者のアクション

App Storeの返金はなぜ収益損失を生むのか?

購入金額は誰もが最初に気づく部分です。しかし、それが最も高くつく部分であることはほとんどありません。本当に痛いのは、その下流にあるすべてです。誰も取り消そうと思わなかったアクセス権、とうに消えた収益を前提にしたままのライフタイムバリューの計算、月末に待ち構える照合作業、昨日まではアプリに満足していたのに今日は不満を抱えている顧客からのサポートチケット。

正直なところ、最も打撃を受けるのは予測です。完了した購入を確定収益として扱うモデルは、後から発生する返金の分だけ、毎回必ず狂います。コホートのグラフもおかしくなります。返金されたユーザーはチャーンとして表れるのではなく、コホートから単に消えてしまう傾向があるため、リテンションの数字が実態より良く見えてしまうのです。誰かが嘘をついているわけではありません。ただ、全体像が見えていないだけです。

Appleの返金リクエスト中に開発者がコントロールできることは?

おおよそ3つで、多くの人が想像するより短いリストです。Appleが実際にあなたのサーバーに到達できるか。要求されたときに何を返すか。回答が届いた後、あなたのシステムがどれだけ速く反応するか。何が欠けているかに注目してください。決定です。それはあなたのリストに載ることはなく、Appleは消費データが複数のインプットのひとつであって決定票ではないと、かなりはっきり述べています。

少し考えてみる価値のある点があります。何も答えないサーバーは中立ではありません。顧客側の言い分と履歴だけをAppleに渡し、あなた側の天秤には何も載せないことになるのです。

消費情報が返金審査に与える影響

CONSUMPTION_REQUESTが届いたら、 Send Consumption Informationエンドポイントを通じて回答します。ペイロードは本当に小さなものです。同意の有無、購入品が提供されたか、サンプルがあったか、どの程度使用されたか、そしてあなたが望む結果。Appleの表現では、これは決定に「情報を与える」ものです。情報を与える、であって、決定する、ではありません。

同意は一度チェックを入れて終わりというものではありません。このAPIを通じて顧客の個人データを共有する前に有効な同意が必要であることをAppleは明示しており、同意がなければそもそも回答すべきではないというのがガイダンスです。まず法的な準備、コードはその次です。

初めてのときにほぼ全員が戸惑う点がひとつあります。消費率のフィールドは、消耗型、非消耗型、非更新型サブスクリプションにのみ適用されます。自動更新サブスクリプションでは、Appleが経過時間からその数値を自ら算出するため、このフィールドに何を送っても無視されます。この仕組みについては Appleの消費リクエスト期限に関する解説でさらに詳しく掘り下げていますので、実装中の方はぜひご覧ください。

App Storeの返金がサブスクリプション収益に与える影響

サブスクリプションの返金は、1回分の課金サイクルをはるかに超えるコストになります。Apple自身の通知テーブルがそれを示しています。アプリ内APIから返金をリクエストすると自動更新がオフになり、AUTO_RENEW_DISABLEDサブタイプとともにDID_CHANGE_RENEWAL_STATUSが発火します。現在の課金は取り消され、将来の課金はすべて存在しなくなります。

ひとつのイベントで、継続収益に2つの別々の打撃。ここで語るどの点よりも過小評価されがちな部分です。さらに、返金された購読者が静かにチャーンとして分類されてしまうと、課金上の結果をプロダクトの失敗として扱うことになりますが、実際はそうでないことがほとんどです。アクセス権もこれに連動させるべきです。返金されたサブスクリプションは速やかにアクセス権を失い、取り消された返金は同じ速さでアクセス権を取り戻すべきです。

App Storeの返金モニタリングが重要な理由

要約すると、App Storeの返金モニタリングは3つのことです。返金イベントを発生した瞬間に捕捉すること、それぞれを実際のトランザクションと実際のユーザーに紐づけること、そして後から実際に検索できる履歴を保持すること。これを省くと、返金は数週間後の財務レポートで初めて表面化します。アクセス権を変更すべきだった時点をとうに過ぎ、回答期限もすべて閉じた後です。

実際に機能する構成には、通常次の要素が含まれます:

● App Store Server Notifications V2が確実に届き、署名がきちんと検証されていること

● トランザクションが実際のユーザーに紐づいていること。通常は購入時に設定したappAccountTokenを利用します

● アクセス権とサブスクリプションの状態が、夜間バッチではなくイベントそのものから変更されること

● 顧客ごとの返金履歴があり、繰り返しのパターンが隠れずに見えること

● 期限が営業時間ではなく実際の時計で計測されること

後になって、ほとんど偶然に気づく副次的なメリットもあります。適切に保存されたこれらのイベントは、どの製品、どの価格帯、どのストアフロントで最も損失が出ているかを正確に示してくれます。集めるつもりのなかったデータですが、結局は頼ることになるデータです。

Apple返金自動化で手作業を減らす方法

Appleの返金自動化は、繰り返しの多い中間部分を引き受けます。通知の受信と検証。トランザクションを正しいユーザーに解決すること。消費ペイロードを構築し、期限内に送信し、Appleが最終的に下した決定を記録すること。率直に言っておくと、自動化がしないこともあります。決定への影響力を買うことはできず、返金を求める人が減るわけでもありません。それは自動化の仕事ではないのです。

正直なところ、自動化を採用する理由はタイミングに尽きます。12時間は寛大に思えますが、通知が日曜の午前2時に届き、誰かがそれに気づかなければならないとなれば話は別です。Appleのsandbox環境の期限は本番よりさらに短く、Appleがこの処理を誰が担うと想定していたかを強く示唆しています。

表2: 手動と自動の返金処理の比較

開発者がモバイルアプリの収益を返金から守る方法

モバイルアプリの収益保護は、正直なところ、実践してみるとかなり地味です。お金が動く前に、価格と更新条件を明確に示す。プレッシャーの中でも信頼できるトランザクション記録を保持する。例外なく、すべての購入にユーザー識別子を付ける。文書化された同意がある場合は必ず消費リクエストに回答する。そして、返金イベントが直接アクセス権の変更を駆動するようにする。誰かが手作業で対応することを覚えていてくれるのを当てにしてはいけません。いずれ忘れられるからです。

価格、更新日、解約方法を最初から明確に示すペイウォールは、申請される前にリクエストの一部を静かに減らします。これは予防ではありません。本当の意味では、ここで挙げたどれも予防ではありません。ただ、避けられたはずの部分を縮めるだけです。回答できたはずのリクエスト、更新が遅れたアクセス権、たまたま誰も気づかなかったパターン。

返金管理でよくある間違い

V2エンドポイントを設定していないことが最も高くつく間違いです。他のほぼすべてが、そもそもそれが存在することを前提にしているからです。それ以外では、同じ失敗がチームを問わず繰り返されがちです。署名を検証せずにペイロードを信用する、文書化された同意なしに消費データを送る、購入時のappAccountTokenを省略して、見ているトランザクションが誰のものか誰も自信を持って言えなくなる。

もうひとつの失敗は技術的なものではまったくありません。組織的なもので、それゆえに見つけにくいのです。返金が経理だけの問題として扱われ、イベントがプロダクトやエンジニアリングに届かず、返金されたユーザーがフルアクセスを保持し続ける。ときには数か月にわたって。理由はただ、誰も2つの部門をつないでいなかったからです。

まとめ

返金はApp Storeの仕組みのバグではありません。その一部であり、恒久的なもので、今後も変わりません。チームごとに実際に異なるのは、その損失のうちどれだけが本来避けられたものだったかです。見逃した通知。誰も回答しなかったリクエスト。何週間も放置されたアクセス権。すべて自ら招いたものです。そして、誰かが直すと決めれば、すべて直せるものでもあります。

多くのチームが本格的なワークフローを構築するのは、ほぼ同じタイミングです。返金の件数が、それまで静かに手作業で吸収していた誰かの処理能力をついに超えたときです。もし今まさにその状況にあるなら、 App Storeのセットアップ手順は、この段階ではほとんどが設定作業です。作り直しではありません。

これらのルールの出典

● Apple Support: アプリやコンテンツの返金をリクエストする は、顧客がリクエストを申請する方法と24〜48時間の期限について説明しています。

● Apple Developer: Send Consumption Information は、CONSUMPTION_REQUESTのトリガー、12時間の期限、同意のルール、Appleによるデータの利用について説明しています。

● Apple Developer: notificationType は、REFUND、REFUND_DECLINED、REFUND_REVERSED、CONSUMPTION_REQUEST、および自動更新の変更について説明しています。