ほとんどのインディー iOS アプリは評価に関する課題を抱えています。ユーザーが不満を持っているからではなく、評価を依頼するプロンプトが間違ったタイミングで表示されるか、あるいはまったく表示されないからです。

これは多くの開発者が思っている以上に重要です。評価は単なる社会的証明ではありません。あなたのキーワードランキングを守る価値があるかどうかを、Apple が判断するために使うコンバージョンシグナルなのです。

ここでは、当て推量に頼らず、Apple のルールも破らずにこの問題を解決する方法を紹介します。

評価の課題は、あなたが思っているものとは違います

ほとんどの開発者は、次の 2 つの極端なやり方のどちらかに走りがちです。一切レビューを依頼せずにオーガニックで集まることを期待するか、ユーザーが何かをしている最中に割り込むポップアップでしつこくお願いするか、のどちらかです。

どちらもうまくいきません。

問題はタイミングとコンテキストにあります。初めてアプリを起動したばかりで、まだ何もしていないユーザーは、評価する準備ができていません。エラーに遭遇したばかりのユーザーなら、なおさら準備ができていません。一方で、ワークアウトやクイズ、何らかのマイルストーンといった意味のある行動を完了したばかりのユーザーこそ、ふさわしいタイミングのふさわしい対象です。

Marteso の現在のアプリデータを見てみましょう。Pi Digits はアメリカでの評価が 5 つ星 1 件です。RowTally と CalcBlitz はいずれも評価 0 件です。これらは悪いアプリではありません。プロンプトのタイミングの問題をまだ解決できていないだけのアプリなのです。

Apple のルールを率直に整理します

Apple が用意している正当なツールは 1 つだけです。SKStoreReviewController.requestReview() です。これをコード内で呼び出すと、プロンプトの見た目とレスポンスの処理は Apple が制御します。閉じる動作を上書きすることはできません。レビューと引き換えに何かを提供することもできません。フォームや取引の中で依頼することもできません。

Apple はこれを 1 台のデバイスにつき年間 3 回までに制限しています。この上限は高く聞こえますが、ほとんどのインディーアプリは、オンボーディング直後やセッションの途中といった悪いタイミングで 1 ~ 2 回を無駄に消費してしまい、3 回目が役立つコンテキストで表示されることはまずない、という実態に気づくと話は変わってきます。

年間 3 回ということは、3 回の意図的な判断ができるということです。それぞれを有限のリソースとして扱いましょう。

機能する 2 つのタイミングの窓

レビュー依頼が肯定的なレスポンスを得られる見込みが十分にある瞬間は、2 つあります。

1 つ目は「初回の感動」の瞬間です。これは、ユーザーがそのアプリの本来の目的である中核タスクを初めて達成したときです。オンボーディングのチュートリアルではありません。本当のタスクのことです。Pi Digits なら、円周率の暗唱チャレンジを完了したとき。RowTally なら、完了した編み目のカウントを保存したとき。CalcBlitz なら、タイム計測付きの計算を終えたときです。

ユーザーは、アプリが自分の必要としていたことをしてくれると、たった今確認したところです。それがふさわしい瞬間です。

2 つ目は「マイルストーン」の瞬間です。これは、ユーザーが連続記録や自己ベスト、完了回数といった意味のある進捗の節目に到達したときです。Pi Digits なら、初めて 10 桁を暗唱できたときかもしれません。習慣化アプリなら、7 日間の連続記録かもしれません。

マイルストーンが機能するのは、ユーザーがすでにポジティブな感情の状態にあるからです。あなたは彼らを邪魔しているのではありません。彼らがたった今やり遂げたことを称えているのです。

何もしていない最初のセッションや、コールドスタート、エラー状態のときに依頼するのは避けましょう。

評価の獲得速度がキーワードランキングにつながる理由

これは、ほとんどの ASO ガイドが飛ばしてしまう部分です。

評価は、App Store を閲覧するユーザーにとっての信頼シグナルであるだけではありません。Apple にとってのコンバージョン品質のシグナルでもあります。Apple があるキーワードであなたのアプリをランク付けするとき、その検索を通じてアプリを見つけたユーザーが実際にダウンロードするかどうかを観察しています。ダウンロードしなければ、ランキングは下がっていきます。

評価が 1 件のアプリは、同程度のスコアで 200 件の評価があるアプリよりも信頼しにくいものです。見込みユーザーがあなたのプロダクトページにたどり着いて評価が 1 件しかないのを見たとき、その心理的な抵抗は現実のものであり、Apple はそれをコンバージョンデータから観察できます。

競争の激しいキーワードを狙うインディーアプリにとって、その抵抗こそがランキングの見えない天井になっていることがよくあります。キーワードの選定は正しい。メタデータも正しい。それでもプロダクトページのコンバージョンが、順位を維持できるほどには高くないのです。

信頼に足る評価件数、たとえ 20 ~ 50 件であっても、そこに到達するだけでその抵抗を大きく減らせます。

実践的なプロンプトの実装方法

ほとんどのインディーアプリに私が推奨する構成は次のとおりです。

アプリ内で「感動イベント」を 1 つ特定しましょう。これは、ユーザーが本当の価値を手にしたことを意味するアプリ内アクションです。コードを書き始める前に、まずこれを書き出しておきましょう。

ソフトカウンターを実装しましょう。ユーザーがそのイベントに何回到達したかをカウントします。3 回目、または 5 回目の到達時に requestReview() を呼び出します。最初のセッションでプロンプトを出してはいけません。

マイルストーントリガーを追加しましょう。連続記録や自己ベスト、完了回数などの進捗マイルストーンを 1 つ選び、そこに 2 つ目の requestReview() 呼び出しを追加します。これにより、年間 3 回の枠をすべて使い切ることなく、ユーザー 1 人あたりコンテキスト的に適切な瞬間を 2 つ確保できます。

フローの途中で依頼してはいけません。レビュープロンプトは、ゲームが終わった後、ワークアウトが保存された後、ルートが完了した後といった、自然な小休止のときにだけ表示すべきです。タスクの途中では絶対にいけません。

やってはいけないこと

レビューを買ってはいけません。Apple はそのパターンを検出して削除します。偽のレビューによるランキングシグナルは一時的なものですが、ペナルティのリスクは一時的ではありません。

レビューを依頼するプッシュ通知を送ってはいけません。これは Apple のガイドラインに違反しており、ユーザーにあなたの通知をミュートする習慣をつけさせてしまいます。

ユーザーを App Store のプロンプトに送る前にふるい分けする、サードパーティのレビューゲーティングサービスを使ってはいけません。Apple のガイドラインは、ポジティブな感情を持つユーザーだけをプロンプトに誘導することを禁じています。

設定メニューに常設の「評価する」ボタンを 1 つ追加して、それを戦略だと呼んではいけません。それは戦略ではありません。どのみち評価してくれたであろうユーザー向けの、補助的な手段にすぎません。

結果が出るまでにどれくらいかかるか

評価件数はゆっくりと積み上がっていくものです。それを最も速く加速させる方法は、上で述べたタイミングの窓を的確に押さえ、requestReview() を正しく呼び出すビルドをリリースすることです。

ほとんどのインディーアプリでは、評価を 0 件から 20 件にするのに、アクティブユーザー数にもよりますが、数日ではなく数週間かかります。しかし、その複利効果こそが重要です。評価件数が増えるとプロダクトページのコンバージョンが改善し、それがランク付けされたキーワードのコンバージョンシグナルを改善し、その結果、それらの順位を維持しやすくなるのです。

ASO の仕組みは一貫性を評価します。評価は、その仕組みの一部なのです。