Communitygithub.com

コンバージョン監査

ファネルをエンドツーエンドで監査し、修正すべき唯一のリークと、それを証明するテストを1つだけ特定します。ステップの計装、実ベンチマークとの比較、ユーザー離脱箇所の特定、トラフィック品質問題とプロダクト問題の切り分け、事前に成功基準を設定した実験の設計を行います。

コンバージョン監査 とは?

このスキル「コンバージョン監査」は、AIエージェント(Claude Code、Cursor、Codexなど)向けに設計された、ファネル分析と最適化のための包括的なフレームワークです。単に数値を報告するのではなく、「最もコストのかかるリーク」「出荷すべき1つの変更」「その変更が達成すべき目標数値」という3つの意思決定で監査を終えることを目的とします。 このスキルは、数値のレイヤーの上に「何を修正すべきか」を判断するレイヤーを提供します。ダッシュボード構築やアナリティクスSDKの組み込みには使用せず、アクティベーション・オンボーディング・チェックアウト離脱・トライアルから有料への変換・ランディングページ・リテンション崖・A/Bテストの設計や判定(テスト中止の判断を含む)に特化しています。プロセスは4ステップで構成されます:ファネルの描画、ステップ間測定とユーザー損失によるランク付け、虚栄メトリクスの排除、事前コミットされた数値による実験設計です。 実践的なベンチマーク範囲、サンプルサイズの経験則、虚栄から現実へのメトリクス交換表、監査・実験テンプレートを含むリファレンス資料(`references/funnel-benchmarks-and-test-design.md`)も提供されます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/oinoa/skills/tree/HEAD/skills/conversion-audit

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

コンバージョン監査 は何をしますか?

あなたの仕事は数値を報告することではありません。すべての監査を意思決定で終わらせることです。つまり、最もコストのかかる1つのリーク、出荷すべき1つの変更、そしてその変更が達成すべき数値です。誰も次の行動を変えないチャートは、全員の午後を無駄にしただけです。

すべてを支配するたった1つのルール

最も簡単なリークではなく、最も大きなリークを修正せよ。 コンバージョンは乗算的です。100 → 40 → 36 → 34 というファネルには、1つの壊滅的なステップと3つの良好なステップがあります。36 → 34 のステップ(94%のステップ)を2倍にしてもほぼ無価値ですが、100 → 40 のステップを55に改善すればファネル全体が約38%向上します。常に絶対的なユーザー損失数でステップをランク付けしてください。パーセンテージや、そのステップがどれほど厄介に見えるかではありません。最も見苦しいページが、最もコストのかかるページであることはほとんどありません。

ステップ1:データを見る前にファネルを描く

ユーザーが通過する実際のステップを、ページではなくイベントとして順に書き出します。「ランディング → 価格ページ閲覧 → サインアップ開始 → メール確認 → セットアップ完了 → コアアクション実行 → 7日目に再訪」。ステップに名前を付けられなければ測定できません。また、2つの異なるジャーニーが1つのステップにまとめられている場合、下流のすべての数値は嘘になります。

ファネル監査を静かに壊す2つのこと:

  • 混合母集団。 有料トラフィック、オーガニック、招待フローはコンバージョン率が大きく異なります。それらを平均化すると、良いものも壊れているものも隠れてしまいます。何かを結論づける前に、ソースごとにセグメント化してください。
  • 分母が動いた。 「低下した」コンバージョン率は、多くの場合、トラフィックミックスの変化であり、プロダクトのリグレッションではありません。プロダクトのバグを探す前に、上部ステップのカウントが形状を変えたかどうかを確認してください。

ステップ2:ステップ間を測定し、ユーザー損失でランク付けする

各ステップについて:開始数、完了数、パーセンテージ、そして絶対的な減少数。絶対的な減少数でソートします。そのソートされたリストが監査そのものです。その他はすべてコメントです。

そして、最悪のステップに対してのみ、3つの診断質問をします:

  • モチベーションの問題ですか? ユーザーが次のステップを理解していないか、望んでいません。症状:インタラクションせずに離脱します。修正はコピー、証明、価格の明確さにあります。
  • 摩擦の問題ですか? ユーザーは望んでいるが、フローが抵抗します。症状:ステップを開始し、途中で放棄します(送信がないフォーム開始、リトライ、エラー)。修正はフィールド削減、判断の削減、より良いデフォルト、エラーハンドリングにあります。
  • フィットの問題ですか? 到着したユーザーはそもそもコンバージョンするはずがありませんでした。症状:あるソースではステップのコンバージョンが良好で、別のソースではひどい。修正はページ内ではなく、上流のターゲティングにあります。

この分類を間違えることは、監査が何ヶ月もの無駄な作業を生み出す最も一般的な原因です。フィットの問題をA/Bテストで解決することはできません。

ステップ3:虚栄メトリクスを明確に名指しする

メトリクスが虚栄であるのは、ビジネスが悪化しても数値が上がり得る場合です。ページビュー、アクティベーションのないサインアップ、「エンゲージメント」、生のフォロワー数、累計(常に増加するしかない)。それぞれを、分母と時間枠を持つバージョンに置き換えてください。「1万サインアップ」ではなく「コホート別、サインアップから7日以内のアクティベーション」。

正確に1つのノーススターを選んでください:ユーザーが実際の価値を得たときにのみ動き、チームが実際に影響を与えられ、収益をリードする(遅延させない)メトリクス。その他はすべて補助メトリクスまたはガードレールです。壊れていると宣言する前に、ステップを検証するためのベンチマーク範囲については、リファレンスを参照してください。

ステップ4:それを証明するテストを設計する

すべての推奨事項には、実験と事前にコミットされた数値が付属します:

  • テストごとに1つの変更。 3つの変更をまとめると、勝ったとしてもどれが効いたのか学べず、負けたとしてもさらに学べません。
  • 開始前に目標と期間を設定する。 「ステップ2を40%から48%に、2週間フルで測定」。データを見てから基準を決めることは、チームが失敗を出荷する方法です。
  • フルウィークで実行する。 平日と週末ではトラフィックが異なります。4日間のテストは気分次第です。
  • 検出力不足のテストは、テストをしないより悪い。 ステップが週に数百ユーザーしかいない場合、小さな改善は測定不可能です。十分に大きくて目に見えるものをテストするか、明らかに優れたバージョンをそのまま出荷して先に進みましょう。推測を偽の統計でごまかさないでください。
  • 予定通りにテストを中止する。 終了日までに基準に達していないテストは負けです。勝つまで延長するのはテストではなく、ノイズの探索です。

成果物

毎回、この順序で4行:

  1. リーク — どのステップか、絶対的なユーザー損失数、全体損失の%。
  2. 診断 — モチベーション / 摩擦 / フィット、その根拠となるエビデンス。
  3. 変更 — 出荷すべき1つのこと。
  4. 数値 — いつまでに何を超えなければならないか、超えなければロールバック。

4行目を埋められなければ、まだ推奨事項はありません — 意見があるだけです。

ステップごとのベンチマーク範囲、サンプルサイズの経験則、虚栄から現実へのメトリクス交換表、監査および実験テンプレートについては、references/funnel-benchmarks-and-test-design.md を参照してください。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル