pm-analytics

製品分析スキル

このスキルの動作 (最初に読んでください)

これは生成型のプロセススキルです (分析を計画または実行し、分析を批評することもできます)。分析は、AI アシスタントが自信を持って間違った結論を出す分野です。Claude は虚栄の指標 (ページビュー、総サインアップ数) を報告し、相関を因果と取り違え、2日間のスパイクや n=20 のサンプルをトレンドであるかのように扱い、平均値を引用し (これによりすべての興味深いサブグループが隠れます)、「数字はこちらです」で止まり、意思決定に至りません。誰も行動を起こさないダッシュボードや、バイアスに基づいて構築されたインサイトは、分析しないよりも悪いものです。

そこで、このスキルは以下をゲートします:

1. コンテキストを確立する — これが情報を提供する意思決定や問い、それが連なる目標、利用可能なデータ (これらが何を測定し、どの手法を使うかを決めます)。
2. 常に真であるコアを適用する — 問いを最初に、行動につながる指標、シグナルとノイズ、セグメント、定量+定性、そして推奨で締めくくる。
3. コンテキスト依存の意思決定 (分析手法、先行指標か遅行指標か、ツール、アトリビューションモデル、コホートの種類、リテンション期間) をトレードオフとともに明らかにし、ユーザーに選ばせます。

その後、pm-okr-metric-validity-audit (選んだ指標は有効か、虚栄の指標ではないか?) と pm-assumption-rigor-audit (因果の主張や読み取り結果は精査に耐えるか?) に引き継ぎます。

スコープ: このスキルは分析プロセスを担います — 何を測定するか、ファネル/コホート/セグメント/ジャーニー、ノイズからシグナルを読み取ること、そしてデータから意思決定へのストーリーです。指標の定義の厳密な有効性は pm-okr-metric-validity-audit に、統制された変更の統計 (サンプルサイズ、有意性、ガードレール) は pm-experimentation-ab に、OKR/KPI の成果物は pm-okrs-kpis に、そして定性的な「なぜ」を生み出すディスカバリーリサーチは pm-discovery に委ねます。

---

ステップ 0 — 分析する前にコンテキストを確立する

不明な場合は尋ねてください。回答なしで進める場合は前提を明示してください:

• この分析はどのような意思決定や問いに情報を提供しますか? データからではなく、問いから始めてください — 「なぜアクティベーションが下がったのか?」や「どのオンボーディングステップでユーザーが離脱するのか?」などです。意思決定が伴わない分析はノイズを生むだけです。
• どの目標に連なりますか? 指標をビジネスまたはユーザーの目的に結びつけて、追跡しやすいものではなく、本当に重要なものを測定しましょう。
• どのようなデータが存在し、それは信頼できますか? イベントのカバレッジ、期間、利用可能なセグメント、既知のトラッキングの欠落。薄い、あるいは偏ったデータは、正直に結論できる内容を変えます。

---

常に適用するコア (どの分析にも当てはまること)

重要なものを測定する

• まず問い、次にデータ。 分析のライフサイクルに従ってください: 測定目標を設定する → 収集する → 分析する → 行動する。各インサイトが次の問いを生みます。
• 虚栄の指標よりも行動につながる指標を。 ページビューや総登録ユーザー数はプレゼンを飾りますが、意思決定を導きません。テストはこれです: 「この数値が大きく動いたら、自分が正確に何をすべきか分かるか?」 分からないなら、それは虚栄の指標です。行動に結びついた指標 (初週のアクティベーション、機能の採用率、リテンション) を優先しましょう。
• 主要指標を1つ + ガードレール。 分析を1つの成功指標に結びつけ、健全性/ガードレール指標を監視して、「勝利」が他の場所で犠牲になっていないようにしましょう。(これらの指標の厳密な有効性チェックは okr-metric-validity に属します。)

データを正直に読み取る

