product-analytics

product-analytics skill の概要

product-analytics の用途

product-analytics skill は、AI エージェントがプロダクト KPI の定義、指標フレームワークの選定、ダッシュボード設計、リテンション・コホート・ファネル・機能利用状況データの解釈を行うためのスキルです。単発のグラフ案ではなく、構造化された指標設計が必要なプロダクトマネージャー、グロースチーム、創業者、アナリスト、AI 支援型のプロダクトチーム向けに作られています。

たとえば「このプロダクト段階では何を測るべきか」「この機能は本当に使われているのか」「ダッシュボードにはどのリテンション指標を載せるべきか」「あいまいな North Star 目標を、測定可能なインプット指標にどう落とし込むか」といった問いに使えます。

product analytics に向いている業務

この product-analytics skill が特に力を発揮するのは、分析だけでなく意思決定も含む Product Management のワークフローです。相性がよい用途は次のとおりです。

• AARRR、North Star、HEART の各フレームワークからの選定
• pre-PMF、成長期、成熟期プロダクト向けの KPI 定義
• 経営向け、プロダクトヘルス、機能利用状況のダッシュボード構成作成
• サインアップ、アクティベーション、機能接触を基準にしたコホートリテンション分析の設計
• プロダクトローンチやライフサイクル段階に照らした指標変動の解釈

一方で、SQL 生成だけが必要な場合、ウェアハウスモデリング、特定 BI ツールのセットアップにはあまり向きません。このスキルが提供するのは product analytics の考え方とテンプレートであり、完全な analytics engineering スタックではありません。

このスキルが実務で使いやすい理由

このリポジトリには、単一のプロンプトファイル以上の内容が含まれています。中核となる SKILL.md では、スキルを使う場面とワークフローを説明しています。references/metrics-frameworks.md には、AARRR、North Star、HEART の実用的なフレームワークガイドがあります。references/dashboard-templates.md では、経営向け、プロダクトヘルス、機能利用状況の各ビューに対応したダッシュボードレイアウトを提供しています。scripts/metrics_calculator.py は、CSV データからリテンション、コホート、ファネルを計算する軽量なコマンドライン補助ツールです。

この組み合わせにより、product-analytics skill は計画段階にも一次分析にも使いやすくなっています。

product-analytics skill の使い方

product-analytics のインストールと最初に読むファイル

GitHub リポジトリからインストールするには、利用している skill manager の GitHub インストールフローを使います。たとえば環境が npx skills add に対応している場合、実用上のコマンドは次のとおりです。

npx skills add alirezarezvani/claude-skills --skill product-analytics

インストール後は、次の順番でファイルを読んでください。

1. SKILL.md — スコープ、ワークフロー、KPI ガイド、解釈ルール
2. references/metrics-frameworks.md — AARRR、North Star、HEART、Goals-Signals-Metrics
3. references/dashboard-templates.md — ダッシュボード構成と KPI ブロック
4. scripts/metrics_calculator.py — リテンション、コホート、ファネル向けの任意の CSV ベース計算

この順番が重要なのは、このスキルがフレームワーク駆動で設計されているためです。参照ファイルを飛ばすと、エージェントがプロダクト段階に合った分析ガイドではなく、一般的な KPI リストを出してしまう可能性があります。

product-analytics をより有効に使うための入力

product-analytics を効果的に使うには、プロダクトの背景、段階、ユーザーセグメント、必要な意思決定をエージェントに伝えます。弱いプロンプトの例:

Help me create product metrics.

より良いプロンプト:

Use the product-analytics skill. We are a B2B SaaS product in growth stage. Users sign up, invite teammates, create a project, and publish reports. Our suspected activation event is “created first project with at least one teammate.” We need a product health dashboard for the PM and leadership team. Define a North Star candidate, input metrics, activation and retention KPIs, and dashboard layers. Call out missing data and risks.

リテンションやファネルを扱う場合は、イベント名、コホートの基準、期間、セグメントを含めます。たとえば、signup cohort と first-feature-use cohort では答えられる問いが異なります。

実分析でのおすすめワークフロー

いきなり指標を出させるのではなく、まずスキルにフレームワークを選定または比較させるところから始めます。使いやすい流れは次のとおりです。

1. プロダクト段階とビジネスモデルを定義する
2. 指標フレームワークを選ぶ: 成長ファネルには AARRR、戦略的整合には North Star、UX 品質には HEART
3. 最初の価値体験とアクティベーションイベントを特定する
4. 指標階層を作る: North Star、インプット指標、ガードレール、診断指標
5. 対象読者に合わせてダッシュボードのレイヤーを設計する
6. コホート、リテンション、ファネル、機能利用状況分析を実行または依頼する
7. 指標の変動を意思決定、実験、計測不足に翻訳する

