數據分析師面試遇到「轉換率突然下降，你會怎麼查」，可以先確認數字算的是誰、哪個行為與多長時間，再核對資料是否完整，接著找出下降集中在哪群使用者、哪段流程，最後提出能驗證原因的下一步。如果還沒分清付款減少與付款記錄漏送，就先建議增加折扣，可能花了成本，卻沒有處理真正的問題。
以下用一款服務台灣與香港的購票 App 作虛構練習，所有數字、改版情節與回答示例均為原創。產品負責人看到每週購票轉換率從 6% 跌到 4%，懷疑最近改版影響成交，希望你在當日下午先說明影響範圍與優先處理事項。你的任務是縮小問題範圍，說明目前能確定什麼，以及下一項查證為何值得優先做。
先把「購票轉換率」寫成一句可以重算的話
這裡先約定：分母是每週曾登入並查看活動詳情的不重複使用者；分子是這批人從該週第一次查看活動詳情起，二十四小時內至少有一筆購票付款成功的人數。一人即使看過多場活動、買了三次票，也只計一次。這個比率衡量查看活動後是否購票，不直接衡量單一活動頁的說服力。
還要補齊日期與例外：兩週各取完整七天，以台港共同的 UTC+8 時區劃分，讓最後一天進入的人也有完整二十四小時。內部測試帳戶兩期都排除，匿名訪客不在本題範圍；後續退款另行追蹤，不回頭把已付款的人刪掉。若要衡量最終未退款成交，應另訂等待時間及計算方式。
這些設定會實際改變答案。Amplitude 的漏斗分析說明指出，可按不重複使用者或事件總次數計算，而完成步驟還須符合指定順序與轉換時間。因此，不能直接把兩張都叫「轉換率」的報表拿來比較；先核對它們是否使用同一套定義。
題目給出前週 10,000 人查看、600 人付款，本週 12,000 人查看、480 人付款。初步計算是 600 ÷ 10,000＝6%，以及 480 ÷ 12,000＝4%。下降幅度為 2 個百分點；若以前週為基準，則是相對下降約 33.3%。把兩種表述分開，後面的影響估算才不會混淆。
核對原始記錄，先分辨漏記與真的少人付款
定義一致之後，先確認本週的觀察時間與資料處理都已結束。尚未收到的付款記錄，不能直接算成未付款。以 GA4 為例，Google 的資料更新說明提到，處理可能需要二十四至四十八小時，其間報表數字仍可能改變。實際調查應看正在使用的系統與資料流程，不能套用一個固定等待時數。
接著把報表拆回原始記錄：活動查看是否重複送出、使用者識別碼是否因登入方式改變而拆成兩人、付款事件是否改名、資料匯入是否中斷。核對時保留使用者識別碼、查看時間、付款時間與狀態，以及 App 版本。付款重試或單次買多張票都不能重複計人；只有進入本週分母、且在指定時間內成功付款的人，才放進分子。
這個虛構練習追加一項發現：部分新版 App 的成功付款事件改名，舊報表沒有納入。將後端訂單與付款記錄對照，確認本週實際有 540 位符合定義的使用者付款成功，其中 60 人未出現在原報表中；分母 12,000 人與前週 600 位付款者也已按相同方式核對。
修正後，本週轉換率是 540 ÷ 12,000＝4.5%。原先看到的 2 個百分點下降，其中 0.5 個百分點來自漏記；還有 1.5 個百分點需要解釋。此時可以請資料維護者修復報表，並標註受影響日期，同時繼續調查實際購票變化。找到資料問題，並不代表商業表現就沒有問題。
比率下降，也可能有一部分來自使用者組成
確定數字可信後，再把整體拆開。先選和購票行為有合理關係、也能加總回整體的分群，例如新客與舊客。以下把每週首次查看活動前，從未成功購票的人列為新客，其餘列為舊客；當週買票後不改分類，避免把成功的新客移到舊客，讓結果失真。
| 使用者群體 | 前週查看人數 | 前週付款人數／轉換率 | 本週查看人數 | 本週付款人數／轉換率 |
|---|---|---|---|---|
| 舊客 | 6,000 | 480／8% | 6,000 | 420／7% |
| 新客 | 4,000 | 120／3% | 6,000 | 120／2% |
| 合計 | 10,000 | 600／6% | 12,000 | 540／4.5% |
新客本來的轉換率較低，而本週新客占比從 40% 升到 50%。若暫時沿用前週兩群的轉換率，把它們套到本週人數，會得到 6,000 × 8%＋6,000 × 3%＝660 人，相當於 5.5%。這顯示，單是新舊客比例不同，就能在這個計算中使整體從 6% 降到 5.5%。
但實際只有 540 人付款，比上述 660 人少了 120 人，整體仍差 1 個百分點。新舊客本身的轉換率都下降，因此不能只用「新客變多」結束調查。這是固定前週轉換率的算術拆解，並非已證明多出的流量或改版造成多少損失，也不能把差額直接稱為流失訂單或收入。
接下來可按台灣／香港、App 版本與付款方式交叉查看，仍保留每組人數。只有少數人的群體即使跌幅大，也未必能解釋整體變化；反過來，占比大的群體只跌一點，也可能值得優先處理。比較的目的，是找到能影響判斷的範圍，並非把所有欄位排列組合到出現一個極低數字。
沿著使用流程，讓每個可能原因都有查證方法
新舊客都有下降，下一步就要把差異放回實際購票流程。對同一批查看者，依序核對選擇場次、送出訂單、開始付款與付款成功的人數，固定事件順序及二十四小時範圍。若前幾步大致穩定，主要落差在開始付款之後，就先查付款路徑；這也說明為什麼目前還不急著重新設計首頁推薦。
同時整理異動時間表，包括 App 發布、事件名稱調整、付款供應商變更、票價與手續費、熱門場次售罄，以及推廣活動開始的時間。每一項都要接上「如果它是原因，應該看到什麼」，再找能支持或削弱該解釋的記錄。
例如，付款流程出錯的假設，應對照錯誤碼、失敗步驟與版本，並嘗試在相同條件下重現；可售票量不足的假設，應查看受影響場次何時售罄，以及使用者是否在選位時離開；新一輪推廣帶來較多只想瀏覽的人，則應比較該來源使用者的查看、選位與付款行為，並留意它是否集中在某個市場。
假設練習再提供一條線索：兩地部分使用者在新版 App 的銀行驗證頁看到錯誤，開始付款後的成功比例也下降。這足以優先安排工程查證，但還不能把全站 1.5 個百分點的下降都歸給改版。升級新版的人可能和沒升級的人不同，同期也可能有不同活動或付款方式；只看「改版後一起下降」仍不足以確定因果。
若能重現錯誤，就先修復已知故障，再觀察受影響路徑是否恢復。若無法重現，可比較相同市場、相近新舊客組成及付款方式下的新舊版本，並查更細的時間記錄。還要確認使用者真的進入新版銀行驗證頁，不能只看安裝版本。這些比較能縮小範圍，仍可能漏掉其他差異；需要檢驗流程設計效果時，再安排合理的隨機分組，讓新舊流程在可比較的條件下試行。已知會阻止付款的故障，應先處理。
在有限時間內，先處理會改變決定的證據
面試官可能追問：「只有半天，怎麼排優先順序？」可以先完成計算定義、資料完整性確認與後端付款核對，因為這三步會決定問題究竟有多大。確認實際下降後，優先看人數多、跌幅明顯且有錯誤線索的付款路徑；較細的城市與推廣來源分析可以接續做，不需要等所有圖表完成才回報。若核對期間已確認有人持續無法付款，工程也可同步處理故障。
如果被問「這個跌幅有沒有統計意義」，先交代比較期間、歷史波動與各群人數，再評估差異的不確定性。兩週可能包含相同使用者，演出安排與週末活動也可能不同，不能僅因總人數上萬就說結論已確定。拆過很多群之後，也不應只挑最差的一群當答案；要看它是否持續出現、能否重現，以及和付款記錄是否一致。
對需要立即處理的故障，判斷門檻又不同。即使受影響人數還未估準，只要已確認有人因錯誤無法付款，就能建議先採取範圍清楚、可撤回的處理，例如由產品與工程評估暫停相關功能的擴大上線。同時保留原始記錄與觀察方式，避免處理後反而失去查證線索。
結論要讓產品、工程與資料維護者採取行動
完成上述核對後，當日下午的回報就能同時交代下降幅度與工作順序：「本週實際購票轉換率為 4.5%，較前週低 1.5 個百分點。原報表另有 60 位付款者漏記，已交由資料維護者修復。新客占比變高可在固定前週轉換率的拆解中解釋 0.5 個百分點，剩餘差異仍需查證。目前新版銀行驗證路徑有錯誤線索，建議工程優先重現並評估處理；暫時不能把全站下降都歸因於改版。」
接著補上工作安排：資料維護者核對修復後的 540 人能否逐筆對回付款記錄；工程確認錯誤重現條件及可行修正；分析師估算受影響人數，並在下一次完整資料到齊後更新比較；產品負責人依故障範圍決定是否暫停擴大。回報時間應配合各項查證可完成的時間與資料更新節奏，不能只寫「持續觀察」。
最後留下一條改變判斷的條件：若銀行驗證問題修復後，付款步驟已恢復，但新客整體購票仍偏低，就把後續重點轉向活動供給與流量來源。這能讓團隊知道調查尚未結束，也避免下一次更新仍反覆展示同一張曲線。
用二十五分鐘練習一份可交付的調查摘要
先花五分鐘重寫購票轉換率的定義，確保一位跨日購票、重試付款的使用者也能被正確計數。再用五分鐘重算 4%、4.5% 與 5.5% 各代表什麼，說明哪個來自報表、哪個來自核對、哪個只是比較基準。接著用十分鐘列出三個可能原因，各配一項支持證據、一項相反證據與負責查證的人。
最後五分鐘，錄下一段九十秒回報。聽回放時，檢查是否先說目前確認的下降幅度，是否把假設說成結論，以及下一步是否真的能排除其中一種解釋。完成後可閱讀 產品經理的問題取捨與成效衡量指南，把同一套查證方式換到另一個情境，再練一次。