簡単に言うと: すべての返金が不満を持った顧客によるものとは限りません。かなりの割合は予測可能な不正パターンであり、トライアル不正(プレミアム機能を使い、課金された瞬間に返金を求める)、使用後返金(必要なものを手に入れたら、お金を返すよう求める)、そして数ヶ月間アクティブなアカウントからの「誤購入」申告などがあります。こうしたパターンはデータに痕跡を残します。そして異議を申し立てられるケースこそ、対応期限を逃したことで失ってはならないものです。
この違いが重要な理由
すべての返金を同じもの、つまり「対応に失敗した不満な顧客」として扱ってしまうと、誤った結論を導き、誤った対応をとることになります。
一部の返金は本当に不満を反映しており、その解決にはプロダクトやUXの改善が必要です。しかし、アプリの返金不正には別の分析が必要です。なぜなら、一部の返金行動には通常の顧客行動とは異なるパターンが見られることがあるからです。
この2つをひとまとめにすると、両方の問題が見えなくなります。実際よりもプロダクトの評価を悪く見せてしまう一方で、回収や異議申し立てが可能な返金が、正当な顧客による返金と同じ扱いに埋もれてしまいます。
顧客の不満と不正の可能性があるパターンを分けて考えることが、どちらに対しても有効な対策を講じるための第一歩です。
主な不正パターン
監視すべきパターンがいくつかあります。
トライアル不正。 ユーザーが無料トライアルを開始し、必要なプレミアム機能を使用した後、トライアルが有料サブスクリプションに切り替わるタイミングで返金を求めるケースです。タイミングと利用履歴は、取引を評価する際に有用な指標となります。
使用後返金(ユース・アンド・リファンド)。 ユーティリティ系アプリや一度だけ価値を提供するアプリでよく見られます。ファイルの変換、機能のロック解除、ウォーターマークの削除、サービスの利用など、特定の1つの作業を完了させる目的でサブスクリプションを購入し、その作業が終わるとすぐに返金を求めるケースです。重要な指標は、消費された価値と返金リクエストのタイミングとの関係です。
利用歴の長いアカウントでの「誤購入」。 数ヶ月間アクティブで、相応の利用履歴があるアカウントから、誤って購入したという申告があるケースです。本当の誤購入も実際に起こりますが、アカウントの利用歴や使用履歴は、誤購入による返金リクエストを評価する際の追加的な判断材料となります。
常習的な返金者。 少数ではありますが、複数回の購入にわたって繰り返し返金を行うユーザーもいます。1回の返金は単発の出来事ですが、返金の履歴が長く続いている場合は、調査する価値のあるパターンです。Appleの消費データには、累計返金額、アカウントの利用歴、累計購入額、そのほか判断材料となる消費関連情報が含まれる場合があります。
それぞれが残す痕跡
これらのパターンが自動化において重要な理由は、必ずしも見えないものではないという点にあります。返金リクエストを評価する際に使用される取引データや消費データに、こうしたパターンが現れることがあります。
利用量が多く、すぐに返金を求める。 大量の利用の直後に返金リクエストがある場合、使用後返金のパターンである可能性を示唆します。
トライアル切り替え時の課金に合わせた返金。 トライアルの切り替え時期に集中する返金リクエストは、トライアル不正を評価する際の有用な指標となります。
アカウントの利用歴と「誤購入」申告の不一致。 長期間アクティブに利用されているアカウントが誤購入を申告する場合、不正と即断するのではなく、確認する価値のある不一致として扱うべきです。
繰り返される返金履歴。 返金履歴が繰り返されている顧客は、単発の出来事ではなくパターンを表している可能性があります。
Appleの現行のconsumption-requestドキュメントには、アカウントの利用歴、消費状況、プレイ時間、累計返金額、累計購入額、配信状況、サンプルコンテンツやトライアルが提供されたかどうかなどのフィールドが含まれています。
つまり、デベロッパーは対象となるAppleの返金リクエストに対応する際、利用可能な証拠を使ってより多くの文脈情報を提供できるということです。Appleは、この消費情報が返金の判断材料になるとしており、デベロッパーはCONSUMPTION_REQUESTに対して12時間以内に対応することが推奨されています。
不正による返金こそ異議を申し立てる価値がある理由
ここが戦略上のポイントです。
本当の不満による返金には、通常別の対応がふさわしいといえます。正当な顧客の不満に異議を申し立てると、顧客体験を損なうおそれがあり、根本的なプロダクトの問題の解決にもつながりません。
サブスクリプションの返金不正の可能性がある場合は事情が異なります。利用可能な証拠が、相当な利用量や価値の提供、あるいは顧客の申告内容と矛盾する繰り返しの返金行動を示している場合、そのケースはより詳細な確認が必要になることがあります。
重要な違いは、デベロッパーが一方的にすべての返金を拒否できるわけではないという点です。最終的な判断を下すのはAppleとGoogleであり、すべての返金においてデベロッパーが対応できる機会があるわけではありません。
Appleの場合、対象となるCONSUMPTION_REQUEST通知により、デベロッパーはAppleが返金判断に使用する消費情報を提供できます。
Google Playの場合、デベロッパーによる確認が必要なチャージバックでは、PendingRefundReviewNotificationが発生することがあります。デベロッパーはReviewRefund APIを通じて、24時間以内に返金に関する意向や関連する購入・利用の証拠を提供できます。
そのため、アプリの返金詐欺は、単に返金を拒否する問題としてではなく、検知と証拠収集の問題として捉えるべきです。
できること・できないこと
限界について正直に言うと、次のとおりです。
できないこと: 顧客が返金をリクエストすることを阻止することはできませんし、一方的に拒否することもできません。最終的な判断を下すのはAppleとGoogleです。
できないこと: すべての不正な返金に異議を申し立てることはできません。すべての返金でデベロッパーが確認できる機会があるわけではなく、利用可能なプロセスはAppleとGoogleで異なります。
できること: 対象となるすべてのリクエストに対し、所定の対応期限内に、利用可能な消費データや購入の証拠を提示して対応することができます。
できること: どのアプリで、どのような理由で、どの商品で、どのような顧客行動が見られるかといったパターンを特定し、本当のプロダクト上の課題と不正の可能性を区別することができます。
サブスクリプションの件数が多いチームの場合、返金不正検知ソフトウェアを活用することで、返金イベントを一元管理し、疑わしいパターンを特定し、対象となるリクエストが未対応のまま放置されないようにすることができます。
RefundSensorはこの両方に対応します。対象となるAppleのCONSUMPTION_REQUESTイベントやGoogle Playのチャージバック確認に対応する一方で、分析機能によって返金をアプリ別・理由別に分類し、不正の可能性があるパターンが単一の「返金率」の数字に埋もれることなく可視化されます。
これにより、対応期限を逃して確認可能なケースを失うことがなくなり、問題のどれだけが不正の可能性によるもので、どれだけが本当のプロダクト上の課題によるものかを把握できるようになります。
参考リンク
https://developers.google.com/android-publisher/voided-purchases
https://developer.android.com/google/play/billing/provide-refund-and-chargeback-suggestions
https://developer.android.com/reference/com/android/billingclient/api/BillingFlowParams.Builder
https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken
https://developer.apple.com/documentation/appstoreserverapi/consumptionrequest
https://support.google.com/googleplay/android-developer/answer/17068375
自社の返金率のうち、どれだけが不正の可能性に関連しているかを確認しましょう。RefundSensorは、対象となるAppleおよびGoogle Playの返金アクティビティを監視し、返金イベントをアプリ別・理由別に分類することで、不正の可能性が全体の返金数値の中に埋もれてしまうのを防ぎます。 無料で始める
よくある質問
返金システムを利用して対価を支払わずに価値を得る行為のことで、トライアル不正、使用後返金、または虚偽の「誤購入」申告などが含まれます。これは、返金が正当とされる本来の不満とは区別されるものです。
返金リクエスト自体を防いだり、ご自身で拒否したりすることはできません。最終的な判断を下すのはストア側です。できることは、対象となるリクエストに対して不正を明らかにする消費データ(コンサンプションデータ)を用いて対応すること、そしてより分かりやすいトライアルやペイウォールの設計によって、トライアル不正を根本から減らすことです。
データの傾向から判断できます。利用量が多いにもかかわらず即座に返金を求めるケース、トライアルから有料プランへの切り替え時期に合わせた返金、長期間アクティブなアカウントからの「誤購入」申告などが典型例です。理由別の返金分析を行うことで、こうしたパターンを可視化できます。
価値が明確に提供されていながら、申告内容の根拠が弱い不正のケースです。本当の不満による返金は、通常そのまま認めるほうが良いでしょう。問題は、不正による返金が、対応期限を逃すことでそのまま承認されてしまうケースが多いことです。
リクエスト自体を防ぐことはできませんが、正確な消費データを提出することで、Appleが判断の際に不正の可能性を考慮するための情報を提供できます。期限内に対応しなければ、Appleはこうした情報を得ることができません。
