← 返回列表

レビュー収集の仕組み化：satisfaction gate と「年 3 回上限」の中で待つタイミング設計

2026/9/15

B 方向·OPC 最佳实践（维度：口コミの仕組み）。レビュー 索引に専用課題なし——opc-aso-2026（store 内最適化）の入力側（どう集めるか）を扱う。

背景と問題

App Store/LINE ミニアプリの評価が集客の複利になる（ASO）のは既知——だが「レビューをお願いする」設計を決めていない。出すタイミングを間違えると低評価が集まるか、無視される。

发现（访问 2026-09-15）

  • タイミングの定石：成功体験の直後（タスク完了/保存/streak 達成）に出す——onboarding 中/不満が生まれた瞬間は厳禁（AppTweak、AppFollow）。繰り返し訪問 3-4 回を待つのがコミュニティの合意（UX StackExchange）。
  • 上限は制度で決まっている：Apple の store prompt は365 日で 3 回まで·90 日間隔が実務慣行、clear な dismiss 必須（Wuzzon）。Android は In-App Review API（公式）。
  • satisfaction gate パターン：まず「楽しんでいますか？」と聞き、happy だけ store prompt へ、unhappy は feedback フォームへ振り分ける——悪いレビューが store に出る前の社内フィルタとして広く使われる（Reddit indie 議論）。
  • incentive 禁止：報酬でのレビューは Apple/Google 両方が禁止——誘導は「タイミング」でしか作れない。

推测

  • 我々の主戦場はstore prompt ではなく LINE：PWA+LINE OA 構成なので、satisfaction gate をLINE の 2 タップ（「ここ 1 ヶ月で役に立ちましたか？」→役立った=store レビュー誘導 1 通/いまいち=お困り導線（分診）へ）で実装するのが自然【推测：TTFV 通過後 2 週間が第一の候補時点】。
  • 家族製品のレビューには「親の名前で書くか子の名前で書くか」の特異な課題がある【推测：レビューを書くのは子（決済者）】——レビュー文言の誘導は子の体験（「親が LINE を見てくれた」）に寄せる。

结论

可行动启发：

  1. satisfaction gate を LINE 配信に実装：月次の 1 通（満足度 2 択）→満足者にのみ store レビュー URL（App 出来後）——store prompt の 3 回上限を消費せず、コントロール可能な窓口を持つ。
  2. 第一トリガーは TTFV 通過後 2 週間：opc-onboarding-first-value の初回価値時点を過ぎたユーザーのみ——発火条件を利用ログ（heartbeat）で判定。
  3. 不満ルートは問い合わせ分診に直結：satisfaction gate の「いまいち」回答は分診（お困り）への入り口に——低評価が store に出る前に製品で拾う（opc-inquiry-reduction-playbook と同じ週次 intent 分類に記録）。
  4. レビュー文面の誘導例を用意：「親が自分の LINE で確認できて安心しています」のような具体的シーン文例 3 つを誘導 1 通に添える——書く負担を下げると口コミの質が上がる（報酬を使わない正攻法）。

待办 / 下次继续

关联