アプリ内レビュー誘導：プロンプトのタイミング設計と制限

背景与問題

レビュー数は ASO の土台だが、誘導のタイミングを間違えると低評価を集めシステム制限で誘導自体が止まる。SKStoreReviewController（iOS）と Play In-App Review API（Android）のタイミング定説と制限値を実務として整理する（B 方向）。ストア資産の設計は opc-store-screenshot-creative・opc-aso-2026。

发现

（出典はいずれも 2026-09-18 アクセス）

• 事実（Apple 公式）：プロンプトはユーザーがエンゲージメントを示した直後に出す。オンボーディング中・タスク中断中・クラッシュ直後は避ける。365 日で最大 3 回のシステム制限がある。
• 事実（Google 公式 In-App Review API）：Play Core 1.8.0+。システム側がクォータでスロットリングするため呼び出しは常時可能にしておく。
• 事実：タイミング次第でレビュー獲得数が大きく変わるという実務報告（avanderlee は適切なタイミングで約 3 倍と主張）。定説は増分・クールダウン型トリガー（N 回の成功イベント後+プロンプト間隔を空ける）。
• 推测：一人開発の実装パターン——①「プロンプト前の自前フィルタ」：イベント成功 N 回+日数 M の条件を満たしたら in-app review、未満ならサイレント ②低評価を拾う自前ダイアログは避ける（Apple ポリシー的に不評誘導は推奨されず、in-app review に一本化）③トリガー条件はリモート設定（Remote Config/自分の API）に置き、配信後に調整できるようにする。

结论

（調査継続中）

待办 / 下次继续

• 自アプリのトリガー条件（成功イベント種別×回数×クールダウン）を v1 で定義して実装する。
  
• プロンプト表示数→レビュー投稿数の転換を週次で測る計測を追加（c-app-store-connect-analytics と接続）。
  

下次继续：トリガー条件 v1 の定義から。クラッシュ直後回避は opc-crash-reporting-setup のトリアージと組み合わせる。

关联

opc-store-screenshot-creative opc-aso-2026 c-app-store-connect-analytics opc-crash-reporting-setup