漏斗分析怎麼做?先確認分母、順序與觀察窗口
用同一組教學資料拆解漏斗分析的計數單位、入口、步驟順序與完成窗口,說明不同轉換率為何都可能算對,以及如何建立可重複比較的口徑。
先說結論:先寫清楚規則,轉換率才有意義
漏斗轉換率不是「最後一步除以第一步」就結束。開始計算前,至少要固定五件事:分析對象、計數單位、入口、步驟順序、完成窗口。同一批行為資料,只要其中一項改變,結果就可能不同;兩個數字都算對,也不代表它們可以直接比較。
最實用的口徑不是永遠最嚴格或數字最大,而是最接近決策問題。例如,檢查單次結帳操作是否卡住,適合看同一工作階段內的嚴格順序;評估需要數天考慮的課程購買,則可看使用者在合理天數內跨工作階段完成。報表旁應保留完整定義,而不是只留一個百分比。
一個漏斗口徑,要先回答五個問題
1. 分析對象是誰?
先限定要觀察的群體,例如所有訪客、新客、看過特定方案的人,或由某個活動進站的人。篩選條件若只套在第一步,和每一步都套用,可能得到不同結果;因此要記錄條件套用在哪一層。
2. 計數單位是什麼?
- 使用者漏斗:同一人重複進入,通常仍只算一人,適合回答「多少人最後完成」。
- 工作階段漏斗:一次造訪是一個機會,適合回答「單次使用流程是否順利」。
- 事件漏斗:同一人重複操作可能多次計入,適合研究動作頻率,但不能直接當成獨立顧客數。
GA4 的漏斗探索以使用者為核心;Microsoft Clarity 的漏斗文件則把完成率定義為成功完成漏斗的工作階段比例。Fullstory 也允許選擇唯一使用者或唯一工作階段。工具名稱相同,不代表預設分母相同。
3. 誰可以進入?
封閉漏斗要求先完成第一步才進入,適合衡量一條明確流程;開放漏斗允許從中間步驟進入,適合觀察回訪或已有進度的顧客。GA4 官方文件也說明:開放漏斗可讓先前已加購、之後回來結帳的人從後段重新進入。
4. 步驟必須多嚴格?
「依序完成」通常允許中間穿插其他動作;「直接接續」則要求下一個事件緊跟在前一事件之後。前者更接近真實、非直線的旅程,後者更適合檢查表單、註冊或付款等短流程。若想先發現實際路徑,再決定漏斗步驟,應先用路徑分析,不要把預想路線當成唯一真相。
5. 多久內完成才算?
完成窗口是從進入漏斗到完成最後一步可容許的最長時間。三十分鐘、一天與七天回答的是不同問題。窗口太短,會把正常回訪當成流失;窗口太長,則可能把原本無關的後續購買連到早期行為。
總轉換率與階段轉換率不要混在一起
假設封閉漏斗有四步:看課程介紹 → 看價格 → 開始結帳 → 付款。共有 1,000 位使用者進入,依序有 640、400、240 人抵達後續步驟。
| 階段 | 完成人數 | 相對第一步 | 相對前一步 |
|---|---|---|---|
| 看課程介紹 | 1,000 | 100% | — |
| 看價格 | 640 | 64% | 640 ÷ 1,000 = 64% |
| 開始結帳 | 400 | 40% | 400 ÷ 640 = 62.5% |
| 完成付款 | 240 | 24% | 240 ÷ 400 = 60% |
它回答「進入漏斗的人,有多少完成全部流程」。最後一段的階段轉換率則是 240 ÷ 400 = 60%,回答「已開始結帳的人,有多少付款」。
只說「結帳轉換率 60%」會產生歧義:有人以為分母是所有看課程者,有人則以為是開始結帳者。報表標題應直接寫成「介紹頁至付款」或「開始結帳至付款」,並同時顯示人數。
Google Analytics 的自訂漏斗報表把放棄率呈現為目前步驟到下一步未繼續的人數與比例。例如 200 人進入、140 人到下一步,放棄人數是 60,放棄率是 30%。因此,放棄率也必須綁定一對相鄰步驟,不能脫離分母單獨解讀。
完整案例:同一批資料為何出現四個答案
以下是虛構教學資料,用來展示口徑差異,不是 MKT Notes 或任何客戶的實際成效。
某線上課程網站在八月觀察前述四步漏斗。原始資料中:
- 1,000 位使用者在八月首次完成「看課程介紹」,共產生 1,350 個含此步驟的工作階段。
- 240 位使用者在進入後七天內依序完成四步。
- 其中 190 位在一天內完成,150 位在三十分鐘內完成。
- 八月共有 300 位付款者,但其中 60 位在七月已進入漏斗,或沒有走完本次定義的前置步驟。
- 有 210 個工作階段在同一次造訪內完成四步。
| 報表名稱 | 分子 | 分母 | 結果 | 真正回答的問題 |
|---|---|---|---|---|
| 使用者封閉漏斗,七天 | 240 | 1,000 | 24% | 進入者有多少在七天內依序完成? |
| 使用者封閉漏斗,一天 | 190 | 1,000 | 19% | 進入者有多少在一天內完成? |
| 使用者封閉漏斗,三十分鐘 | 150 | 1,000 | 15% | 短流程是否能迅速完成? |
| 同工作階段漏斗 | 210 | 1,350 | 15.6% | 每次造訪有多少當次完成? |
| 當月付款者 ÷ 當月介紹頁使用者 | 300 | 1,000 | 30% | 兩個當月總量的比例是多少?這不是同一條封閉漏斗。 |
最後一列最容易被誤稱為「漏斗轉換率」。300 位付款者中混有較早進入或跳過步驟的人,因此不能說八月進入漏斗的 1,000 人有 30% 完成。它可以是營運比例,卻不是這個封閉、七天、依序完成的漏斗。
口徑該怎麼選?從決策反推,而不是挑好看的數字
| 決策問題 | 建議計數單位 | 入口與順序 | 完成窗口 |
|---|---|---|---|
| 付款表單哪一步故障? | 工作階段 | 封閉、直接接續或嚴格依序 | 接近正常操作時間 |
| 顧客考慮數天後是否購買? | 使用者 | 封閉、允許中間行為 | 依實際決策週期設定 |
| 回訪者從哪裡恢復流程? | 使用者 | 開放漏斗 | 可涵蓋合理回訪週期 |
| 哪個入口帶來較多完整旅程? | 使用者或工作階段,固定一種 | 封閉、分群比較 | 各群使用同一窗口 |
| 一個人付款前會重試幾次? | 事件搭配使用者 | 先定義開始與完成,再數中間重複 | 限定在同一合理旅程內 |
完成窗口不要直接抄工具預設值。可先查看完成者的時間分布,再結合業務情境選擇:即時付款可能以分鐘或小時計,企業採購則可能需要數天或更久。Fullstory 也區分同一工作階段與跨工作階段漏斗,並以完成者的步驟時間解讀完成速度。
看到掉落,不要立刻把原因歸給那一頁
漏斗能指出「哪裡少了人」,不能單獨證明「為什麼」。看價格到結帳掉落,可能是價格不合、方案難懂、追蹤遺漏、頁面載入失敗,也可能只是顧客需要回去比較。GA4 官方文件也提醒,某些「沒有下一步」的顯示不一定等於流失,可能只是所選維度沒有改變。
因此每個明顯落差至少做三項檢查:
- 資料檢查:事件是否在成功狀態觸發、是否重複、漏送或改名?
- 切分比較:差異是否集中在裝置、瀏覽器、方案、新舊客或流量來源?
- 行為證據:用路徑、工作階段回放、使用者研究或客服紀錄理解離開後發生什麼。
如果分析與後端訂單總量也對不上,先依網站分析與後端訂單對帳流程確認資料完整性,再討論頁面優化。錯誤追蹤做出的漂亮漏斗,仍然是錯誤證據。
八步建立可重複比較的漏斗
- 寫下決策:這個漏斗要決定修頁面、改流程、調預算,還是追蹤長期購買?
- 定義分析對象:記錄包含與排除條件,並說明篩選套用在哪一步。
- 選計數單位:固定使用者、工作階段或事件;跨報表比較時保持一致。
- 逐步寫成功條件:以已完成的行為定義步驟,不只看按鈕被點擊。
- 固定入口、順序與窗口:把封閉/開放、直接/間接、時間限制寫進報表名稱或註解。
- 驗證原始事件:以測試紀錄、事件時間與唯一 ID 檢查漏送、重複與先後順序;可搭配GA4 事件規劃指南。
- 同時顯示人數與比例:保留每步人數、總轉換率、階段轉換率與實際日期範圍。
- 切分、找證據再行動:先定位差異,再用路徑或質性資料驗證原因;變更後用完全相同口徑比較。
發布前可直接使用的口徑卡
每張正式漏斗至少附上以下資訊:
| 欄位 | 範例 |
|---|---|
| 商業問題 | 看過課程介紹的人,有多少在七天內付款? |
| 分析對象 | 八月首次看課程介紹、排除內部與測試流量的使用者 |
| 計數單位 | 唯一使用者 |
| 入口 | 封閉,必須先看課程介紹 |
| 步驟 | 介紹 → 價格 → 開始結帳 → 付款 |
| 順序 | 依序完成,允許中間行為 |
| 完成窗口 | 從第一步起七天內 |
| 日期範圍 | 依第一步進入日期歸入八月 |
| 篩選與分群 | 裝置與新舊客;各群沿用同一口徑 |
| 驗證來源 | 事件除錯紀錄、訂單 ID 與後端付款狀態 |
當兩份漏斗數字不同,先逐欄比對這張卡。若差異來自分母、順序或窗口,應把它視為定義不同;只有定義相同仍不一致,才進一步查資料處理、身分辨識、延遲或追蹤錯誤。這樣漏斗才不是一個容易被挑選的百分比,而是一套能被重算、解釋與用來決策的分析方法。
SOURCE LOG