資料分析師面試問題

框架: 篩選 → JOIN → 分組 → 排序 → 取前幾筆

假設我們有 customers(customer_id, name) 和 orders(order_id, customer_id, order_date, status, revenue) 兩張表。我會先確認營收要不要包含已取消或已退款的訂單，一般來說只算已完成的訂單。 查詢的做法是：把訂單篩選到過去 30 天、狀態為已完成，依客戶分組加總營收，由高到低排序，最後取前 5 筆。如果邏輯變得比較複雜，我會用一個 CTE 先整理出符合條件的訂單，讓查詢更清楚。 有幾個細節很重要：要用對日期欄位；除非先彙總過，否則不要 JOIN 品項層級的資料表；還要決定同分時怎麼處理。如果同分的客戶也要列入，而且資料庫支援，我會改用排名類的視窗函數，而不是單純 LIMIT 5。 最後我也會驗證結果，檢查符合條件的營收總額、資料列數，以及前幾名客戶有沒有可疑的重複訂單列。

框架: 定義 cohort → 定義回訪事件 → LEFT JOIN → 彙總

首先要把留存定義清楚。我會把 1 月 cohort 定義為註冊日期介於 1 月 1 日到 2 月 1 日之間的使用者。如果使用者在註冊後第 7 天至少有一次符合條件的活躍事件，就算 7 日留存；但如果公司對留存的定義是 7 天內有回訪，那就要看第 1 到第 7 天之間。這一點我會在寫查詢前先釐清。 如果是精確的第 7 天留存，我會先建立一個 cohort CTE，包含 user_id 和 signup_date。接著用 user_id LEFT JOIN 事件表，條件是 event_date 等於 signup_date + interval 7 days，而且 event_name 是有意義的活躍事件。分母是 cohort 中不重複的使用者數，分子是有對應事件的不重複使用者數。 關鍵在於用 LEFT JOIN 保留沒有任何活動的使用者。如果用 INNER JOIN，沒有留存的使用者會被排除，留存率就會被灌高。另外要計算不重複的 user_id，避免同一位留存使用者因為多筆事件被重複計算。 最終指標是 retained_users / cohort_users。如果面試官要我進一步診斷，我會再依來源管道、平台、地區或註冊週別做分群。

框架: 依使用者為購買紀錄排名

我會用視窗函數，依購買時間為每位使用者的已完成購買排名。先篩選出已完成的購買，再套用 row_number() over partition by user_id order by purchase_at，row_number = 2 的那一筆就是第二次購買。 篩選的順序很重要。如果已取消或已退款的購買不該計入，就要在排名之前先排除。如果有多筆購買的時間戳記完全相同，我會加上 order_id 這類固定的次要排序條件，確保結果一致。 輸出可以包含 user_id 和 second_purchase_at。如果面試官要的是至少購買過兩次的使用者，就只回傳排名為 2 的資料列；如果要列出所有使用者，沒有第二次購買的顯示 NULL，就把結果再 LEFT JOIN 回 users 資料表。 時間複雜度由資料庫處理，但實務上如果資料表很大，在 user_id 和購買時間戳記上建立索引會很有幫助。

框架: 每位使用者一列，記錄各步驟的時間戳記

我會整理成每位使用者一列，記錄每個漏斗步驟最早發生的時間戳記，這樣可以避免同一位使用者多次觸發同一個事件而被重複計算。做法是對事件表做條件式彙總：min(case when event_name = signup then event_at end)、min(case when event_name = email_verified then event_at end)，依此類推。 接著視需求強制步驟順序。例如電子郵件驗證要發生在註冊之後、新手引導要在驗證之後、首次購買要在新手引導之後。如果商業上要看的是不論順序的寬鬆轉換，我會明確說出這個假設。 轉換指標包括：註冊到驗證、驗證到新手引導、新手引導到購買，以及從註冊到購買的整體轉換。每一步以該步驟的不重複使用者數為分子、前一步為分母。再依平台、來源管道、裝置、地區與 cohort 日期分群，找出流失集中在哪裡。 需要注意的邊界情況包括：重複事件、使用者跳過步驟、時區邊界、機器人或測試帳號，以及延遲送達的事件資料。

框架: 驗證 → 分群 → 漏斗 → 外部因素 → 建議