• シグナルとノイズを分離します。 小さな変動や短期的な変動に反応せず、ローリングウィンドウ（30/90/365日）、移動平均を使用し、行動する前に期間やセグメントをまたいで繰り返されるパターンを探します。
• データの罠を避ける — それらを名指しし、回避するように設計します：
  • 相関 ≠ 因果 — 二つのものが一緒に動く場合（プッシュ通知 ↑ と利用 ↑）、両方とも第三の要因（ホリデーキャンペーン）によって引き起こされている可能性があります。メカニズムを探し、実験（experimentation-ab）で因果を確認します。
  • 生存者バイアス — 残ったユーザーだけを分析すると、他のユーザーが去った理由が隠れます。データから誰が欠けているかを問いかけます。
  • サンプルサイズの誘惑 — n=10 での 50% のリフトは n=1,000 では消えます。十分なデータを待ちます。
  • 選択バイアス — 見る前に成功指標を決めます。都合の良い分析だけでなく、すべての分析を文書化します。
• 平均は嘘をつく — セグメント化します。 「典型的なユーザー」は通常存在しません。結果をデバイス、新規対リピーター、獲得元、行動別に分解します。興味深いストーリーはほとんど常にサブグループにあります（全体 +10% がモバイル −5% を隠すことがあります）。

数値を意思決定に変える

• 「なぜ」を見つけ、定量と定性を組み合わせます。 数値は何が起こったかを示します。興味深いパターンの背後にいるユーザー（ほぼコンバージョンしたユーザー、離脱したヘビーユーザー）と話してなぜを学び、その後データに戻って聞いたことを検証します。
• インサイト → インパクト → アクションで締めくくります。 生の指標ではなくビジネス用語で問題を提示し（「DAU −15%」より「新規ユーザーがコア機能を見つけられない、月約 $50K」が勝ります）、一つのインサイトを明確にする可視化を選び、具体的で責任者を明確にした測定可能な推奨事項で締めくくります。意思決定を変えない分析は完了していません。

---

文脈依存の判断（表面化させ、自動適用しない）

それぞれについてトレードオフとステップ0に紐づく推奨を提示し、ユーザーに選ばせます。あらゆる分析タイプを実行すること、あるいはあらゆる指標を引っ張ってくることは、失敗パターンです。

判断	適用すべきとき	避ける／適応すべきとき	既定の推奨
分析手法	既知のフローにおける段階ごとの離脱にはファネル。行動／リテンションが時間とともにどう変化するかにはコホート。グループ間の違いにはセグメント。非線形でタッチポイントをまたぐ行動にはジャーニー／パス	探索的な行動にファネルを無理に当てはめる、あるいは単純なファネルで答えが出るのにパス分析を行う	手法を問いに合わせる。コンバージョンにはファネル、リテンションにはコホート、分散の説明にはセグメント
先行指標と遅行指標	目標が希少／遅延型なら早期に動くための先行指標（アクティベーション、機能採用）。成果を検証するための遅行指標（MRR、LTV）	遅行指標だけで日々の舵取りをする（対応が手遅れになる）	両方を組み合わせる — 先行指標で行動を導き、遅行指標でそれが機能したことを確認する
ツール／プラットフォーム	Web トラフィックには GA。イベント／行動プロダクト分析には Mixpanel／Amplitude。パイプラインを統合するには Segment。深い／履歴的な分析にはウェアハウス（BigQuery／Snowflake）。ライブ監視にはリアルタイム	プロダクト分析ツールが今日答える問いに対して、ウェアハウスのパイプラインを過剰に作り込む	すでに導入済みのイベント分析ツールを使う。深さ／履歴が要求するときにのみウェアハウスを追加する
コホートの種類	「アハ体験」を見つけるには行動コホート（アクション X を行ったか）。リリース／季節性を切り分けるには時間ベース。チャネル品質を比較するには獲得	1 つのコホートの種類を、3 つの問いすべてに答えたかのように読む	アクティベーションの要因を見つけるには行動コホート。変更のインパクトを測るには時間ベース
リテンション期間	毎日使うプロダクトには N 日。頻度が低い場合は週次／月次。自然なサイクル（日曜の献立計画）にはカスタム	週次で使うプロダクトに日次リテンションのレンズを当てる（誤警報）	期間をプロダクトの自然な利用リズムに合わせる
アトリビューションモデル	単純なコンバージョンクレジットにはラストクリック。複数のタッチポイントが寄与する場合は線形／時間減衰	上流チャネルが別の場所でコンバージョンするジャーニーを始めているのにラストクリックを使う（過小評価になる）	ジャーニーがチャネルをまたぐ場合はマルチタッチ（線形／時間減衰）。ラストクリックは単純なケースのみ
定性の深さ	明確なパターンには軽め（サポートチケット、セッションノート）。大きな意思決定において「なぜ」が要となる場合は深め（インタビュー）	コストが高く不可逆な判断を定量だけで行う	定性を賭け金の大きさに合わせる。驚くような数値は常にユーザーの言葉と突き合わせて確認する

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをそのインストール可能なスキルの name で指定します。呼び出せるのは、そのスキルがインストールされている場合のみです。インストールされていない場合でも、このスキル自体の中核がこれらのルールをすでに備えているため、ブロックせずにそのまま進めてください。

