Android の In-App Review API:うっとうしくならずに評価を頼む方法

Android の「評価してください」プロンプトの多くは、ボタンが2つあるカスタムダイアログだ。片方は Play ストアのリスティングを開き、もう片方は閉じる。アプリ起動時、あるいは任意のセッション数の後に表示され、ユーザーが実際にやろうとしていたことを中断させる。「評価する」をタップした人はアプリを離れて Play ストアに移動し、そこでゼロからレビューを書かなければならない — このひと手間が、せっかく捉えた意欲の大半を殺してしまう。「今はしない」をタップした人は何も教えてくれておらず、それでもおそらく来週また聞かれることになる。

Google の In-App Review API は、この問題の「仕組み」の部分を解決する。アプリの上にネイティブの評価シートが現れ、アプリを離れることなく星を選び(任意で一言添えて)、元いた場所にそのまま戻れる。UX の部分までは解決しない — いつ表示するかは、どう表示するかよりも依然として重要だ — が、「どう表示するか」を間違える言い訳はなくなる。

実際の仕組み

この API は Play Core(com.google.android.play:review-ktx)の一部だ。事前に ReviewInfo オブジェクトをリクエストしておき、表示準備ができたらフローを起動する。

val manager = ReviewManagerFactory.create(context)

manager.requestReviewFlow().addOnCompleteListener { request ->
    if (request.isSuccessful) {
        val reviewInfo = request.result
        manager.launchReviewFlow(activity, reviewInfo)
            .addOnCompleteListener {
                // The flow is finished — you don't get a signal on
                // whether the user actually rated. Treat this as "done,"
                // not "succeeded."
            }
    }
}

つまずきやすい点が2つある。まず、requestReviewFlow() は静かに失敗したり、ダイアログを一度も表示せずに返ってきたりすることがある — Google は同じユーザーがこのシートを見る頻度を制限しており(アプリごとにおおよそ年1回、正確には非公開でコントロールもできない)、テスト中の呼び出しの多くは何も表示せずに完了する。次に、完了コールバックはユーザーが評価したか、スキップしたか、あるいはクォータがダイアログを完全にブロックしたかに関わらず発火する。onRatingSubmitted は存在しない — これは意図的な設計で、アプリが結果に応じて機能をロックしたり催促したりできないようにするためだ。

本当に重要な部分:タイミング

API がどれだけ摩擦のないものでも、悪いタイミングで表示すれば意味がない。よく見る失敗パターンは、onCreate() の直後に requestReviewFlow() を呼ぶことだ。表示回数が多いほどレビューも増えるという発想だが、実際は逆だ。ユーザーがまだ何の感想も持っていないうちに尋ねており、しかもその日アプリを開いた本来の用件の真っ最中に尋ねてしまっている。

うまくいくタイミングは、アプリが実際に役目を果たしたことが明らかになった直後だ。Mintly を作っていて分かったのは、フォーカスセッションが終わってストリークが伸びたのを見た瞬間 — それも最初のセッションではなく、アプリがすでにある程度の信頼を得たセッションだ、ということ。アプリのカテゴリを問わず通用する具体的なルールをいくつか挙げる。

• 固定のセッション数ではなく、完了したポジティブな成果でトリガーする。 家計簿アプリなら1か月をきれいに締めくくった後、習慣化アプリならストリークの節目、リマインダーアプリなら本当に役立った救済の後 —「5回目のセッション」ではない。
• エラー経路では絶対にトリガーしない。 何かが失敗した直後や、ユーザーがフローから離脱した直後は、頼むには最悪のタイミングだ。
• API 自体がレート制限していても、自分でも制限する。 Google のクォータによりほとんどのリクエストは静かに何も起きないが、それでも自前のトリガーロジックは条件を満たすたびに発火するのを避けるべきだ。あるユーザーに対してフローが一度完了したら、実際に表示されたかどうか自分側で確認できなくても、数か月は再度呼び出さない。
• 自前の事前プロンプトと組み合わせない。 本物のプロンプトへのアクセスを絞り込む「アプリは気に入っていますか?」的なカスタムダイアログは、API がなくそうとしている二段階の摩擦をそのまま再導入してしまい、しかも本物のプロンプトを誰に見せるかを恣意的に選別できてしまう — これはまさに Play の審査ガイドラインが明示的に禁じている操作だ。

できないこと、そしてそれでも人々が試すこと

ユーザーが実際に評価を残したかどうかを検知することも、星の値を読み取ることも、不満なユーザーをフローから遠ざけて満足しているユーザーだけを誘導することもできない。最後のものはよくある要望だが、Play の開発者ポリシーに明確に反する — この API の存在意義は、誰がトリガーしても同じ、フィルタリングされていないシートを見る点にある。「うまくいっていませんか?」というサポート窓口が欲しいなら、レビュープロンプトの前に分岐を作るのではなく、独立した正直なフィードバックリンクとして用意するべきだ。

もう一つ知っておくべき制約は、これが Play 専用だということだ。他の Android アプリストアには同等の保証はなく、そちらでは結局、手動の「評価してください」リンクかストア自体の仕組みに頼ることになる。

クォータを消費せずにテストする

実際のクォータは不透明なので、本番ビルドではなく Play Core のテストツールでテストするのがよい。com.google.android.play:review-ktx のテスト用アーティファクトと内部アプリ共有トラックを使えば、Google の実際のスロットリングを待たずに何度でもフローをトリガーできる。開発中はトリガーをデバッグメニューに組み込んでオンデマンドで発火できるようにし、リリース前にそのショートカットを取り除く。本番では、すべての呼び出しを「投げっぱなし」として扱う — リクエストし、起動し、次に進み、実際にシートを表示するかどうかは Google 側のロジックに任せる。