Communitygithub.com

轉換率審計

從頭到尾審核漏斗,找出最值得修復的那一個漏洞,並提供證明它的測試——包含指標檢測、步驟轉換率分析、用戶流失原因分類,以及實驗設計與成功標準。

轉換率審計 是什麼?

這項技能提供一套系統化的漏斗審計方法,幫助開發者與產品團隊從數據中找出真正的瓶頸,而非只報表數字。它強調整體轉換率是乘法效應,必須優先修復「絕對用戶流失最多」的步驟,而不是最容易修的步驟。技能支援所有平台(網頁、App、SaaS),流程分四步:先畫出事件級漏斗,再測量各步驟轉換率並按流失人數排序;接著對最差的步驟區分是動機(motivation)、摩擦(friction)還是適配(fit)問題;然後公開虛榮指標(vanity metrics),選出一個北極星指標;最後設計一個單一變數的實驗,附帶預先承諾的目標數字與測試時長。最終交付物只有四行:漏洞、診斷、變更、數字——缺第四行就不是建議,只是意見。這項技能的價值在於讓每次審計都能做出決策,避免浪費時間在無關緊要的優化上。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/oinoa/skills/tree/HEAD/skills/conversion-audit

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

轉換率審計 是做什麼的?

你的工作不是報告數字,而是每次審計都要做出一個決定:成本最高的那一個漏洞、你會推出的一項變更,以及這個變更必須超越的數字。一張無法改變任何人下一步行動的圖表,只是在浪費大家的下午。

唯一規則,凌駕一切

修復最大的漏洞,而不是最容易的。 轉換率是乘法效應——一個 100 → 40 → 36 → 34 的漏斗,只有一個災難性步驟,其他三個還不錯。把 36 → 34 這步驟翻倍(94% 的步驟)幾乎不值一提;但把 100 → 40 這步驟提升到 55,整個漏斗就能提升約 38%。永遠按絕對流失用戶數來排序步驟,不要看百分比,也不要看這個步驟在你眼裡有多討厭。最醜陋的頁面很少是最昂貴的。

第一步:在檢視任何數據之前,先畫出漏斗

寫出用戶實際通過的步驟,依序以事件(event)而非頁面(page)表示:「到達頁面 → 看到價格 → 開始註冊 → 驗證信箱 → 完成設定 → 執行核心動作 → 第 7 天回訪」。如果你無法命名這個步驟,就無法測量它;如果兩個不同的旅程被合併成一個步驟,那麼後續的每個數字都是謊言。

有兩件事會悄悄破壞每一次漏斗審計:

  • 混合族群。 付費流量、自然流量和邀請流量的轉換率天差地遠。把它們平均起來,既隱藏了好的,也隱藏了壞的。在下結論之前,一定要按來源分層。
  • 分母變了。 一個「下降」的轉換率,通常只是流量組成變化,而不是產品衰退。在你去尋找產品 bug 之前,先檢查頂層步驟的次數是否改變了形狀。

第二步:測量步驟間轉換,然後按流失用戶排序

對每個步驟:進入數、完成數、百分比,以及絕對流失數。按絕對流失數排序。這個排序清單就是審計結果——其他都是註解。

然後,只對最差的步驟,問三個診斷問題:

  • 這是動機問題嗎? 用戶不了解或不想要下一步。症狀:用戶未互動就離開。修復方向:文案、證據、價格清晰度。
  • 這是摩擦問題嗎? 用戶想要,但流程阻礙他們。症狀:用戶開始步驟但中途放棄(表單開始提交但沒送出、重試、錯誤)。修復方向:更少的欄位、更少的決策、更好的預設值、錯誤處理。
  • 這是適配問題嗎? 到達的用戶從來就不會轉換。症狀:某個步驟對某個來源轉換率很好,對另一個來源卻很差。修復方向:不是修改頁面,而是向上游調整目標受眾。

把這個分類搞錯,是審計最常見的浪費幾個月無用工作的原因——你無法透過 A/B 測試來解決適配問題。

第三步:大聲說出虛榮指標

一個指標如果可以在業務走下坡時仍然上升,它就是虛榮指標。例如:頁面瀏覽量、無激活的註冊量、「參與度」、原始追蹤數、累積總數(只會上升)。把每個指標替換成有分母和時間範圍的版本:不是「10,000 次註冊」,而是「註冊 → 7 天內激活,按群組(cohort)區分」。

只選一個北極星指標:這個指標只有在用戶獲得真實價值時才會移動、團隊確實能影響它、而且它領先營收而不是落後。其他都是輔助指標或護欄。請參考基準範圍,在宣佈某步驟有問題之前先對照檢查。

第四步:設計證明它的測試

每個建議都要附帶一個實驗和一個預先承諾的數字:

  • 每次測試只改變一件事。 混雜三個變更,贏了也不知道哪個有效,輸了更沒有學到東西。
  • 在開始之前就設定目標和時長。 「步驟 2 從 40% 提升到 48%,在完整的兩週內測量。」看到數據後才決定標準,是團隊推出失敗的原因。
  • 執行完整的週數。 工作日和週末流量不同;為期 4 天的測試只是情緒。
  • 統計檢定力不足比不做測試更糟。 如果該步驟每週只有幾百名用戶,小的提升無法測量——要嘛測試一個夠大的變更,要嘛直接推出明顯更好的版本並繼續前進。不要用虛假的統計數據來粉飾猜測。
  • 準時宣布測試失敗。 一個在截止日期前仍未達到目標的測試就是失敗。延長測試直到它「贏」了,那不是測試,而是在尋找雜訊。

交付物

每次固定四行,按此順序:

  1. 漏洞 — 哪個步驟、絕對流失用戶數、佔總流失的百分比
  2. 診斷 — 動機 / 摩擦 / 適配,以及支持的證據
  3. 變更 — 要推出的一項改變
  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.

相關技能