不具合のあるアプリアップデートは返金の波を引き起こします。売上金に届く前に食い止める方法を解説します

リリースが不具合を抱えたまま出荷されると、返金はあなたのクラッシュダッシュボードよりも先に始まります。不具合のあるアプリアップデートは、人々を苛立たせるだけではありません。それは返金を求める具体的な口実を与え、低価格の購入では、その金額はあなたが失うものの中で最も小さな部分です。すでに燃やした計算資源、請求されたサードパーティの API 呼び出し、確保したストレージは、その売上とともに戻ってはきません。

救いとなるのは、壊れたリリースが、数週間ではなく数分で抑えられる数少ない返金要因の一つだということです。両ストアともアップデートを段階的に出荷し、途中で止めることを許しており、このたった一つの制御が、影響を受けるユーザーが一握りで済むか、それとも売上金に対する返金の波になるかの分かれ目です。返金の波が実際にどれだけのコストになるのか、各ストアで不具合のあるリリースを食い止める方法、そして異議がすでに申し立てられた後にあなたが唯一発言できる二つの短い時間枠を解説します。

なぜ不具合のあるアプリアップデートは返金に変わるのか

起動時のクラッシュ、読み込まれないペイウォール、昨日は動いたのに今日は動かない機能。そのどれもが、有料の顧客に返金を求めるはっきりとした口実を与え、返金はその反応の丁寧な形にすぎません。丁寧でない形が銀行のチャージバックです。どちらもあなたにコストを負わせ、ユーザーの一部にしか壊れていないリリースでも、売上金に現れるほどの数を生み出しかねません。

失うお金は売上だけではない

購入が返金されると、売上金額は顧客に戻ります。戻ってこないのは、その購入を処理するためにすでに費やしたすべてです。処理を実行した計算資源、使用の瞬間に請求されたサードパーティの API 呼び出し、確保したストレージ、そしてすでにクリエイターへ支払った分配金は、消えます。低価格の消耗型アイテムでは、これらの埋没コストに銀行手数料の可能性を加えると、顧客が払った額を上回ることもあります。

返金の波は返金率も動かす

返金は単なる売上ごとの損失ではありません。カードネットワークも両ストアも、あなたの売上が返ってくる比率を注視しています。壊れたリリースひとつがその比率を跳ね上げると、避けたい精査を招きかねません。つまり不具合のあるアップデートのコストには、金額だけでなく、あなたが費やす信用も含まれます。

App Store で不具合のあるリリースを止める方法

Apple の封じ込めツールは段階的リリースであり、その価値のすべては、ほとんどのユーザーが壊れたビルドを目にする前にブレーキを引けることにあります。

段階的リリースは七日間かけて進む

バージョンアップデートで段階的リリースを有効にすると、Apple は自動アップデートを有効にしているユーザーの無作為な一部にそれを配信します。公開は決まったスケジュールで上がっていきます。初日は 1%、続いて 2%、5%、10%、20%、50%、100% と、七日間かけて進みます。序盤の数日は利用者基盤のごく一部にしか触れないため、二日目に見つかった欠陥は、同日に全体公開した場合よりもはるかに少ない人にしか届いていません。

おかしいと感じた瞬間に一時停止する

不具合のあるアプリアップデートがすり抜けてしまっても、段階的リリースはいつでも一時停止できます。Apple は最大 30 日間、回数の制限なく一時停止を認めており、その枠は累積されます。10 日間停止して再開しても、まだ 20 日分の停止が残っています。再開すると、公開は止まった日から続きを進めます。一時停止しても、すでにビルドを持っているユーザーから取り上げることはないので、一時停止は修正と迅速な審査とセットにしましょう。

Google Play で不具合のあるリリースを止める方法

Google Play は二つのブレーキを用意しています。一つはまだ公開中のリリース向け、もう一つはすでに全員に届いたリリース向けです。

進行中の段階的公開を停止する

Google Play の段階的公開では、一定の割合のユーザーへ公開し、自分のスケジュールで割合を上げていけます。問題を見つけたら、そのリリースを開いて「公開の管理」を選び、次に「公開の停止」を選びます。新たなユーザーはそのバージョンを受け取らなくなり、すでに受け取ったユーザーはそのままです。もしそのビルドが結局は問題なかったとわかれば、同じ公開を止まったところから再開します。

すでに 100% まで公開されたリリースを停止する

Google Play では、すでに全体へ公開されたリリースを停止することもできます。これは段階的公開のブレーキにはできないことです。停止すると、以前公開されていて全体へ行き渡ったあなたのアプリのバージョンが、まだ停止したビルドを使っていない新規および既存のユーザーに対して自動的に代わりを務めます。注意すべき制限が二つあります。トラック上の最初のリリースは停止できないこと、そして壊れたバージョンが十分に長く公開されていてほとんどのユーザーがすでに更新している場合、停止してもほとんど効果がないことです。被害はすでに行き渡っているからです。

返金と異議がすでに動き出しているとき

公開を段階的にすることは、何人が不具合のあるアプリアップデートにぶつかるかを抑えます。しかし、すでにぶつかってしまったユーザーからの返金や異議に対しては何もしません。顧客がいったん返金を求めれば、ストアがその手続きを進め、あなたの発言権は狭くなります。

ほとんどの返金はあなた抜きで決まる

Google Play の 48 時間のセルフサービス返金、サポートによる返金、無効化された購入は、すべてストアが自らのポリシーに基づいて決めます。証拠を出す窓口も、不服申し立てもありません。それらについては、あなたの記録は返金そのものと、すでに飲み込んだコストです。あなたが動ける唯一の場所は予防であり、だからこそ公開のブレーキが重要なのです。

二つの時間枠だけがあなたの入力

あなたに何かを求める手続きは二つだけです。顧客が消耗型アイテムや自動更新サブスクリプションの返金を求めると、Apple はあなたのサーバーに CONSUMPTION_REQUEST を送り、消費データを最大 12 時間待ちます。Google Play では、審査が必要な争いのある購入が 24 時間のカウントを始め、あなたは orders.reviewrefund API を通じて回答します。どちらの時間枠も逃せば、決定はあなた抜きで下されます。どちらの時間枠も、不具合のあるリリースを取り消せるわけではありません。その余波に対応できるだけです。

封じ込めのチェックリスト

どれも風変わりなものではありません。壊れると予想したリリースだけでなく、すべてのリリースで走らせる短い手順です。

• あらゆるアップデートを App Store の段階的リリースと Google Play の段階的公開を通じて出荷し、同日の全体プッシュは決してしないこと。
• 最初の低い割合の数日間、オーディエンスが守れるほど小さいうちに、クラッシュと返金のシグナルを見守ること。
• 本物の欠陥が現れた瞬間に、App Store の段階的リリースを一時停止するか Google Play の公開を停止し、それから修正して再提出すること。
• Google Play ですでに全員に届いた欠陥については、全体へ公開されたリリースを停止し、以前のバージョンに代わりを務めさせること。
• Apple と Google の通知フィードを用意し、あらゆる消費リクエストと返金審査にそれぞれの時間枠内で回答できるようにすること。
• リリース全体を通じて返金率を追うこと。急増は、ロールバックがもう手遅れになりつつあるというシグナルだからです。