初めてアプリの収益損失を監査したとき、私はあやうく「すべて問題ない」と報告するところでした。返金率は2.4%で、どのベンチマークから見ても良好な数字でした。チームはApple側の期限内にconsumption requestへ回答していました。書類上は、回収すべきものは何もないように見えました。
それでも、半ば意地のような気持ちでもう一つクエリを実行してみました。Appleがすでに返金したトランザクションに対して、現在も有料のentitlementを保持しているユーザーは何人いるか。答えは41人でした。有料サブスクライバーが約900人のアプリでの話です。結果が信じられず、2回実行し直しました。
これは、ユーザーベースの約5%が毎月無料で製品を使い続けていたということであり、その間もdashboardは「問題なし」の表示のままでした。しかも返金率は一切変化しませんでした。このentitlementの修正については、別途 返金後にアクセス権を取り消す方法でまとめています。
App Storeの返金からサブスクリプション収益を取り戻す方法を考えているなら、まずそこから始めてください。なぜなら、返金そのものは、あなたのお金が実際に流出している4つの経路のうち、最も小さな一つにすぎないからです。ここでは全体像を説明します。
4つのバケツ:価値の高さで順位付け
私はこれを4つのバケツとして捉えていますが、労力に対する見返りの順位は、たいていの人が予想するものとは違います。
漏れ(leak): 返金されたのにアクセス権を失わなかったユーザー。修正コストは最も低いのに、最も見落とされがちです。
防御(defense): 証拠を添えてAppleのconsumption requestに回答すること。ソフトウェアで自動化できる部分であるため、どのベンダーもこのバケツについて語ります。
ウィンバック(win-back): 返金したユーザーや解約したユーザーを再獲得すること。成果が出るまで最も時間がかかりますが、Appleは今年、ひそかにこれをやりやすくしました。
リトライ(retry): 手を出さずにいれば自然に回復する課金失敗のケース。
ほとんどのチームはバケツ2にしか取り組んでいません。驚くような発見は、1と3の中にあります。
バケツ1:漏れを見つける。所要時間は1時間
クエリの内容はおおよそ次の通りです。過去12か月にrevocation date(取り消し日)があるすべてのトランザクションを取得し、entitlementテーブルと結合して、今もアクティブなアクセス権を持っているユーザーを数えます。
もし答えが本当にゼロなら、このセクションは読み飛ばしてかまいません。しかし、ゼロでなければ、何かがそれを止めるまで毎月流出し続けるサブスクリプション収益を見つけたことになります。Appleは支払いを取り消します。しかしAppleはあなたのデータベースには一切手を加えません。この2つは、あなたが自分で接続するまでつながりません。消耗型アイテム(consumables)の場合はさらに厄介です。一度使われてしまったアイテムは、StoreKitが取り戻せるものが何もないからです。
(私自身、これを何か月も間違えていました。通知ハンドラはREFUNDイベントを誰も見ないテーブルに記録していただけでした。ログに記録することは、対処することではありません。)
修正方法:REFUNDを検知し、revocation dateの時点でアクセス権を取り消し、REFUND_REVERSEDにはアクセス権の再付与で対応します。Appleは顧客からの異議申し立てを受けて、自ら返金を取り消すことがときどきあります。そのこと自体で顧客に不利益を与えるべきではありません。
ついでにもう一つクエリを実行してください。サーバー通知を一切受け取っていない返金の数を数えます。これがゼロでなければ、エンドポイントが壊れており、バケツ2も機能していません。
バケツ2:まだ影響を与えられるリクエストを守る
AppleはCONSUMPTION_REQUESTを受けてからconsumption dataを送信するまで、約12時間の猶予を与えています。必須フィールドが3つ、任意フィールドが2つ、preferenceが1つあり、現在は消耗型だけでなくすべての商品タイプが対象になっています。
このバケツについては他所で散々語られているため、ここでのアドバイスは短くまとめます。すべてのリクエストに回答すること。商品が明らかに提供され、十分に利用されていたものは却下すること。本当に誤操作によるものは認めること。誠意ある譲歩はコストが低い一方、すべての返金と争うことはそうではありません。Appleはあなたの履歴に基づいて評価を重み付けするからです。
誰も言及しない前提条件が、証拠です。証明できるものしか守れません。7週間前の購入について「実際にどれだけ利用したか」に誰も答えられないなら、どんな自動化も助けにはなりません。これは、どのベンダーを使うかにかかわらず、埋めておく価値のあるデータモデリングのギャップです。
コスト面については、 返金が実際にアプリの収益にどれだけコストをもたらすかで、返金された各ユーザーの背後にある獲得費用を含めて計算しています。
バケツ3:サブスクライバーを取り戻す
ここで、サブスクリプション収益の保護は「守り」から脱却します。そしてこれは、ここ1年でAppleがあなたに有利な形へと作り直した領域でもあります。
Win-back offer。 WWDC24で発表され、iOS 18以降で利用可能な新機能です。App Store Connectでサブスクリプション商品ごとに設定し、対象条件(最低課金期間、前回のサブスクリプションからの経過期間、オファー間に2〜24か月の待機期間)を決めます。配信自体はAppleが行います。顧客のManage Subscriptionページ、あなたの商品ページ、パーソナライズされたおすすめ、場合によってはTodayタブの編集枠に表示されます。
もう一度読んでみてください。Appleは、あなたが決して電子メールでは届けられない場所で、解約済みサブスクライバーにあなたの割引を表示してくれるのです。上限は、1サブスクリプションあたり350オファー、1ストアフロントあたりアクティブ5件です。アプリ内では、対象になった時点でStoreKitがwinBackOfferメッセージを発火し、renewal info内のeligibleWinBackOfferIDsで利用可能なオファーが確認できます。Appleの win-back設定ガイドに対象条件のフィールドがまとめられています。
Promotional offer。 1サブスクリプションあたり最大10件まで設定でき、iOS 12.2の頃から存在します。サーバー側からのJWS署名が必要です。win-backより手間はかかりますが、ターゲティングを完全にコントロールできるため、返金理由が「特定の国での価格の問題」のような具体的な情報を示している場合に効果を発揮します。
Offer code。 アプリの内外どちらでも利用できます。そのため、返金してアンインストールしてしまったユーザーに届く、現実的にはほぼ唯一の手段となります。それ以外のユーザーにはアプリ内で届けられますが、このユーザー層には届きません。
Extend a Subscription Renewal Date。 個人的には過小評価されている機能だと思います。AppleのサーバーAPIを使うと、 サブスクライバーの更新日を先延ばしにできます。1件単位でも、一括でも可能です。私たちは、不具合のあるリリース後の誠意として使っています。誰かが課金バグについてサポートにメールしてきたら、1か月延長する。コストはほぼゼロで、どんなクーポンよりも効果的です。回避できた返金は、取り戻した返金に勝ります。
一つ例外があります。もし誰かが製品そのものではなく、予期しない課金に驚いて返金した場合は、割引で追いかけるべきではありません。まずpaywallの文言を修正し、ユーザーが自然に再発見するのを待ちましょう。 App Store返金管理では、その運用面について扱っています。
バケツ4:自然に解消する解約
Appleは課金失敗後、最大60日間、あるいは顧客がカード情報を修正するかキャンセルするまでリトライを続けます。この期間内にサブスクリプションが更新されれば、有料サービスは回復した日から継続されます。
つまり、失われたように見えるサブスクリプション収益の一部は、実際には失われておらず、保留になっていただけです。これを台無しにする要因は2つあります。有効にしていない猶予期間と、実質的に「解約してください」と言っているようなdunningメールです。リテンションツールにお金をかける前に、この2つを確認してください。
自分をごまかさずに測定する
コホートアトリビューションのない返金管理は、自信満々の誤った結論を生み出します。
各返金は、返金が発生した時点ではなく、元の購入が発生した期間に帰属させてください。そして、コホートが成熟するのを待ちます。月額プランなら30〜45日、年額プランならさらに長い期間が必要です。返金リクエストは数か月後に来ることもあるからです。
これは、サブスクリプションの返金トラッキングが難しくなるポイントであり、多くのdashboardがひそかにごまかしている部分でもあります。11月に受け入れられたwin-backは、8月に解約したコホートに属するものです。あなたのレポートがそれらを結び付けていないなら、あなたの回収数値は実体のないものです。
追うべき数値は1つではなく4つです。
コホート別の返金率。
期限内に回答したリクエスト数。
返金理由別に分けた、守られた収益。
未解消のentitlement漏れ。これはゼロに向かって推移し、その後もゼロを維持すべき数値です。
もし1つだけをdashboardに載せるとしたら、それは漏れの件数です。ゼロでない限り明確に「間違っている」とわかる、唯一の数値だからです。
ソフトウェアが本当に役立つ場面
バケツ2とバケツ4はきれいに自動化できます。バケツ1は一度自動化すれば、あとは監視するだけで済みます。バケツ3は設定と判断の領域であり、判断の部分をツールが代わりにやってくれることはありません。
Refund Sensorは、両ストアでの防御面を担い、対象となるすべてのリクエストに期限内でトランザクションの証拠とともに回答し、守れた収益を記録します。ただし、誰かを呼び戻してくれるわけでも、わかりにくいpaywallを修正してくれるわけでもありません。それができるのは、あなた自身だけです。
参考情報
よくある質問
試す順に4つの方法があります。まず、返金されたトランザクションでアクセス権を保持し続けているユーザーを見つけて、それを無効にします。次に、すべてのconsumption requestに12時間以内に回答します。そして、win-backオファーやpromotional offerで解約したユーザーを呼び戻します。最後に、課金のリトライと猶予期間を確認してください。解約の一部は実は永続的ではなかったケースもあるからです。
直接的にはできません。Appleは顧客からの異議申し立てを受けて、まれに自ら返金を取り消し、REFUND_REVERSED通知を送信することがあります。この通知が届いたら、アクセス権を復元してください。これは自分で争わなくても得られる回収です。
win-backオファーは自動更新をオフにした解約済みサブスクライバーを対象としており、対象条件は課金期間と前回のサブスクリプションからの経過期間によって決まります。返金されたサブスクリプションは解約扱いになるため、通常は対象になります。ただし、ルールを設定して確認してください。
entitlementクエリです。作業は1時間程度で、ベンダーもアプリのリリースも不要です。これまで実行したすべてのアプリで、結果はゼロではありませんでした。
返金額そのものよりも多くなります。一般的な割合は、課金トランザクションの2%から5%程度です。実際のコストには、そのユーザーの獲得にかけた費用、通知を見逃した場合のentitlementの漏れ、そして次のユーザー獲得で払いすぎる原因となる過大評価されたLTVが加わります。
いいえ。漏れの修正は無料でできますし、それはバグです。ソフトウェアは、あなたが対応できていないリクエストに回答してくれますが、それは確かに重要な問題ではあるものの、最初に取り組むべき問題ではありません。