我會先確認這次下滑是不是真的。檢查追蹤設定有沒有變動、資料管線是否延遲、有沒有時區問題、機器人過濾規則、App 版本更新，以及下滑是否同時出現在多個儀表板或原始資料表中。 接著把下滑分群拆開來看：平台、App 版本、地區、來源管道、使用者加入時間長短、付費與免費使用者、裝置類型，以及流量來源。如果是全面性的下滑，可能是追蹤、基礎架構或產品層面的大範圍問題；如果只集中在某一塊，就會指向特定的平台、版本、市場或管道。 再來檢視使用者旅程。是 App 開啟數下降、登入成功率下降、首頁載入失敗、通知成效變差，還是使用者進來之後核心行為減少？如果 App 開啟數穩定、但核心活動下降，問題出在產品內部；如果 App 開啟數本身就下降，就要看通知、新客導入、季節性、服務中斷或外部事件。 最後依根本原因提出行動建議。如果 iOS 的 DAU 在新版發布後下滑、當機率又上升，就退回上一版或推出 hotfix；如果只有付費廣告導入的使用者減少，就檢查廣告投放預算與歸因；如果是資料延遲，就先說明這個限制，避免製造不必要的急迫感。

框架: 目標 → 主要指標 → 輸入指標 → 護欄指標 → 分群

我會從目標開始。推薦功能的目的可能是提升商品探索、互動、轉換、留存或訂單金額。主要指標應該反映這個功能想帶給使用者的價值，而不只是點擊。以電商推薦為例，比較好的指標可能是每位活躍使用者從推薦商品產生的購買數或加入購物車次數。 輸入指標包括推薦曝光數、點擊率、加入購物車率、轉換率、每工作階段營收、覆蓋率與多樣性。護欄指標則包括退貨、退款、低品質點擊、頁面延遲、使用者客訴，以及對自然探索的排擠效應。 我會再依新舊使用者、商品類別、裝置、流量來源與推薦版位做分群。模型有可能讓整體平均表現變好，卻傷害了新使用者或長尾商品的曝光。 如果可行，我會用 A/B 測試評估這個功能，之後再持續追蹤長期留存與回購行為。如果使用者其實是被引導到不相關或滿意度低的商品，那短期的點擊提升並不夠。

框架: 把營收拆解為流量、轉換率、AOV、組合、價格、留存

營收通常可以拆成流量 × 轉換率 × 平均客單價，再加上產品組合、定價、回購與退款的影響。如果營收上升、轉換率卻下降，有幾種可能的解釋。 流量增加的幅度，可能足以抵銷較低的轉換率。平均客單價可能因為調價、組合方案、企業客戶、購物車變大，或產品組合轉向高價商品而上升。公司也可能減少了購買意圖低的流量，使轉換率下降，但成交的購買價值更高。另外，也可能是追蹤方式改變，影響了營收或轉換率的數字。 我會依管道、產品、地區、新舊使用者、客戶等級與裝置做分群，再把營收拆解成工作階段數、轉換率、AOV、退款率與回購。我也會確認轉換率是以工作階段、使用者還是訪客為單位計算，因為分母改變可能造成誤導性的趨勢。 建議取決於成長的品質。如果營收成長來自更健康的高價值客戶，轉換率下降或許可以接受；但如果是來自一次性的漲價，同時新客轉換率正在走弱，這可能就是未來成長的風險。

框架: 對象 → 決策 → 指標 → 切分維度 → 警示

我會先定義使用對象，以及他們要做的決策。高階主管需要的是成長、留存、變現與風險的整體概況，不需要在第一個畫面就看到所有營運細節。 最上層的指標包括：月經常性營收（MRR）、淨營收留存率、總營收留存率、新增 MRR、擴充 MRR、縮減 MRR、流失 MRR、活躍客戶數、試用轉付費轉換率、ARPU、可取得的話再加上 CAC 回收期，以及預測與目標的對比。 實用的切分維度包括：客戶區隔、來源管道、方案、地區、公司規模、cohort 月份，以及業務協助成交與自助購買。視覺化應該包含趨勢線、cohort 留存、MRR 橋接圖、流失原因與目標差異。 設計原則：清楚標示指標定義、資料更新時間、篩選條件、負責人與警示門檻。避免虛榮指標，也不要在沒有清楚標示的情況下，把使用者數和營收指標混在一起。這個儀表板要回答的是：我們有沒有在成長？為什麼？風險在哪裡？主管接下來該追查什麼？

框架: 釐清決策 → 說明風險 → 提出更好的呈現方式

