私が知っている2つのチームが同じアプリを運用しており、同じ月の返金率として3.1%と5.8%を報告していました。どちらも嘘をついていたわけではありません。指標の定義が異なっていただけで、しかもその定義を誰も書き留めていなかったのです。
これが、モバイルアプリの返金分析について機能紹介ページには書かれていない点です。その数値の信頼性は、背後にあるアトリビューションルール次第であり、ほとんどのダッシュボードはどのルールを使っているかを明示していません。
そこで本記事では、各ツールが何をしてくれるのか、そしてそれらを信頼する前に確認すべき1つの方法論的な質問を取り上げます。追跡の仕組みだけをさらに深掘りしたい場合は、 App Store返金の追跡方法でApple側について詳しく解説しています。
要点まとめ
コホートアトリビューションは期間アトリビューションに勝ります。返金は、それが発生した月ではなく、購入が行われた月に対してカウントしましょう。
返金のタイムラグは数週間、時には請求期間まるごとに及びます。「今月の返金率」を表示しているダッシュボードは、不完全な数値を示しているということです。
チャージバックは返金ではありません。RevenueCatも、チャージバックを返金としてカウントしないと明言しているため、別途フィードが必要です。
ストアのコンソールは無料ですが、トレンド分析には弱いツールです。Appleはレポートを提供し、Googleは1日の上限付きAPIを提供しています。
モバイルアプリの返金率を追跡するための最良のツールとは、分母を公開しているツールのことです。
まず、定義の問題について
アプリの返金率を追跡する方法には2通りあり、両者は一致しません。
期間法:3月に発生した返金を、3月に請求された取引数で割る方法です。構築は簡単ですが、3月の返金が1月の購入に紐づくことが多いため、不正確です。
コホート法:1月に請求されたすべての取引のうち、それ以降どれだけの割合が返金されたかを見る方法です。数値が常に変動し続けるため、より難しくなります。
Apphudはこの点を正直に明記しています。分母はその期間に請求された取引数で、分子はその後(期間が締まった後も含め)返金された件数です。これはコホート方式であり、実際の返金の挙動と一致しています。
そのため、締め切り(カットオフ)を設定する必要があります。月額サブスクリプションは30日から45日程度で安定しますが、年額プランは数か月にわたって変動し続けます。10日経過した数値と90日経過した数値を比較するのは、ノイズ同士を比較しているに過ぎません。
無料プラン:ストアコンソール
まずはここから始めましょう。費用はかかりませんが、ほとんどのチームはここで止まってしまいます。
App Store Connect。Sales and TrendsとFinancial Reportsで返金データが得られ、Financial Reportは実際の支払額と一致します。期間ベースで手作業が必要なうえ、商品やチャネルによるセグメント分けはできません。月次の簡易チェックには十分ですが、どのペイウォールが収益を失っているかを見つけるには役立ちません。
実はより優れた無料のフィードはコンソールの中にはありません。AppleのGet Refund Historyエンドポイントは、顧客ごとに返金されたすべての取引をページ分けされた形式で返し、自社のデータウェアハウスに取り込むことができます。レート制限があり、Appleはポーリングよりも通知の利用を推奨しているため、これは照合用として扱うべきです。
Google Play Console。こちらもFinancial Reportに加え、指定期間内に返金・チャージバック・取り消しされた購入を一覧表示するVoided Purchases APIがあります。1日あたり6,000回、30秒あたり30回という上限があるため、リアルタイム処理ではなく、定期的なバッチ処理向けに設計されています。
どちらのコンソールにも、トレンド分析において共通の弱点があります。実際に成立した返金のみを報告し、リクエストされた件数は報告しないため、自分が阻止したリクエストを把握することはできません。
RevenueCat
すでにサブスクリプションをRevenueCat経由で運用しているなら、これが基本の選択肢になります。
返金率はRevenueCatのベンチマーク指標の1つで、最初の請求期間中に返金された有料サブスクリプションの割合を、自社のストア・カテゴリ内の他アプリと比較できます。このベンチマーク機能こそが有用な部分であり、比較対象のない生の数値だけでは対応策を講じにくいものです。同社のState of Subscription Appsレポートは75,000以上のアプリを対象としており、中央値は3%から5%前後となっています。
また、承認・却下・取り消し・解決待ちを分けて表示するApp Store Refund Requestsチャートもあります。これはリクエストレベルのデータであり、ほとんどのツールが扱っていない部分です。
注意点が2つあります。開発者ではなくGoogle側が承認したPlayの返金は、反映までに最大24時間かかることがあり、取り消し(revoke)のチェックが入っていない返金はそもそも検出されません。さらに、RevenueCatはチャージバックを返金としてカウントしません。購入ステータスは更新されますが、返金率には反映されないのです。
Adapty
セグメント分析においては他社より優れています。返金の追跡は日別、プラン別、商品別、獲得チャネル別に分解されており、実際に問題を発見できる切り口になっています。全体では問題なく見えても特定のチャネルだけ悪い数値が出ている場合、それはプロダクトの不具合ではなく、メッセージングの不具合です。
同社のベンチマークは11,000以上のアプリにわたる19億ドル分の追跡済み収益に基づいており、カテゴリ間の差は無視できないほど大きく、教育・ヘルスケアは4.7%から5.1%程度、旅行・公共料金系は1.5%から2.1%に近い水準です。年額プランは週額プランよりも返金が多く発生します。ハードペイウォールはおよそ5.8%で、フリーミアムの3.4%より高くなっています。
注意点は同社の他の機能と同様です。この優れた分析機能は、Adapty SDKを導入していることが前提となっています。
Apphud
規模は小さく、料金も安価で、方法論について珍しいほど明確に説明しており、それだけでも候補に入れる価値があります。ドキュメントではコホートロジックを隠さずに明示しています。リアルタイムダッシュボード、18種類ほどのサブスクリプションイベント、他社に比べてマーケティング色が薄いのも特徴です。
取締役会で説明責任を果たせる数値が欲しいなら、機能リストの長さよりも明確さのほうが重要です。
返金・チャージバック専用の追跡ツール
ここにギャップがあります。サブスクリプションプラットフォームは成立した返金のみをカウントします。どれも対応期間(レスポンスウィンドウ)の内側に存在していないため、どれだけのリクエストを阻止できたか、あるいは返金理由別の勝率を教えてくれません。
これは別のデータセットであり、リクエストに実際に対応している仕組みがあって初めて存在します。 Refund SensorはApple返金リクエストとGoogle Playのチャージバックレビューをケースとして追跡し、タイムライン、結果、守られた収益を両ストア分、1つのダッシュボードで表示します。返金に至らなかったリクエストも可視化できます。
これは置き換えではなく、組み合わせる価値があるものです。コホート分析にはサブスクリプションプラットフォームを、リクエストレベルのトレンドにはモバイルアプリ向けの収益保護ソフトウェアを使いましょう。問いが異なるため、どちらか一方だけでは不十分です。
チャージバックを別途追跡する
チャージバックの傾向は返金の傾向の一部ではなく、両者を同一視することが、モバイルアプリの返金追跡において最もよく見られる間違いです。
Google Playではシグナルが異なります。Real-time developer notificationsは、何かが無効化された際にvoidedPurchaseNotificationを、チャージバックに開発者の対応が必要な際にpendingRefundReviewNotificationをプッシュします。Voided Purchases APIには、fraud、friendly_fraud、chargebackを含む9種類の値を持つvoidedReasonフィールドがあります。これが無料で得られる最も近いチャージバックのトレンドラインです。
Appleの場合は、取り消し理由(revocation reason)付きのREFUND通知に加え、成立しなかったケース向けのREFUND_DECLINEDおよびREFUND_REVERSEDがあります。
偽りのないチャージバックのトレンドを把握するには、voidedReasonがchargebackに等しいものを商品別に時系列でプロットしましょう。そのうえで、fraudとfriendly_fraudは別々にプロットしてください。これらのアカウントは繰り返し発生し、異なる対応が必要になるためです。どのフィードが何を担うかについては、 Voided Purchases API対real-time developer notificationsで解説しています。
モバイルアプリの返金率とチャージバックを追跡する方法
実際に構築するなら、以下の順番で進めます。
アトリビューションルールを決めて書き留める:コホート方式とし、プランの期間ごとにカットオフを明記する。
ストアのフィードを接続する。App Store Server Notifications V2と、Play側のRTDNを使う。これらがなければ、月次のCSVを読むだけになってしまいます。
すべての返金イベントを、今日の日付ではなく元の取引に紐づけて保存する。
リクエストレベルのイベントを追加する。そうしなければ、自分が何を防いだのか決して分かりません。
チャージバックは独自の理由コードで分けて管理する。
全体平均ではなく、自社のカテゴリに対してベンチマークする。
ステップ3は自作のセットアップが静かに破綻しがちな箇所で、ステップ6はダッシュボードが静かに誤解を招きがちな箇所です。どちらも難しくはありませんが、どちらも省略されがちです。
率の話ではなくコストの話については、 返金が実際にアプリの収益に与えるコストでその計算を解説しています。率だけでは、次に何をすべきかは分かりません。
出典
よくある質問
カテゴリ別ベンチマークとApple側のリクエストレベルのチャートが欲しいならRevenueCat、チャネルやプラン別のセグメント分析が必要ならAdapty、最も明確に公開された方法論が欲しいならApphudです。返金に至らなかったリクエストまで把握したい場合は、防御系ツールも追加しましょう。
返金された取引数を、有料取引数で割り、購入が発生した期間に紐づけて計算します。そのうえで、コホートを確定とみなすまでにどれだけ待つかを決めます。月額プランなら30日から45日、年額プランはそれより長めです。
サブスクリプション型アプリの場合、有料取引の2%から5%程度です。教育やヘルス・フィットネス系はこれより高くなり、旅行や公共料金系は低くなります。10%を超えたら、マーケティングを見直すのをやめて、ペイウォールの内容を確認しましょう。
正確には追跡できません。Appleのfinancial reportsには成立した返金のみが表示されます。GoogleのVoided Purchases APIは理由コード付きで無効化された購入を表示するため最も近い手段と言えますが、1日6,000回という上限があり、定期的なバッチ処理が必要です。
ほとんどの場合、アトリビューションのタイムラグが原因です。収益レポートは期間ベースですが、返金率は本来コホートベースであるべきで、すべての返金が反映されて初めて両者は一致します。また、チャージバックが含まれているかどうかも確認してください。ツールによっては除外している場合があります。
Appleは閾値を公開しておらず、自信満々にそれを語る人がいたら疑ったほうがよいでしょう。文書化されているのは、Google Playにおいて返金や異議申し立ての率が持続的に高い場合、アカウントのステータスに影響しうるということです。これは、単なる数値よりもトレンドを追跡すべき強い理由になります。
