mcpField
B
behavioural-analytics

behavioural-analytics

github.com/owl-listenerデータ・データベース3.1k669 回インストール8 週間前に更新
リポジトリ

behavioural-analytics について

ファネル、継続率、イベントデータを読み解く、プロダクトデザイナー向けのスキルです。計測やリリース状況を確認して設計上の問題を切り分け、検証可能な仮説を優先順位付けします。

主な機能

  1. 01イベント定義と分母の確認
  2. 02ユーザーパスとリリース状況の確認
  3. 03ファネルと継続率の傾向分析
  4. 04反証可能な設計仮説の順位付け
  5. 05セグメントと検証方法の明示

活用シーン

  1. 01コンバージョン低下の調査
  2. 02初回利用後の離脱分析
  3. 03プラットフォーム別行動の切り分け
  4. 04次に行う調査の選定

インストール

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

$npx skills add https://github.com/owl-listener/designer-skills --skill behavioural-analytics

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

同梱ファイルEVALS.md

詳細

行動分析

デザイナーに必要な方法でプロダクトデータを読み解き、問題を証明するのではなく、特定することを専門としています。

何をするのか

他の人が計測設定したファネル、リテンション曲線、イベントストリームを受け取り、デザインのどこに問題があるのか、また、それぞれの仮説を裏付ける、あるいは否定するには何を確認すべきかを、優先順位を付けた短いリストにまとめます。指標を定義することはありません。それはすでに済んでいます。また、実験を実施することもありません。次に何を調べる価値があるかを判断します。

数値を信頼する前に

意外な数値の多くは、興味を引く以前に間違っています。デザイン仮説を一つでも立てる前に、次の点を除外してください。

  • イベント名が示す意味と、実際の意味が異なります。 checkout_completed は、支払い時ではなく画面のレンダリング時に発火する可能性があります。ラベルではなく、トラッキング定義を確認してください。
  • 分母が変わっています。 分子が横ばいなのにコンバージョンが低下している場合、それはデザインの変化ではなく、獲得経路の変化です。
  • そのステップは、実際にはステップではありません。 ファネルは、プロダクトが強制していない順序を前提としています。ユーザーがステップを飛ばしたり、戻ったり、フローの途中から参加したりできる場合、「離脱」と見えるものは、ファネルでは捉えられない経路であることがよくあります。
  • リリース、祝日、キャンペーンが同じ日に重なっています。 インターフェースのせいだと判断する前に、デプロイとマーケティング施策の日程を照らし合わせてください。
  • プラットフォームごとの差が、全体の数値に隠れています。 全体ではほとんど変化していないように見えても、あるプラットフォームでは低下し、別のプラットフォームでは上昇していることがよくあります。 この5つすべてを確認しても残る数値なら、デザイン改善の根拠として検討する価値があります。そうでない場合はデータの問題であり、デザインの問題として答えようとすると、1サイクルを無駄にします。

数値の形を読む

数値そのものより、形のほうが多くの意味を持っています。

  • あるステップで急落する — 何かが妨げになっています。必須要件、エラー、あるいはユーザーがまだ持っていない情報の要求などです。
  • 複数のステップにわたって徐々に低下する — 何かが妨げているわけではなく、フローが単に長すぎます。ステップを一つ削除しても、わずかな改善にとどまります。
  • リテンションが低下したあと横ばいになる — ユーザーの中核層は存在しますが、初回の利用体験に問題があります。横ばいの部分は、プロダクトが機能していることを示しています。
  • リテンションが低下し続ける — まだ中核層ができていません。オンボーディングの改善では解決しません。問題は価値提案にあります。
  • タスク完了時間が二峰性を示す — 一つのフローの中で、異なる2つの集団が別々のことをしています。デザインに着手する前にセグメント分けしてください。そうしないと、誰にも当てはまらない平均値に合わせてデザインすることになります。

数値の形から仮説へ

仮説に意味があるのは、何かを否定できる場合だけです。「ユーザーは3番目のステップで混乱している」では、何も否定できません。「ユーザーは、住所フォームが有効な英国以外の郵便番号を拒否するため、3番目のステップで離脱する」なら、特定のセグメントにおける特定のエラー率を予測でき、その率が横ばいなら明確に否定できます。 それぞれの仮説について、対象となるセグメント、その仮説を否定する観察結果、そして答えを得るために、既存データ、セッション録画、会話のどれが必要かを示してください。仮説の確からしさではなく、どれだけ低コストで否定できるかを基準に優先順位を付けてください。

ベストプラクティス

  • 平均より先にセグメントを確認してください。全体の数値は、全員が同じように行動するという前提に立っています
  • 分析結果と同時に、確信度とその理由を述べてください
  • 質問に答えられる範囲で、最も小さいコホートを選んでください。大きな数値はメカニズムを覆い隠します
  • その週に何がリリースされたかを確認せずに、グラフからステップ間の変化を読み取らないでください
  • 統計的に有意な差を、大きな差として扱わないでください。デザインに反映する前に、その差にどれだけの価値があるかを確認してください
  • 数値とインタビューのどちらが正しいか、両者が食い違うときに判断するためのものではありません。その場合は qual-quant-triangulation を使ってください

コメント