CSV エクスポートがある場合は、エージェントにリテンションやファネルコンバージョンを計算させる前に scripts/metrics_calculator.py を確認してください。このスクリプトは、ユーザー、コホート、アクティビティ、ファネルの各カラムが明確であることを前提としています。イベントログが乱雑な場合は、前処理が必要になることがあります。

product-analytics skill FAQ

product-analytics は Product Management 向けか、データサイエンス向けか？

product-analytics skill は主に Product Management、プロダクト戦略、分析計画のためのスキルです。何を測るべきか、なぜ重要か、変化をどう解釈するかを定義するのに役立ちます。コホートやファネルの設計を中心に、アナリストのワークフローを支援することもできますが、ウェアハウスモデル、実験基盤、統計ノートブックの代替にはなりません。

プロダクトマネージャーにとって最大のメリットは、あいまいな目標を、プロダクト段階に合った KPI と、アナリストや BI チームが実装できるダッシュボード要件に変換できることです。

通常の分析プロンプトより何が優れているのか？

一般的なプロンプトでは、DAU、MAU、リテンション、コンバージョン、チャーン、売上といった幅広い指標リストが返ってくることがよくあります。このスキルは、フレームワーク選定、段階別 KPI ガイド、ダッシュボードのレイヤー設計、コホート比較、機能利用状況の解釈といった、より方針の明確な product analytics ワークフローをエージェントに与えます。

付属の参照ファイルによって、あいまいさも減ります。ゼロからダッシュボードを作り出すのではなく、エージェントは経営向け、プロダクトヘルス、機能利用状況のテンプレートを出発点として使えます。

このスキルを使わないほうがよい場面

production SQL の作成、tracking SDK のデバッグ、dbt モデル設計、Amplitude、Mixpanel、Looker、GA4 の設定など、課題が純粋に技術的な場合は、product-analytics を主ツールとして使うべきではありません。それらのツールに必要な指標やイベントを定義する支援はできますが、ベンダー実装ガイドではありません。

また、プロダクト文脈がまったくない場合も使用は避けたほうがよいです。ライフサイクル段階、ユーザージャーニー、主要イベント、ビジネス目標がないと、出力は高レベルで実行しにくいものになります。

product-analytics skill を改善する方法

より強い文脈で product-analytics の結果を改善する

最も重要な改善は、入力の質を上げることです。次の情報を含めてください。

• プロダクト種別: SaaS、マーケットプレイス、コンシューマーアプリ、社内ツール、コンテンツプロダクト
• 段階: pre-PMF、成長期、成熟期、立て直し、ローンチ
• 中核となるユーザージャーニー: サインアップ、オンボーディング、価値体験、反復行動
• ビジネスモデル: サブスクリプション、従量課金、広告、取引手数料、エンタープライズ営業
• 現在の課題: アクティベーション、リテンション、マネタイズ、利用定着、品質、チャーン
• 利用可能なデータ: イベントログ、CRM フィールド、請求データ、アンケート、サポートチケット

これにより、product-analytics skill が不適切なフレームワークを選ぶのを避けられます。たとえば、UX 品質の課題には HEART が合う一方、獲得から売上までのファネル診断には AARRR のほうが適しています。

よくある失敗パターンに注意する

弱い出力でよくあるのは、KPI が多すぎる、意思決定につながらない vanity metrics が並ぶ、オーナーのないダッシュボード設計になる、単一スナップショットだけでリテンションを分析する、といったケースです。エージェントには次を分けるよう求めてください。

• 経営指標と診断指標
• 先行指標と遅行結果
• セグメント単位のシグナルと混合平均
• 機能への接触と真の機能利用
• 初回利用と反復または継続利用

優れた product analytics の回答は、各指標がどの意思決定を支えるのかを示すべきです。指標にオーナー、しきい値、アクションパスがない場合は、エージェントに修正を依頼してください。

最初の出力後に反復する

最初の回答が出たら、狙いを絞ったフォローアップで改善します。

• “Reduce this to 5 executive metrics and 10 diagnostic metrics.”
• “Rewrite for a pre-PMF product with low traffic.”
• “Add instrumentation events needed to calculate each KPI.”
• “Separate dashboard views for PM, leadership, and growth team.”
• “Identify which metrics are guardrails versus success metrics.”
• “Turn this into an experiment readout template.”

データに基づく作業では、必要に応じてフレームワーク出力とリポジトリ内の scripts/metrics_calculator.py を組み合わせ、その結果を単に割合として言い換えるのではなく、文脈に沿って解釈するようスキルに依頼してください。