Zenn
👀

In-App Review APIでアプリ内レビューフローを設ける際の留意点

2021/01/09に公開
Android
C++
Java
Unity
Google Play
tech

概要

Google Play In-App Review API便利ですよね

少ない実装でアプリ内でPlayStoreのレビューを行うことができるようになり、ユーザのレビュー品質の向上が見込まれます

この記事では実装と運用の留意点をまとめます

留意点

実装方法

前提は以下です

  • Android 5.0(APIレベル 21)以上 or Chrome OS のデバイス
  • Google Play ストアがインストールされている
  • 該当apkがplay consoleにアップロードできる環境がある

実装はこちら(アプリ内レビューを統合する（Kotlin または Java）)に全て書かれてるので割愛します。めちゃ簡単です。

レビュー訴求UIについて

こちら(設計ガイドライン)です

  • カードの既存のデザインを、サイズ、不透明度、形状、その他の特性を含め、一切の改ざんや変更をせずにそのまま表示する。
  • カードの上や周囲にオーバーレイを追加しない。
  • カードとカードの背景を最上位レイヤに置く。カードが表示されたら、プログラムでカードを削除しないでください。カードの削除は、ユーザーの明示的な操作、または Play ストアの内部メカニズムに基づいて自動的に行われます。

レビュー訴求する時は常に最前面にUIを表示し、UIに手を加えることはできない・してはいけない

アプリ内でレビュー訴求するタイミング

こちら(アプリ内レビューをリクエストするタイミング)です

  • 評価ボタンや評価カードを表示する前または表示中に質問をしない（「アプリを気に入りましたか？」といったユーザーの意見に関する質問や、「このアプリを 5 つ星と評価していただけますか？」といった予断を与える質問）。

このガイドラインに沿うと「アプリを評価しませんか？」はセーフのように感じられますが、こちら(割り当て)によると

API をトリガーするよう「行動を促す」オプション（ボタンなど）を設けないでください。

とあるので、そもそもレビュー訴求用のボタンなどは表示せず、レビュー訴求したいタイミングでレビューフローを呼び出すのが正しい使い方みたいです
(ユーザがレビュー済みかが分かれば柔軟性ある使い方ができるんですけど、それが取得できると他の部分で悪用できそうなので厳しそうですね・・・)

ただ、このガイドラインを守っていないからリリース審査に落ちるということはなく、あくまでガイドラインということでした

実装時のレビューフローの考え方

こちら(アプリ内レビューフローを開始する)によると

アプリ内レビューフロー中にエラーが発生した場合、ユーザーに通知したり、アプリの通常のユーザーフローを変更したりしないでください。

とあり、実際に実装すると以下のようでした

  • レビュー訴求UI内で「レビュー完了」・「未レビュー」・「また後でを選択」のどのアクションをしてもonCompleteが呼ばれ、何が起こったかアプリは知ることが出来ない
  • なのでonCompleteで「レビューありがとうございました」などの文言を表示しても、レビュー後でない可能性もあることを考慮する

あくまでアプリの動きはそのまま、レビュー訴求のみ行われるようにするのが理想みたいでした

割り当て上限

こちら(割り当て)です

Google Play により、ユーザーにレビュー ダイアログを表示する頻度に時間制限付きの割り当てが設定されています。

  • レビュー訴求の適切なタイミングはGoogleが取り仕切る
  • なので特定のアカウントに大量のレビュー訴求は行わないし、ユーザが求めてもレビュー訴求UIが出ない時がある(本来そういったユーザは自分でストアレビューするため)

開発時にレビュー訴求UIを確認したい場合は次項を見てください

開発中のUI確認方法

こちら(アプリ内レビューをテストする)です

  • 内部アプリ共有・内部テストトラックを利用する
  • FakeReviewManagerを利用する

の二択があります

内部アプリ共有・内部テストトラックを利用する

実際のリリースではIn-App Review APIを叩きすぎないように割り当て上限が設定されており、何度も確認することができないのですが、この方法では割り当て上限にカウントされずに動作確認することができます

  • 内部アプリ共有を利用する場合はこちらにapkをアップロードして生成されたリンクをAndroidで開くことでアプリ内レビューのテストが可能になります

  • 内部テストトラックを利用する場合はPlayConsoleの該当アプリにて内部テストのリリースを行いましょう

内部テストトラックではレビュー訴求されないことがあったのですが、内部アプリ共有だとしっかり確認できるので軽い確認程度であれば内部テスト共有を使えばよいかと個人的には思います

FakeReviewManagerを利用する

詳細はこちら(FakeReviewManager を使用してテストする)に書かれてます

  • コード上で確実に成功するレスポンスを返すクラスを利用する方法になります
  • UIの確認はできず「成功しました」という結果のみが返ってきます

余分なエラーなど気にせず開発したい場合はこちらを利用すれば毎回apkを生成することなく進められるので、こういったクラスが用意されてるのはありがたいですね

まとめ

4行でまとめます

  • レビュー訴求の適切なタイミングはGoogleが取り仕切る
  • レビュー訴求UIでユーザが何のアクションをしたかは取得不可能
  • レビュー訴求用のボタンなどは表示せず、レビュー訴求したいタイミングでレビューフローを呼び出すのが正しい使い方
  • UI含めた確認をしたい場合は内部テストトラック・内部テスト共有

絶妙な使い勝手ですが、これによってレビューするユーザが増えると健全ですね

Discussion