成果物を作成または改訂した後は、完了と宣言するのではなく、監査レンズに引き渡してください。これらは候補のレンズです — 姿勢については docs/orchestration-policy.md に従うか、成果物全体を pm-product-review に通してください。ここでは assumption-rigor が常に関連するレンズ（自動実行） であり、その他は成果物に実際に含まれる内容に応じて提示されます。ユーザーが特定の目的のためにこのスキルを呼び出した場合は、その範囲を尊重してください。

• pm-assumption-rigor-audit (自動実行) — 因果関係の主張は成り立っているか（それとも因果関係を装った相関関係か）、読み取りは正直か（選択バイアスがかかっていないか）、そして根幹をなす結論は主張ではなく証拠に基づいているか？
• pm-okr-metric-validity-audit (提示 — 指標に言及または依存している場合) — 指標は実用的で妥当か（虚栄の指標ではないか）、正しく定義されているか、そして目標に結びついているか？ これは、このスキルが指標定義の基準を委ねる厳密なチェックです。

構成（docs/orchestration-policy.md §9 に準拠）: 変更を統計的な厳密さで検証する場合（サンプルサイズ、有意性、ガードレール、ピーキング）、pm-experimentation-ab が下流にあります（次に生成することを提案し、自動生成はしない）。分析に基づく高リスクで不可逆的な意思決定の場合は、pm-decision-quality-audit が意思決定プロセスをチェックします。監査で衝突が明らかになった場合は、目的に向けて解決してください。分析はより良い意思決定を導くために存在します — それが虚栄の指標、セグメント化されていない平均、または証明されていない因果関係の主張に基づいているなら、誰かがそれに基づいて行動する前に修正してください。

---

よくある do/don't パターン

❌ しない	✅ する
データから始める	意思決定や問いから始め、それから測定する
虚栄の指標（ページビュー、総サインアップ数）を報告する	実用的な指標を使う — 「これが動けば、何をすべきか分かる」
相関を因果として扱う	メカニズムを探す。実験で因果を確認する
2日間の急増や n=20 に反応する	移動窓を使う。再現可能なパターンや十分なサンプルを待つ
定着したユーザーだけを分析する	誰が欠けているかを問う — 生存者バイアスを防ぐ
都合の良い切り口だけを選び出す	成功指標を事前に確定する。すべての分析を記録する
平均を引用する	デバイス、流入元、行動でセグメント化する — 平均は物語を隠す
何をだけを報告しなぜがない	量的データと質的データを組み合わせる。一方を他方で検証する
数字で止まる	洞察 → インパクト → アクションで終える。担当者を定め、測定可能にする
ここで A/B 統計を再発明する	有意性やガードレールは experimentation-ab に委ねる
分析を未チェックのまま出荷する	okr-metric-validity と assumption-rigor に引き渡す

---

出典レッスン（Uxcel）

• Analytics Strategy & Planning
• Analytics Tools & Platforms
• Customer Journey Analytics
• Digging into Data
• Analytics Storytelling
• User Funnel Analysis
• Cohort & Segment Analysis