mcpField
P
product-analytics

product-analytics

github.com/yonatangrossデータ・データベース300113 回インストール今日更新
リポジトリ

product-analytics について

実験、継続率、コンバージョンのデータをリリース・延長・中止の判断につなげる、プロダクトマネージャーや分析担当者向けのガイドです。統計の基礎と分析時のよくある落とし穴も扱います。

主な機能

  1. 01A/B テストの評価と判断ルール
  2. 02コホート継続率と機能利用の分析
  3. 03ファネル段階と離脱の診断
  4. 04サンプルサイズ、信頼区間、有意性
  5. 05実験バイアスとデータ整合性の確認

活用シーン

  1. 01実験結果から変更のリリース可否を判断する
  2. 02ユーザーコホートごとの継続率を分析する
  3. 03コンバージョンファネルの主要な離脱箇所を探す
  4. 04実験のサンプルサイズと割り当てを確認する

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yonatangross/orchestkit --skill product-analytics

インストール後、Claude Code で/product-analyticsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

test-cases.json
references/
stats-cheat-sheet.md
rules/
_template.md
_sections.md
cohort-retention.md
ab-test-evaluation.md
funnel-analysis.md

詳細

プロダクト分析

生のプロダクトデータを、リリース・継続・終了の判断につなげるためのフレームワークです。A/B テスト、コホート継続率、ファネル分析、およびこれらの判断を確信を持って行うために必要な統計の基礎を扱います。

クイックリファレンス

カテゴリルール重要度使用する場面
A/B テストの評価1高バリアントの比較、有意性の測定、リリース判断
コホート継続率1高機能の利用曲線、N 日目の継続率、エンゲージメントのスコアリング
ファネル分析1高離脱の原因特定、コンバージョンの最適化、段階のマッピング
統計の基礎1高p 値の解釈、サンプルサイズの決定、信頼区間

合計:4 カテゴリにわたる4つのルール

A/B テストの評価

完全なフレームワークについては、rules/ab-test-evaluation.md を読み込んでください。基本パターン:

## Experiment: [Name]

Hypothesis: If we [change], then [primary metric] will [direction] by [amount]
  because [evidence or reasoning].

Sample size: [N per variant] — calculated for MDE=[X%], power=80%, alpha=0.05
Duration: [Minimum weeks] — never stop early (peeking bias)

Results:
  Control:   [metric value]  n=[count]
  Treatment: [metric value]  n=[count]
  Lift:      [+/- X%]        p=[value]  95% CI: [lower, upper]

Decision: SHIP / EXTEND / KILL
  Rationale: [One sentence grounded in numbers, not gut feel]

判断ルール:

  • リリース — p < 0.05、信頼区間がゼロを含まない、ガードレール指標の悪化なし
  • 延長 — プラスの傾向はあるものの検出力が不足している(再分析ではなく実施期間を延長)
  • 終了 — 帰無結果、またはガードレール指標の悪化

サンプルサイズの計算式、SRM チェック、落とし穴の一覧については、rules/ab-test-evaluation.md を参照してください。

コホート継続率

完全な方法論については、rules/cohort-retention.md を読み込んでください。基本パターン:

-- Day-N retention cohort query
SELECT
  DATE_TRUNC('week', first_seen)  AS cohort_week,
  COUNT(DISTINCT user_id)         AS cohort_size,
  COUNT(DISTINCT CASE
    WHEN activity_date = first_seen + INTERVAL '7 days'
    THEN user_id END) * 100.0
    / COUNT(DISTINCT user_id)     AS day_7_retention
FROM user_activity
GROUP BY 1
ORDER BY 1;

継続率のベンチマーク(SaaS):

  • 1 日目:40~60%が健全な水準です
  • 7 日目:20~35%が健全な水準です
  • 30 日目:10~20%が健全な水準です
  • 30 日目以降に曲線が横ばいになることは、プロダクトマーケットフィットの兆候です

行動ベースのコホート、機能の利用曲線、エンゲージメントのスコアリングについては、rules/cohort-retention.md を参照してください。

ファネル分析

完全な方法論については、rules/funnel-analysis.md を読み込んでください。基本パターン:

## Funnel: [Name] — [Date Range]

