retention-optimization

retention-optimization 概要

retention-optimization は何をするか

retention-optimization skill は、ユーザーがなぜ戻ってこないのかを診断し、それをリテンション、エンゲージメント、LTV を改善するための優先順位付き計画に落とし込むための skill です。汎用的なグロースの発想会議ではなく、実務で使える retention-optimization ガイドが必要な Product Management の仕事に最適です。

どんな人に向いているか

モバイルアプリ、消費者向けプロダクト、サブスクリプション型プロダクト、または繰り返し利用が前提の体験を担当しているなら、この retention-optimization skill を使う価値があります。特に、「なぜユーザーが離脱しているのか？」「Day 1、Day 7、Day 30 の retention を改善するには何を先に変えるべきか？」といった問いに向いています。

何が違うのか

この repo は、最初に必要な入力についてかなり意見を持っています。retention 指標、アプリのカテゴリ、収益化モデル、現在のエンゲージメント機能を求めるため、施策を提案する前にベンチマークの文脈を押さえる設計です。そのため、広い意味でのプロンプトよりも意思決定に役立ちます。また、app-marketing-context.md への参照があるのも特徴で、最良の結果はプロダクト文脈と獲得文脈を合わせて見ることから生まれる、という示唆になっています。

retention-optimization skill の使い方

インストールと起動の前提

Eronred/aso-skills のリポジトリパスと skill slug retention-optimization を使って、retention-optimization install のフローで導入します。実際には、リテンション戦略、チャーン診断、優先順位付きのエンゲージメント計画を相談したいときに呼び出す想定です。

質問する前に渡すべき情報

「retention を改善して」のような曖昧な依頼ではなく、具体的な入力を渡すのがコツです。最低限、次の情報があると強いです。

• 現在の Day 1、Day 7、Day 30 retention
• アプリのカテゴリ、またはプロダクト種別
• 収益化モデル
• push、streak、リマインダー、コミュニティなど、現在のエンゲージメント施策
• 主な症状。たとえば、サインアップ後に離脱する、初回セッション後に uninstall される、週次の再訪率が低い、など

より強いプロンプトの例は次のようになります。
「私たちはサブスクリプション型の生産性アプリです。Day 1 は 18%、Day 7 は 9%、Day 30 は 4% です。ほとんどのユーザーは onboarding を完了しますが、2回目のタスクを終えません。push は使っておらず、メールのみです。想定される retention のボトルネックを診断し、優先順位付きの retention-optimization 計画を出してください。」

最初に読むファイル

まずは SKILL.md を確認してください。初期評価の流れと benchmark の考え方がまとまっています。自分のワークフローに合わせて retention-optimization skill を調整する場合は、推薦内容を変える前に app-marketing-context.md のようなリンク先のコンテキストファイルも見ておくべきです。インストール後に見えるファイルが 1 つだけなら、それはこの skill が軽量で、プロンプト主導で使う前提だというサインです。

ざっくりした目的を使えるプロンプトに変える方法

「retention を増やしたい」を、制約条件つきのプロダクト課題に言い換えます。ユーザーセグメント、ライフサイクルの段階、最近何が変わったかを明記してください。すでに試した施策も入れると、この skill の出力は診断と自明な改善策を切り分けやすくなります。Product Management 向けの retention-optimization では、通常、優先順位付きのアクション、各アクションがどの retention レバーに効くのか、そしてその提案の前提条件をセットで求めると有用です。

retention-optimization skill の FAQ

retention-optimization はモバイルアプリ専用ですか？

いいえ。ただし、設計として最も明確なのはアプリの retention とエンゲージメント戦略です。SaaS、マーケットプレイス、コンテンツプロダクトでも、問題を繰り返し利用の行動に置き換え、同等の retention 指標を渡せば十分役立ちます。

通常のプロンプトと何が違いますか？

通常のプロンプトは、すぐにアイデア出しへ進みがちです。一方、retention-optimization skill はまずカテゴリのベンチマークと収益化の文脈を求めるため、比較のズレや一般論を減らせます。本当に問題なのが「機能不足」ではなく、プロダクト価値、習慣化、ユーザー期待のミスマッチである場合に特に有効です。

どんなときは使わないほうがいいですか？

主な課題が獲得、価格設定、または一回きりの onboarding コピーであるなら、この retention-optimization skill は使わないでください。リポジトリ自体が onboarding 特有の論点と retention を分けているので、すでにユーザーがプロダクトに到達していて、再訪を促したい場面で使うのが適切です。

初心者でも使いやすいですか？

はい。いくつかのプロダクト質問に答えられるなら使いやすいです。入力項目が明確に整理されているので初心者にも扱いやすい一方で、有用な出力を得るには、プロダクトのカテゴリ、指標、現在のエンゲージメント設計を把握しておく必要があります。

retention-optimization skill を改善するには

ベンチマーク可能な入力を渡す

品質を最も大きく上げるのは、正確な retention の期間とプロダクトカテゴリを渡すことです。「retention が悪い」のような弱い入力では、返ってくるのは一般的な改善策だけです。たとえば「fitness アプリで D1 22%、D7 8%、D30 3%」のように入力すると、skill は現実的な期待値と比較しやすくなり、正しい課題の優先順位をつけやすくなります。

どこで離脱しているかを明示する

ユーザーが消える地点を伝えてください。インストール後、サインアップ後、初回タスク後、1週目後、請求イベント後などです。retention-optimization skill は、習慣ループが壊れる段階を特定したときに最も力を発揮します。なぜなら、同じ retention スコアでも失敗の原因はまったく違うことがあるからです。

最初の計画を反復する

最初の回答のあとに、次の 3 つのどれかを追加で聞くと精度が上がります。最有力の診断仮説、実施価値のある最小テスト、対象コホートを最も動かしそうなエンゲージメント機能です。そうすることで、retention-optimization ガイドが広いアイデア集に変わるのを防ぎ、実行可能な内容に保てます。

ありがちな失敗パターンに注意する

最も多いミスは、文脈なしで「retention のアイデア」を求めることです。もう一つは、retention と monetization、onboarding を混ぜてしまい、1つの提案ですべて解決できると思い込むことです。最初の出力が浅く感じたら、セグメンテーション、最近のプロダクト変更、既に存在するエンゲージメント機能を追加してから、もう一度 skill を実行してください。