「可以給我今天下午剛連續儲值三次的玩家名單嗎？我們要在晚上八點前發推播。」
行銷主管在下午四點傳來這個需求，你打開後台一看...最新的資料停在昨天晚上 23:00。你秒回工程師群組問能不能手動跑一次更新，得到的回覆是：「ETL 流程要跑三小時，而且現在跑會影響到其他報表...」
晚上八點的推播計畫泡湯，客戶抱怨「你們系統怎麼連這麼基本的需求都做不到」，你夾在中間裡外不是人。這不是你第一次遇到這種事。上次是營運要「剛流失的用戶名單」，再上次是客服要「今天投訴兩次以上的玩家清單」。每次都是一樣的劇本：需求很急、數據很慢、最後妥協用昨天的舊資料硬著頭皮做。
問題到底出在哪？
1.資料從發生到你看見，中間隔了一座山
大部分 PM 都知道「資料需要處理」，但很少人真的理解這個處理到底有多複雜。
讓我們追蹤一筆「玩家儲值」的資料旅程：
14:30 - 玩家按下儲值按鈕 資料寫進交易資料庫（Database），這裡只記錄最原始的資訊：訂單編號、金額、時間戳記。
18:00 - 第一次資料轉換 ETL 流程啟動，把原始交易資料「抽取」出來，跟用戶資料表、商品資料表做關聯，補上玩家 ID、等級、購買的是哪個商品包。這個過程叫做「資料整合」。
21:00 - 第二次資料轉換 整合好的資料再進一步加工：計算這個玩家今天是第幾次儲值、累計金額、距離上次儲值多久。這些「衍生指標」要花時間算。
23:00 - 寫入分析資料表 處理完的資料才終於寫進你平常看的那張「玩家行為分析表」，也就是 BI 工具接的那張 Table。
從玩家按下按鈕，到你能在後台看到這筆資料，中間隔了 8.5 小時。
而且這還是「順利」的情況。如果 ETL 流程遇到資料格式異常要重跑、或是剛好碰上流量尖峰要排隊，延遲可能會更久。
2.為什麼不能「即時」？三個你必須知道的現實
現實一：資料倉儲不是為了即時設計的
現代資料架構就像是一個「文件簽核流程」。
原始資料從各個系統（Database）產生，經過 ETL 這個「審核關卡」進行清洗、整合、計算，最後才進到「資料倉儲」（Data Warehouse）讓你查詢。
這個架構的設計邏輯是：犧牲即時性，換取資料品質和查詢效能。
想像一下，如果每次玩家儲值都要即時更新所有相關指標（今日儲值次數、累計金額、與上次間隔...），系統會被這些計算拖垮。所以工程師選擇「批次處理」：每隔幾小時統一算一次，效率比較高。
現實二：One Big Table 的代價
很多公司為了方便，會把所有需要的欄位都塞進「一張大表」（One Big Table）。
這張表可能有 200 個欄位：基本資料、行為資料、消費資料、裝備資料... 應有盡有。PM 和分析師超愛這種表，因為「什麼都查得到」。
但這張表的更新成本非常高。
因為它要等「所有上游資料源」都更新完，才能整合進來。任何一個環節卡住（比如裝備資料表今天有異常），整張表都要延遲。就像一份報告要等十個部門都簽核完才能定稿，只要有一個部門慢了，整份報告都出不來。
現實三：即時資料的成本，高到你想像不到
技術上要做到「即時」不是不行，但代價是：
- 要重新設計整個資料架構：從批次處理（ETL）改成串流處理（Stream Processing），這基本上是打掉重練。
- 維運成本暴增：即時系統要 24 小時監控，任何異常都要立刻處理，不能像現在這樣「晚上跑壞了，明早再修」。
- 指標會變簡單：即時系統沒辦法做太複雜的計算，那些「過去 30 天平均值」、「同期比較」之類的進階指標可能做不出來。
以我遇過的案例，導入即時資料系統的成本大約是原本資料團隊預算的 2-3 倍。
3.PM 可以做的三件事
面對這個現實，PM 不是只能摸摸鼻子接受。以下是三個實際可行的應對策略：
策略一：需求分級，不是所有需求都要即時
先問自己三個問題：
- 這個需求的時效性真的是「小時」嗎？ 很多時候客戶說要「即時」，其實「每天早上 9 點更新」就夠了。
- 延遲 6 小時會造成多大損失？ 如果是「流失預警」這種需求，晚 6 小時可能用戶已經刪遊戲了。但如果是「本週活躍排行」，晚個半天根本沒差。
- 有沒有替代方案？ 比如「剛儲值三次的玩家」，能不能改成「昨天儲值三次的玩家」？或是用「本週累計儲值金額 Top 100」來替代？
把需求分成三級：
- 真・即時（1 小時內）：例如防詐騙、異常交易預警
- 準即時（6 小時內）：例如當日活動成效追蹤
- 非即時（隔日即可）：例如每週報表、月度分析
大部分需求其實落在「準即時」和「非即時」，這些都可以用現有架構解決。
策略二：理解你的資料更新週期，設定合理預期
去問你的資料工程師一個簡單問題：「我們的 ETL 多久跑一次？」
答案可能是：
- 每天晚上 23:00 跑一次（隔日資料）
- 每 6 小時跑一次（當日資料，但有延遲）
- 重要指標每小時跑一次（準即時）
知道這個週期後，你就能：
- 跟客戶設定正確預期：「這個名單我們明天早上 10 點給您」而不是「我看看能不能生出來」
- 規劃需求的提出時間：如果 ETL 是晚上 11 點跑，你下午 4 點要資料根本來不及
- 評估需求的可行性：某些需求可能根本不適合用現有架構做
策略三：跟工程團隊一起設計「快車道」
不是每個指標都要走完整的 ETL 流程。
對於真的很關鍵的即時需求（比如防詐騙、客訴預警），可以跟工程團隊討論設計「快車道」：
- 直接從交易資料庫撈：犧牲一些關聯資料的完整性，但可以做到「15 分鐘延遲」
- 設定觸發條件：當特定事件發生（連續儲值 3 次、單日客訴 2 次），系統主動發通知，而不是被動等你查詢
- 縮小範圍：不要整張大表都即時，只把最關鍵的 10 個欄位拉出來做即時更新
我之前的專案就是這樣處理：一般報表還是走每日 ETL，但「高風險交易預警」開了一條快車道，直接從交易 DB 每 30 分鐘撈一次，滿足了營運最迫切的需求，成本也控制在合理範圍。
4.你要記得的事
資料延遲不是 bug，是設計上的取捨。
那些「即時資料」的系統，背後都是用更高的成本、更複雜的架構、更簡化的指標換來的。在大部分情況下，根本不划算。
身為 PM，你的職責不是「滿足所有需求」，而是「找到成本和價值的平衡點」。
下次當客戶又說「我要即時的玩家名單」，你可以這樣回：
「這個需求如果要做到真正即時，我們需要改造整個資料架構，成本大約是現在的三倍，而且會影響現有報表的穩定性。但如果改成『每 6 小時更新一次』，我們下週就能上線，而且根據過去數據，6 小時的延遲對轉換率的影響小於 5%。您覺得哪個方案比較適合？」
把選擇權和判斷依據交給客戶，而不是把自己逼到死角。
這才是 PM 該做的事。