Stage 1: [Aware / Land]     → [N] users    (entry)
Stage 2: [Activate / Sign]  → [N] users    ([X]% from stage 1)
Stage 3: [Engage / Use]     → [N] users    ([X]% from stage 2)  ← biggest drop
Stage 4: [Convert / Pay]    → [N] users    ([X]% from stage 3)

Overall conversion: [X]%
Biggest drop-off:  Stage 2→3 ([X]% loss) — investigate first

最適化の順序: 最も大きな離脱から改善します。ボリュームの大きいステップでの5ポイントの改善は、ボリュームの小さいステップでの20ポイントの改善より価値があります。

セグメント別ファネル、マイクロコンバージョンの追跡、優先順位付けのパターンについては、rules/funnel-analysis.md を参照してください。

統計の基礎

すべての PM が知っておくべき統計を、わかりやすく説明します。計算式とクイックリファレンスについては、references/stats-cheat-sheet.md を読み込んでください。

p 値を平易に説明すると: 変更の効果がゼロだった場合に、これほど極端な結果(またはそれ以上に極端な結果)が観測される確率です。p=0.03 は、偶然のノイズを見ている確率が3%であることを意味します。「変更が機能する確率が97%」という意味ではありません。

信頼区間を平易に説明すると: 真の効果が存在すると考えられる範囲です。「リフト = +8%、95%信頼区間 [+2%、+14%]」は、実際のリフトが2%から14%の間にあるとかなり確信できることを意味します。信頼区間がゼロを含む場合、成功したとは主張できません。

最小検出効果(MDE): 検出したいと考えるリフトの最小値です。MDE を小さく設定しすぎると、現実的ではないほど大きなサンプルサイズが必要になります。MDE はビジネス価値を基準に設定してください。たとえば、2%のリフトではリリースする価値がない場合は、MDE = 5%に設定します。

統計的有意性と実務上の有意性: 統計的に有意な結果(p < 0.05)でも、実務上は意味がない場合があります(リフト = 0.01%)。必ず両方を確認してください。エンジニアリングに6週間かかる0.01%のリフトは成功とは言えません。

よくある落とし穴

  1. 途中経過の確認 — 結果が良さそうだからと実験を早期終了すると、偽陽性率が上がります。開始前に実施期間を決めてください。
  2. 多重比較 — 10個の指標を p < 0.05 で検定すると、偶然によって約1つの偽陽性が生じます。ボンフェローニ補正を適用するか、主要指標を事前登録してください。
  3. サンプル比率の不一致(SRM) — バリアントグループのサイズが想定した割り当て比率から1%を超えてずれている場合、実験に問題があります。結果を分析する前に修正してください。
  4. 新奇性効果 — 新機能は1週目にエンゲージメントが過大に見積もられます。行動が落ち着くまで確認できるよう、十分な期間実験を実施してください(少なくとも完全なビジネスサイクルを2回)。
  5. シンプソンのパラドックス — セグメント別に見ると、集計結果が逆転することがあります。主要なセグメント(デバイス、プランのティア、地域)ごとに結果を必ず確認してください。

リリース/拡張/終了フレームワーク

シグナル判断対応
p < 0.05、CI がゼロを含まず、ガードレールが正常リリース全体に展開し、成功指標を更新します
正の傾向があるが検出力が不十分(p = 0.10–0.15)拡張実行期間を延長し、再度途中結果を確認しません
p > 0.15、横ばいまたは負の傾向終了元に戻し、学びを記録して、仮説を立て直します
p 値を問わず、ガードレールが悪化終了主要指標にかかわらず、直ちに元に戻します
SRM を検出無効割り当てのバグを修正し、実験を再開します

関連スキル

  • ork:product-frameworks — OKR、KPI ツリー、RICE による優先順位付け、PRD テンプレート
  • ork:monitoring-observability — 指標の定義、アラート、ドリフトの監視
  • ork:brainstorm — 仮説と実験案の作成
  • ork:assess — プロダクトの品質とリスクの評価

参考資料

  • rules/ab-test-evaluation.md — 仮説、サンプルサイズ、有意性、判断マトリクス
  • rules/cohort-retention.md — コホートの種類、継続率曲線、SQL パターン
  • rules/funnel-analysis.md — ステージの対応付け、離脱の特定、最適化
  • references/stats-cheat-sheet.md — 数式、検定の選択、検出力分析

バージョン: 1.0.0(2026年3月)

コメント