我會先釐清對方想做什麼決策。有時候利害關係人指定某張圖表，是因為心裡已經有想講的故事，但他們真正需要的是一個商業問題的答案。 接著我會清楚、不帶防衛心地說明風險。舉例來說，累計營收圖永遠只會往上走，可能掩蓋最近的成長趨緩；類別太多的圓餅圖會讓差異看不出來；沒有信賴區間的圖表可能誇大了精確度；沒有考慮流量組合的轉換率也可能造成誤導。 我會提出能更準確回答同一個問題的替代方案，例如趨勢線、cohort 圖、漏斗圖、分布圖、分群長條圖或指標拆解。如果對方仍然需要原本那張圖，我可能會附上並加註說明，但不會把有誤導性的分析當成我的建議提出來。 目的是維持信任。分析師應該樂於協助，但也要為分析的嚴謹與正確負責。

框架: 剖析 → 標準化 → 驗證 → 記錄

我會先剖析資料：資料列數、欄位名稱、缺漏值、重複值、資料型別、不可能出現的數值、日期格式與離群值。在做任何轉換之前，我會先保留一份原始資料。 接著把欄位標準化：去除多餘的空白、統一大小寫、解析日期、換算幣別或單位、必要時拆分合併在一起的欄位，並把不一致的類別對應到一份統一的標準清單。處理重複值時，我會先定義商業上的識別鍵，再決定要刪除什麼。 再來用可信的來源驗證總數。例如總營收要能和財務匯出的資料對得上，訂單數要和來源系統一致，日期範圍也要完整。我會針對 NULL 比例、不重複計數與類別值建立檢核。 最後把轉換過程記錄下來。用來做決策的試算表，應該讓假設一目了然、把原始資料和清理後的資料分開，並避免無法查核的隱藏手動修改。

框架: 探索 vs. 可控的計算

樞紐分析表非常適合快速探索資料，可以跨維度分組、切分與彙總。當問題是依類別看總數、筆數、平均或趨勢，或利害關係人想要互動式篩選時，樞紐分析表就很好用。 當邏輯是客製化、多步驟、需要可查核，或需要精確控制時，用公式做分析會比較好。例如 cohort 計算、瀑布模型、加權評分、例外標記、對帳檢核，或是要餵進預測模型的輸入值。 實務上我通常兩者並用：先用樞紐分析表快速找出規律，再用公式或更乾淨的模型產出最終答案。如果是定期報表，我會優先選擇可重現的查詢或 BI 資料流程，而不是容易出錯的手動試算表。

框架: 假設 → 隨機分組 → 指標 → 護欄指標 → 決策

假設：改版後的結帳頁能減少阻力、提高完成購買的比例，而且不會對後續環節造成負面影響。 我會先確認實驗設定：隨機分組單位、樣本數、實驗期間、曝光紀錄、參與資格，以及使用者在不同工作階段中是否都維持在同一個版本。如果用工作階段而不是使用者來隨機分組，使用者回訪時就可能污染實驗結果。 主要指標：從開始結帳到完成購買的結帳轉換率。次要指標：付款失敗率、結帳所需時間、平均客單價、加購率與回訪次數。護欄指標：退款、信用卡爭議款、客服工單、延遲、錯誤率與客訴。 分析時要同時看統計顯著性與實務顯著性。提升幅度太小，可能不值得付出額外的工程複雜度。分群分析可以看出是不是行動裝置變好、桌機卻變差，但不要對雜訊大的小群體反應過度。 建議：如果主要指標有實質改善、護欄指標正常、追蹤資料可信，而且效果在整個測試期間都持續存在，就可以上線。

框架: 檢查檢定力 → 觀察方向 → 評估成本 → 做出決定

結果不顯著，不代表這個功能就一定沒有效果。我會先確認這次測試的檢定力是否足以偵測到有意義的效果。如果樣本數太小或指標雜訊太大，結果可能只是無法下定論。 接著看效果量和信賴區間。如果區間同時涵蓋有意義的正面效果和有意義的負面效果，代表測試結果並不確定；如果區間緊密集中在 0 附近，這個功能對該指標的影響可能很小。 再來考量成本和策略。如果這個功能維護成本高、又看不出可衡量的效益，就不要上線，或把它撤回。如果它在策略上很重要、風險低，或能改善質性的使用者體驗，可以考慮繼續迭代，或改用更合適的指標來衡量。 我會這樣總結結果：我們測了什麼、觀察到什麼、有多大的把握、有哪些限制，以及我建議的決策是什麼。

