🍎
【iOSアプリ】評価レビューのハック大全📕誰でもいけるレビュー平均4.5✨️※評価4.83、レビュー数1.2万のアプリ実例
開発実例:評価4.83、レビュー数1.2万のアプリ🌸
- 4.83まで伸ばすことができた
- 4.0以降が大変
- ⭐2以下は全体の1％を維持
このアプリで試すために日本語、英語の記事をあさって実際にためした施策を紹介🐰
レビューの基礎ルールと推奨事項
App Store Connect ヘルプ
- ユーザーはアプリを1〜5個の星で評価することができる
- アプリ開発者はレビューへ返信ができる、なんどでも更新できる
- ユーザーにレビューのリクエストを任意のタイミングで表示できるAPI
- このAPIでの要求は年3回の上限がある
- アプリの評価をリセットすることができる
Human Interface Guidelines
Appleの推奨するデザイン上のベストプラクティス
-
評価を求めるのは、ユーザがアプリやゲームをある程度使用したあとにする
- 例えば、ユーザが何らかのゲームレベルや重要なタスクを完了したときにプロンプトを表示
- 初回起動時やオンボーディング中は、ユーザがまだアプリの価値をよく理解していなく意見もまとまっていないため、評価を求めないようにする
- ユーザがアプリを使用していないうちに評価を求められたという印象を与えると、否定的なフィードバックが残される可能性が高くなる
-
タスクを実行したりゲームをプレイしているユーザの邪魔をしないようにする
- フィードバックの要求は、ユーザの操作を妨害したり、ユーザが負担に感じたりする場合がある
- 評価を求められても煩わしいと思わない自然な小休止や停止のタイミングを探す
-
ユーザにしつこく要求しない
- 評価を繰り返し要求すると、ユーザは不快に思い、アプリの感想にマイナスな影響を与えかねない
- 次回の要求まで少なくとも1～2週間空ける
そもそも高評価を目指すべきか？
1.ネガティブな観点
低いとユーザーにダウンロードされない
アプリマーケティング研究所さんの2015年の記事を引用元にする記事が日本には多かったので紹介
- アプリをダウンロードする前にレビューを読む人は7割
- 評価が「★１」のアプリを見つけた場合、9割のユーザーはダウンロードしない
2.ポジティブな観点
高いとユーザーにダウンロードされやすくなる
同上の記事から▽
- 「★２」が「★４」に改善されると、ダウンロード率が5.4倍に上がる
高いとユーザーに発見されやすくなる
こちらは実体験から。
- ブラウザ上でのオーガニック検索に高い効果がある
- AppleがそもそもSEOに強く、例えばGoogleで検索キーワードに沿ったアプリを上位表示してくれる。特定のキーワードで評価TOPに立つと、SEOや検索広告がんばらなくても特定のキーワードで1ページ目にアプリの導線が表示される。上位に表示されると、他社(アプリ)がSEOや記事で乗っかってくるので被リンクにつながっていく。広告課金無しでこのくらいの結果になる▽
- App Storeで広告頑張らなくてよくなる(AppStoreで上位表示される）
- App Storeの上位表示はいくつかの条件が考えられるが(App Analyticsをみていてレビュー以外の重要指標について仮説があるので、別途書きたい📓)、少なくともレビューの高さは指標の一つなので、レビュー高ければ、Apple Search Ads (ASA：ppStore内広告) にお金をかける量が少なくて済む。
- AppStoreで「今日のアプリ」などにピックアップされる
- 実際この初回のピックアップでAppStore内で120万PVの効果
- 実際この初回のピックアップでAppStore内で120万PVの効果
高いと自分のやる気につながる
- うまくいかないことが多くても、レビューや書き込みがポジティブであれば、次の開発の動機になる🔥
高評価にたどり着くには？
体制編
- 不具合があった場合にすぐに修正できる体制とルール
- 1がつくのは基礎的な不具合が多い（または嫌がらせ
- 基礎的な不具合は、アプリが落ちる、根本的なタスクが達成できない
遅い、UIがわかりづらい、コンテンツが少ないなどをDeveloperは気にしがち。でもこれらは±3で、1にはならないことが体感多い。そこは最初置いといても大丈夫- 不具合やクラッシュを0にするのは無理なので、リカバリーできる体制をつくる
- ※これはほんとに重要で、凝っはんの
- 不具合があっても特定にうごける余力、優先度を変える意思決定、即PRとリリースができるルールなど
- リリースしないルール決め
- 金曜日にリリースすると土日で不具合が発見できた場合、対処が遅れるので避ける
- ユーザーの利用頻度の高い時間、ユーザーの繁忙期にリリースをしない
- 例:受験に使われる英語アプリの仕様を、受験期間やテスト期間に実施しない
ユーザーとのコミュニケーション編
- ユーザーの期待値調整
- ユーザーとのインターフェースの変更について事前告知を行う
- とにかく急に変更しない。突然の変更はよいUIや改善だとしても一定の反発がある
- 事前告知で批判がでることは織り込んでおく。（否定的な意見がきて取りやめると、その後くせになるし、運営への不信につながる
- ユーザーとのインターフェースの変更について事前告知を行う
- toCの場合は、「実験してます」というユーザーとのコミュニケーションも効果的
- 実際に試した事例▽
- 不安定だが早く機能をユーザーに使ってもらってFBがほしかったので、リリース時の使い方ガイド、お知らせ、不具合時のダイアログなどので、「実験してます」を強調
アプリ内の実験中の記載
エラー画面に実験中の記載
- 体制の共有（個人開発や少人数での開発であること
- toCアプリの場合、ユーザーは大手やキャリアのアプリだと思いがち。一方で個人開発や少人数のサービスだと積極的に発信することで、ユーザー側の許容度は思った以上に効果がある。※嘘はだめ
実装編
- 【なにを】ユーザーへのリクエストレビュー
- ユーザーにレビューのリクエストを任意のタイミングで表示できるAPI
- 【どこで】マジックナンバーを見つけて、その体験の導線に用意する
- 「ポジティブな体験後にレビューを依頼する」とセオリーでは言われるが、実際にどうやってその場所を検討するのか？マジックナンバーを見つけるのがおすすめ。実際そこで設定してから一度も変更してない。
- 【どうやってみつける？】GAでコホートをつくって、継続率のポイントをみるのがおすすめ
参考記事：アプリのリテンションレート（継続率）を改善するマジックナンバー分析のススメ
OPS（運用）編
-
AppStoreのコメント対応
-
コメント対応は絶対にする。コミュニケーションをとることで、低評価を修正してくれたり、解決しなくても★3まであげてくれることがある。
-
【優先度】低評価＞高評価への対応
- ついほめてくれる高評価へのレスを返したくなるが、対応すべきなのは低評価コメント。
-
【誰に？】未来のユーザー
- 低評価をくれたユーザーはもちろん、そのコメントをこれから読む未来のユーザーを意識してわかりやすく書く。第三者が読んでもわかりやすく書く
-
【何を？】細かく書く
- 運営が対処したこと
- 次回起こった場合の対処方法
- 次不具合があったときの連絡先
-
【例外】やばいものはやばい
- ほんとに違う内容の場合は報告していく
- ユーザーも間違うので別のアプリの機能について言及してレビューかいてるなどがある。
-
-
AppStore外のユーザー対応
- 解決したら、レビューも依頼しとく
不具合が原因のものは必要な情報の取得がレビュー欄だとむずかしいので、サポートのコミュニケーションができる場所に誘導するといいと思い
やめといたほうがいいもの編
・サクラ
・インセンをだしたレビュー記載
BANされたり、実際使ってバレるのでそういった指摘のレビューが増えます。ちゃんとやったほうがProductもよくなります。
マーケ編
・ここは別途記事をまとめます。
（採用中）
- 絶賛メンバー募集中です
- 一緒にサービス開発やりませんか？
Discussion