題幹與適用情境
一款協作產品的每日活躍使用者（DAU）從上週日均 1,000,000 降至本週日均 850,000，以相同星期結構比較，下降 15%。本題將 DAU 定義為：依 UTC 日曆日去重後，至少完成一次核心協作動作的使用者數。核心動作可以是檢視、編輯或留言共享文件，但分析開始後不能臨時更換口徑。
請說明如何確認下降是否真實、把 150,000 的缺口定位到具體使用者路徑、驗證首要假設，並決定要修復資料、暫停發布、回復產品版本，或繼續觀察。這道題適用於產品經理、成長產品經理與產品分析職位。核心能力是把模糊異常縮小成可證偽的產品決策，而非列出所有可能原因。
下文的產品、版本號與數字都是面試演算假設，不代表真實公司資料。公開資料能證明「指標下降診斷」仍出現在 2026 年的產品與分析面試準備中；無法獨立查證的公司歸屬不作為本文事實。
面試官考察重點
第一，能否先固定指標合約。不同工具對「活躍使用者」的事件條件、視窗與身分去重可能不同。若候選人不知道分子、日期邊界、事件版本與使用者識別，就無法區分使用者真的離開與報表少算了人。
第二，能否依證據縮小範圍。強回答先核對資料，再用互斥分群計算絕對缺口，接著沿同一批使用者的巢狀漏斗尋找第一個斷點。只說「看地區、裝置、版本、管道」仍是一張查詢清單，沒有告訴面試官先查什麼、哪項結果會改變下一步。
第三，能否區分相關、歸因與行動。下降與一次發布同時發生，只能建立首要假設；版本採用者原本就可能不同。候選人要補上伺服器端訊號、錯誤紀錄、分階段發布或可控回復等證據，再決定是否止損。
第四，能否在資訊不完整時做出可逆決定。若關鍵旅程已受損，等待完美因果證明可能擴大損失；若只有事件追蹤異常，貿然回復產品同樣有成本。高品質回答會說清楚目前結論、信心程度、行動門檻與下一個決策時間點。
回答前需要釐清的問題
- DAU 的精確口徑是什麼？ 是開啟應用程式、停留一定時間，還是完成核心動作？日期依 UTC、使用者當地時區，或滾動 24 小時？答案會改變查詢與歷史可比性。
- 15% 如何計算？ 是單日年比、相鄰兩週日均，還是與預測基準相比？本題使用兩個完整日曆週的日均，並維持相同星期結構；假日或不完整資料要另外處理。
- 資料何時完整？ 事件是否有延遲、回補、抽樣、隱私門檻或時區切換？若本週資料尚未成熟，應先比較相同成熟度的視窗。
- 最近發生了什麼？ 需要發布日曆、事件追蹤與資料模型變更、行銷活動、通知策略、價格或權限變化，以及外部故障與假日。時間線用來檢驗假設，不能只憑「同時發生」下結論。
- 下降是否伴隨使用者傷害？ 當機、登入失敗、首頁載入失敗、儲存失敗與客服請求會決定止損速度；只有報表下降而伺服器端核心動作穩定時，優先處理量測鏈路。
- 可以如何控制風險？ 是否能停止分階段發布、回復單一版本、關閉功能開關，或保留對照群體？可逆性決定要在繼續蒐證時止損，或先觀察。
- 有哪些獨立訊號？ 用戶端事件、伺服器端請求、資料庫寫入、當機報告與客服回饋若共用同一故障點，不能算真正獨立的交叉驗證。
30 秒回答框架
「我先鎖定 DAU 的事件、身分去重、時區與資料成熟度，並用原始事件和伺服器端核心動作核對 15% 是否真實。確認後，我按互斥的端別、版本、地區與新舊使用者計算絕對缺口，不只比較百分比；再沿開啟、登入、首頁載入、核心動作的巢狀漏斗找第一個斷點，並把斷點與發布及外部事件對齊。首要假設要用另一類訊號或可控回復驗證。若是事件追蹤問題，就修資料並回補；若近期版本造成關鍵旅程失敗，就暫停發布或回復前一版；若下降廣泛且漸進，再查獲客、留存、季節性與競爭變化。」
分步深入解答
第一步：先證明指標值得相信
把指標合約寫成一句可執行定義：DAU = UTC 日曆日內，至少產生一次 corecollaborationaction、依穩定 user_id 去重的使用者數。同時固定機器人、內部帳號、匿名轉登入、跨裝置合併與遲到事件的處理規則。定義沒有凍結時，任何分群都可能在比較兩種不同的「活躍」。
接著做三類核對：儀表板與原始事件能否重算；用戶端核心事件與伺服器端成功請求的獨立使用者數是否同向；資料延遲、事件改名、過濾規則、身分合併與時區是否在下降起點發生變化。若儀表板顯示 850,000，但伺服器端仍有約 1,000,000 位使用者完成核心動作，問題首先屬於量測鏈路。此時應修正口徑、標註異常視窗並評估回補，不能用產品版本回復來「修復」報表。
第二步：量化異常的形狀
先同時說出相對值與絕對值：(850,000 - 1,000,000) ÷ 1,000,000 = -15%，也就是日均減少 150,000 位使用者。再畫每日或每小時序列，判斷是某一時刻斷崖式下降、逐日下滑，還是只有星期結構改變。斷崖更值得對齊發布、資料工作或外部故障；緩慢下降則更可能涉及獲客、留存、季節性或長期產品價值。
基準要可比。完整週應與完整週比較；假日市場要與自己的歷史比較；新功能快速成長期不能把上週數值當成永恆預期。統計波動可以用歷史分布或預測區間判斷，但「顯著」只表示異常不太像隨機雜訊，不會自動給出原因。
第三步：用絕對貢獻定位，而非追逐最大跌幅
分群必須互斥且涵蓋總體。為避免跨端使用者重複計算，本例把每位使用者歸到當天第一次核心動作所在的平台：
| 平台 | 上週 DAU | 本週 DAU | 絕對變化 | 占淨缺口 | |---|---:|---:|---:|---:| | Web | 400,000 | 396,000 | -4,000 | 2.7% | | Android | 350,000 | 343,000 | -7,000 | 4.7% | | iOS | 250,000 | 111,000 | -139,000 | 92.7% | | 合計 | 1,000,000 | 850,000 | -150,000 | 100% |
iOS 貢獻了 139,000，約占淨缺口的 92.7%，因此先查 iOS，比同時深挖所有地區與管道更有效。貢獻率為 分群絕對變化 ÷ 總體絕對變化；若有分群成長抵銷下降，貢獻率可能是負數或超過 100%，不能把它誤解為使用者占比。
接著在 iOS 內依版本、地區、帳號年齡與獲客管道重複計算，但每次只改變一個切面並保留絕對人數。一個小市場下跌 80% 可能只貢獻幾百人；一個大版本下跌 20% 可能解釋主要缺口。
第四步：沿巢狀漏斗找第一個斷點
對同一天、同一批去重使用者建立巢狀事件集合，後一步使用者必須屬於前一步：
| iOS 階段 | 上週使用者數 | 上一步轉換 | 本週使用者數 | 上一步轉換 | |---|---:|---:|---:|---:| | 開啟應用程式 | 300,000 | — | 300,000 | — | | 登入成功 | 280,000 | 93.3% | 279,000 | 93.0% | | 首頁載入成功 | 270,000 | 96.4% | 120,000 | 43.0% | | 完成核心動作 | 250,000 | 92.6% | 111,000 | 92.5% |
應用程式開啟與登入幾乎穩定，斷點出現在登入成功到首頁載入成功；首頁一旦載入，核心動作轉換也大致穩定。這個結果把「DAU 下降」縮小成「iOS 使用者無法進入核心頁面」。只有集合確實巢狀、時間視窗與去重鍵一致時，才能把這些轉換率連乘；把獨立事件總量任意相乘會產生假漏斗。
假設進一步發現 iOS 9.4.0 的登入使用者有 200,000，只有 50,000 成功載入首頁；舊版本 79,000 位登入使用者中有 70,000 成功載入。若伺服器端首頁請求的成功使用者數也從約 269,000 降到 118,000，而非只有 home_loaded 用戶端事件消失，真實旅程受損的證據就明顯增強。這些數字仍是案例假設，目的是示範如何從總體下鑽到可驗證斷點。
第五步：依證據替假設排序
把假設分成四組，但只優先驗證能解釋「時間、範圍與漏斗斷點」的項目：
- 量測問題：事件改名、SDK 遺失資料、身分合併或資料延遲。預期表現是用戶端 DAU 下降，但伺服器端成功動作與使用者回饋穩定。
- 內部產品或技術變更：iOS 9.4.0 的首頁請求、權限或快取邏輯退化。預期表現是下降集中在該版本，錯誤與載入失敗同步上升。
- 觸達或供給變化：通知停發、行銷活動結束、內容供給下降。預期表現是開啟應用程式之前或特定管道先下降，而已進入產品的漏斗相對穩定。
- 外部與季節性：假日、地區網路、平台政策或競爭事件。預期表現是與地域、時間或使用者群一致，且不依賴單一內部版本。
版本與下降同時出現仍是觀察性相關。9.4.0 的採用者可能集中在某些裝置或地區。可以檢查同一裝置與市場內的新舊版本、利用原有分階段發布的對照群體，並在風險可控時停止發布或回復一小部分，觀察首頁成功率與核心動作是否恢復。隨機或預先分配的對照最有說服力；事後分群必須說明殘餘混雜。
第六步：讓診斷直接產生行動
本例中，iOS 解釋約 92.7% 的淨缺口，巢狀漏斗把斷點定位到首頁載入，伺服器端訊號也同向，且異常與 9.4.0 發布時間接近。若首頁失敗正在阻斷使用者工作，而停止發布或回復版本是可逆的，合理行動是先暫停 9.4.0 擴量並回復受影響版本，同時繼續驗證具體故障。無須等到每一行程式碼都定位完才止損。
對外結論應帶信心程度：「目前有高信心認為主要缺口來自 iOS 首頁載入失敗；9.4.0 是首要原因假設，尚未完成因果確認。」接著列出負責人、修復或回復動作、恢復判斷與下次更新時間。恢復標準至少包含首頁成功率、iOS 核心動作使用者數與整體 DAU 同向回升，不能只看儀表板重新變綠。
若交叉核對顯示伺服器端核心動作穩定，就不要回復產品；修復事件追蹤或資料工作、回補歷史並記錄口徑變更。若下降跨所有平台且持續數週，則把分析轉向新使用者流入、舊使用者留存與使用頻率，並透過使用者研究、管道資料或實驗驗證產品假設。行動隨證據分支改變，這才是這道題的產品判斷部分。
高品質示範回答
「我會先把 15% 拆成可驗證的問題。題設的 DAU 是 UTC 日曆日內完成至少一次核心協作動作的去重使用者，所以我先檢查事件定義、身分合併、遲到資料與完整週比較，並用原始事件及伺服器端成功動作重算。如果伺服器端仍有 100 萬人完成動作而儀表板只有 85 萬，我會處理量測事故，不動產品。
假設下降真實，絕對缺口是每天 15 萬人。我會用互斥分群計算每組對缺口的貢獻。案例中 Web 少 4,000、Android 少 7,000、iOS 少 139,000，iOS 解釋約 92.7% 的淨下降，所以先查 iOS。
iOS 的開啟使用者維持 30 萬，登入成功從 28 萬小幅降到 27.9 萬，但首頁載入從 27 萬降到 12 萬；載入成功後完成核心動作的轉換仍約 92.5%。第一個斷點就是首頁載入。若問題又集中在 9.4.0，伺服器端首頁成功使用者也同步下降，我會把該版本列為首要假設，並檢查錯誤紀錄和發布時間線。
我不會把時間重合直接稱為因果。會比較相同裝置與地區的新舊版本，利用分階段發布的對照，並在安全範圍內停止擴量或回復一部分流量，看關鍵漏斗是否恢復。由於使用者已無法進入核心頁面，且版本回復可逆，我會先止損再完成根因分析。
目前回報會寫成：主要缺口有高信心來自 iOS 首頁載入；9.4.0 是待確認原因；現已暫停擴量並回復，負責人正在查證。只有首頁成功率、iOS 核心動作與整體 DAU 一起恢復，才算修復。若伺服器端動作穩定，我會改判為資料問題，修事件追蹤並回補，而不會回復產品。」
常見錯誤
- 直接腦力激盪十種原因 → 假設沒有優先順序，也沒有下一個查詢 → 先驗證資料，再用絕對貢獻與漏斗斷點縮小空間。
- 沒有固定 DAU 口徑 → 事件、視窗或身分規則變化會被誤判為使用者行為 → 先寫清事件、去重鍵、時區、排除項與成熟度。
- 只看分群跌幅 → 小分群的巨大百分比可能解釋不了整體缺口 → 同時計算絕對變化與對淨缺口的貢獻。
- 使用重疊分群後相加 → 同一跨端使用者被重複歸因，貢獻無法重算 → 為貢獻計算建立互斥且完備的分區，重疊標籤另作探索。
- 把發布同日等同於根因 → 版本採用、裝置與地區可能混雜 → 用獨立訊號、可比群體或可控回復驗證。
- 等根因完全確定才行動 → 關鍵路徑持續失敗會擴大使用者損失 → 依影響、信心程度與可逆性設定止損門檻。
- 看到 DAU 恢復就結束 → 資料工作回補或短期通知可能製造表面恢復 → 同時檢查斷點指標、伺服器端結果、使用者回饋與持續時間。
- 把診斷停在圖表上 → 面試官看不到產品判斷 → 明確說出目前結論、行動、負責人、恢復標準與改判條件。
追問及應對
追問一：儀表板下降 15%，但伺服器端成功動作完全穩定，怎麼辦？
把它當作量測事故。比較遺失事件的版本、平台與時間，檢查 SDK、事件名稱、過濾、身分合併與資料延遲；同時凍結依賴該指標的實驗和自動決策。修復後回補可恢復的資料，並在報表標註無法恢復的區間。只要使用者旅程與獨立伺服器端訊號穩定，就沒有依據回復產品。
追問二：所有平台都緩慢下降了八週，沒有明顯發布節點，如何調整？
從事件斷點轉向使用者構成拆解：新使用者流入、啟用、各註冊週留存、活躍頻率與回流分別貢獻多少。依地區、客戶規模與使用情境檢查是否集中，再把管道變化、季節性、價格、競爭或產品價值假設與使用者訪談及可控實驗連接。八週緩降不支持追逐某個單日部署。
追問三：9.4.0 的使用者更願意自動更新，如何避免錯誤歸因？
自動更新意願可能與裝置、地區和活躍度相關。優先使用發布前決定的隨機階段或保留組；沒有隨機化時，在相同裝置、系統版本、地區與歷史活躍度內比較，並檢查更新前趨勢。結論應保留觀察性限制。若使用者傷害明確，仍可依風險做可逆回復，但不要把回復決定包裝成已證明的因果結論。
追問四：回復後 iOS 漏斗恢復，整體 DAU 只恢復一半，下一步是什麼？
先用同一張貢獻表重算剩餘缺口。iOS 回升證明該故障解釋了一部分下降，但不保證只有一個原因。檢查 Web、Android、新舊使用者與管道是否出現第二個獨立變化，也核對回復涵蓋率與資料成熟度。多項因素同時發生時，每次更新都要區分「已解釋缺口」與「尚未解釋缺口」。
追問五：DAU 恢復了，為什麼還要看次週留存？
版本回復、補發通知或資料回補都可能讓單日數字恢復。受影響使用者可能已經流失，或只有開啟行為恢復而核心價值沒有恢復。繼續觀察受影響群體的核心動作、次週留存、客服請求與取消行為，才能判斷事故是否留下後效應；這些是後續驗證，不應改變本輪先止損的決定。