框架: 定義 → 資料來源 → 篩選條件 → 粒度 → 時間點 → 對帳

我會先比較定義。一個儀表板可能顯示總營收，另一個顯示扣除退款、折扣、稅金或信用卡爭議款後的淨營收。營收認列的時間點也可能不同：訂單日期、付款日期、出貨日期或發票日期。 接著比較資料來源、篩選條件與粒度。其中一個儀表板可能排除了測試帳號、已取消訂單、內部使用者、企業發票或特定地區；另一個可能把訂單品項 JOIN 錯了，導致營收重複計算。另外也要檢查時區與資料更新時間。 我會以可信來源為基準建立對帳橋接：從儀表板 A 的營收出發，一步步加減差異，直到和儀表板 B 對上為止。每一筆差異都要有明確的原因。 最後的產出不應該只是「儀表板 A 錯了」，而是修正後的定義、負責人、單一可信來源，以及避免日後再混淆的計畫。

框架: 量化缺漏 → 診斷原因 → 選擇處理方式 → 揭露影響

我會先量化缺漏的程度：哪些欄位、多少資料列、占多少比例，以及缺漏情形是否因分群、時間、來源或平台而不同。缺漏資料不一定是隨機發生的。 接著診斷缺漏的原因。可能是使用者選填的欄位、追蹤失敗、資料延遲送達、系統整合問題、隱私限制，或本來就是「不適用」的合理值。處理方式取決於原因。 可行的做法包括：排除這些資料列、插補數值、新增「未知」類別、從其他來源回補，或調整分析範圍。我會避免直接把缺漏值補成 0，因為「0」和「未知」代表的意義不同。 最後要揭露影響。說明缺漏資料對結論可信度的影響，以及在合理的假設下，建議是否會因此改變。

框架: 決策 → 分析 → 洞察 → 建議 → 影響

挑一個分析明確影響了決策的故事。先說明當時面臨的商業決策是什麼：產品上線、定價、行銷預算、產品調整、營運，或優先順序。 接著用白話說明你的分析。你用了哪些資料、哪個指標最關鍵、檢視了哪些分群、有什麼出乎意料的發現？不要把整個回答都花在介紹工具上，面試官想知道的是你的工作如何改變了大家的想法。 然後說明你的建議和帶來的影響。例如，你的分析發現某個行銷活動整體看起來有獲利，但在其中一個管道其實是虧錢的，於是團隊重新分配預算，ROI 也因此提升。又或者某個產品功能提升了點擊，卻降低了留存，於是團隊把它撤回。 好的回答也會交代注意事項，以及你如何與利害關係人溝通。說明你如何處理不確定性，又如何讓建議容易被理解。

框架: 釐清急迫性 → 提供方向性判讀 → 說明限制 → 規劃後續

我會先釐清決策內容和期限。如果決策風險低，方向性的答案或許就夠了；但如果會影響營收、客戶、法規遵循或策略，品質門檻就應該拉高。 接著我會說明哪些問題現在可以回答、哪些還不行。我可能會先提供初步判讀，並清楚加註：「根據目前可取得的資料，趨勢看起來是負面的，但 Android 使用者的追蹤資料還不完整，所以我還不建議現在就做出最終的上線決策。」 我會把立即的答案和後續計畫分開。立即提供：目前最好的估計值和信心程度。後續跟進：資料清理步驟、驗證檢核、與單一可信來源的對帳，以及什麼時候能給出更可靠的答案。 這樣做能讓利害關係人持續推進工作，同時守住分析的嚴謹度。最糟的答案，是一個又快又篤定、但卻是錯的數字。

框架: 影響 → 急迫性 → 投入成本 → 相依性 → 與利害關係人取得共識

我會根據商業影響、急迫性、所需投入、相依關係，以及這份分析是否攸關一個無法回頭或高風險的決策來排序。和明天上線決策相關的需求，通常會優先於錦上添花的儀表板改善。 我也會釐清每個需求要支撐的決策是什麼。如果某個需求沒有明確的決策或負責人，可能要先把需求釐清，再開始分析。對於重複出現的需求，我會尋找自動化的機會，避免團隊被困在手動報表裡。 當優先順序互相衝突時，我會清楚說明取捨：「今天我可以完成流失分析，或是更新儀表板，但沒辦法兩個都做。因為流失分析會影響這週的留存計畫，我建議先做這個。」 優秀的分析師不會照單全收、依序處理每個需求，而是幫助組織把分析的時間花在能改變決策的地方。