很多公司的成長週報看起來都不差。Marketing 有一組綠燈，Sales 也有，Marketplace 團隊的交易量還在長。真正讓會議開始變難的，往往是另一邊的數字：新客留存走弱、履約變慢、客服量增加，甚至取消與退款也開始往上。
這些數字不一定互相矛盾。它們可能同時都是真的。
問題在於，公司習慣按部門切 Dashboard，客戶卻不會按組織圖移動。一筆生意通常經過的是同一條連續鏈條：
獲客 → 有效需求 → 成交 → 留存與客戶價值 → 交易量 → 供給與產能 → 履約與服務 → 再購 → 經濟結果
所以判斷成長，不能只看某個節點有沒有改善。局部 KPI 變綠之後，還要看它到下一段時剩下多少。
圖：每個局部改善都要穿過下一個商業交接點，才算真正改善整個成長系統。
五張 Dashboard，其實共用同一條商業鏈
先用一個假想 marketplace 來看。
某一季，Marketing 找到一個新渠道。Traffic 大增，報表 CAC 下降，交易量也繼續上升。如果會議停在這裡，這會是一個很漂亮的 growth story。
但後面幾個 team 看到的畫面不同：新流量中符合需求條件的人變少；成交率沒有明顯提升；新客 cohort 的留存變差；需求更集中到供給不足的城市與時段；履約時間被拉長，客服 workload 也上來了。
把這些訊號並排之後，沒有必要先找一個部門背鍋。比較有用的做法是逐段追：Marketing 帶來的 demand 到下一個 stage 時還剩多少品質？成交後的 customer base 有沒有維持價值？更多交易有沒有帶來相稱的收入？供給和服務能力是否接得住？
這也是「做一張超級 Dashboard」常常沒解決問題的原因。五個數字區塊放到同一個螢幕，資訊仍然可能各說各話。真正需要接起來的是 handoff，也就是一個指標改善後，下一個商業環節理應出現什麼變化。
在這個案例裡，CAC 可以下降，GMV 也可以上升，同時 fulfilment 變差。三者都可能正確；只是它們描述的是同一條鏈上的不同位置。
在比較 Dashboard 前，先確認大家拿的是同一把尺
跨部門分析有一種很常見的假精準：兩張表都寫 CAC、conversion 或 retention，於是大家直接拿來比較。
以 CAC 為例。有的團隊只放 paid-media spend，有的把 sales commission、行銷工具、創意與促銷放進去，有的還會納入部分 sales labour。這些都可能叫 CAC，但成本邊界不同。ScaleXP 的 CAC 指南也呈現了這類差異。
因此，在看趨勢之前，先把 Metric Contract 展開。我至少會確認：
| 欄位 | 要問的問題 |
|---|---|
| Stage | 這個 metric 描述商業流程的哪一段？ |
| Economic unit | user、account、order、booking、seller，還是 transaction？ |
| Numerator | 分子到底包含哪些人、事件或金額？ |
| Denominator | eligible population 是誰？ |
| Grain / dimension | user、order、city、channel、product，還是哪個層級？ |
| Time window / cohort | 七天、三十天、一季，還是同一批 acquisition cohort？ |
| Attribution | 什麼條件下成果會歸給這個活動？ |
| Cost boundary | 哪些成本被放進指標？ |
這個檢查很快，但會直接改變商業解讀。假設 CAC 從 100 降到 80，如果分母同時從「新付費客戶」換成「新註冊帳號」，數字本身沒有錯，前後卻不是同一個問題。Conversion 也是一樣，all leads 和 sales-qualified leads 當分母時，不能把百分比的變化當成純粹的 performance improvement。
獲客有變便宜，不代表新增需求更有價值
Marketing 這一段還有另一個容易混掉的概念：attribution 和 causality。
某次轉換被歸因到廣告，只代表 attribution rule 把它算給了廣告；這並沒有直接證明「沒有這個廣告，轉換就不會發生」。Google Ads 的 Conversion Lift 正是用 treatment 與 control 的差異來估計 advertising incrementality。Google Ads Help
所以看到 attributed ROAS 變好或 traffic 上升時，分析還得往後追。這批人有多少會成為 qualified demand？成交後會不會留存？他們集中在哪些供需條件？加入 promotion、return、fulfilment 與 support cost 後，這個渠道還剩下什麼經濟性？
Traffic、Lead、MQL、SQL、Opportunity、Order 的用途，不只是做一條漂亮 Funnel。每一個 stage 都在篩掉一部分不適合往下走的需求。
回到假想 marketplace。新渠道帶來更多 traffic，報表 CAC 也下降，但 qualified-demand rate 同時變差。現階段能安全說的是：前端 attention 買得更便宜了。這批新增 demand 是否更值錢，還沒有證明。
成交率從 8% 到 10% 之後，追的是同一批人
假設新渠道把 conversion 從 8% 拉到 10%。這個結果值得保留，但不要立刻把它升格成完整的 growth win。先把同一批 customers 往後看。
例如，headline metric 和 cohort view 可能長這樣：
| Headline 看起來 | Cohort 拆開後可能看到 |
|---|---|
| Conversion ↑ | 新渠道轉換較高，但首月退款也較高 |
| Retention 持平 | 舊客改善，新客惡化，平均後剛好抵消 |
| ARPU ↑ | 少數高價值客群拉高平均，多數 cohort 沒改善 |
| CAC ↓ | acquisition 變便宜，但低價值 cohort 比例變高 |
Customer lifetime value 的研究長期把 acquisition、retention、profitability 與 customer heterogeneity 放在一起處理。Gupta 等人的 CLV 綜述也指出，不同客群的留存與價值特性可能差很多，aggregate average 因此會遮掉重要差異。Gupta et al., Modeling Customer Lifetime Value
這裡需要的不是把 dashboard 再切更多張，而是用真正會改變商業機制的維度去連 cohort，例如 acquisition channel、segment、geography 或 category。
假想案例到了這一步，conversion 沒有崩，但新客 retention 比原本差。這使「CAC 下降」的解讀縮小很多：它描述了 acquisition cost，卻還不能代表取得了同樣品質的 customer base。
交易量長得很好時，再把 GMV 接到收入與成本
Marketplace 很容易把 GMV、GOV、GBV 這類 gross volume 看成最接近「生意規模」的數字。它們確實重要，但 gross volume 與公司最後認列的 revenue 中間通常還有好幾層。
Airbnb 的 2020 Form 10-K 對 Gross Booking Value 的定義包含經濟上屬於 hosts 與 taxing authorities 的金額，也包含相關服務金額，因此 GBV 的範圍明顯比 Airbnb recognised revenue 更廣。Airbnb 2020 Form 10-K
分析時可以先把 bridge 寫出來：
Gross volume → fee base → take rate / fee architecture → recognised revenue → variable cost → contribution economics
Take rate 也有自己的 denominator contract。eBay 的 2024 Form 10-K 以 net revenues 相對 GMV 定義 take rate。eBay 2024 Form 10-K 做跨期或跨公司的比較時，期間、幣別、取消退款處理以及 transaction population 都要先對齊。
再往下一層，平台的 fee architecture 可能根本不是一個百分比。Amazon seller pricing 同時有 subscription plans、category-based referral fees 與其他 charges。Amazon Seller Pricing 因此一句「平台抽成 15%」很可能把真正的 monetisation mechanics 壓扁了。
假想 marketplace 此時仍然可以報告交易量成長。接下來要看的，是其中多少活動最後變成 revenue，以及服務這些交易之後還留下多少 contribution。
Demand 跑得比 Supply 快時，成長會先出現在營運壓力上
現在把案例再往下推。新渠道帶來的需求並不是均勻分布，而是更多落到原本就供給不足的城市與時段。訂單仍在增加，但 fulfilment 變慢，cancellation、refund 或 support workload 也可能開始往上。
這時候先不要找一個「平台成長到多少就會壅塞」的固定 benchmark。平台可以同時有 network effects 和 congestion effects；相關研究提出了使用者增加後壅塞可能壓低 service quality 的機制，但沒有給所有平台一個通用臨界值。Journal of Economic Interaction and Coordination
實務上更有用的是查 constraint：需求長在哪裡？當地 seller、driver、inventory 或其他 capacity 夠不夠？地區和時段 imbalance 是否惡化？履約時間、取消、退款、rework、support contact rate 或 handling load 怎麼走？為了守住服務品質，是否開始需要更多補貼、人力或營運成本？
成本也要跟著拆。Contribution analysis 的基本用途之一，就是把行為不同的成本層分開。OpenStax 對 contribution margin 與 contribution-format income statement 的整理提供了這個會計骨架。OpenStax, Principles of Managerial Accounting
在跨部門 growth analysis 裡，可以依公司實際成本結構建立類似這樣的 ladder：
交易直接變動成本 → 履約 / 服務成本 → 客戶或渠道可避免成本 → 共享固定成本
這不是 universal template。它只是在防一個很實際的錯誤：下游 service cost 全塞在一個模糊 margin 裡，上游的 volume growth 於是看起來比真實 economics 更乾淨。
到這裡，案例中的每張 Dashboard 都有合理訊號。Marketing 看見便宜的 acquisition；Marketplace 看見更多交易；Operations 看見 capacity 壓力；Support 看見更多負荷。要做的是把它們重新對帳。
把整條鏈重新對帳：改善到底有沒有活過每個 Handoff？
遇到「某個 KPI 變好了，但 business outcome 沒有同步變好」時，可以從改善發生的位置開始，沿著鏈條往後查。
1. 鎖定 Metric Contract
先確認 formula、numerator、denominator、grain、cohort、time window、attribution 與 cost boundary。若定義變了，先把比較重做。
2. 標出它所在的 Stage
Acquisition、qualification、conversion、retention、transaction volume、supply、fulfilment 或 economics，先知道現在看到的是哪一層。
3. 寫下下一個理應跟著改善的 Handoff
Acquisition quality 變好，通常應該在 qualified demand、conversion 或 cohort value 看見相容訊號。Transaction volume 變得更健康，則要往 monetisation、service capacity 或 contribution economics 找。
4. 拆 Cohort 與 Mix
新舊客、channel、geography、category 或 supply structure 混在 overall average 裡，很容易把方向相反的變化平均掉。
5. 對 Volume、Monetisation 與 Cost
Traffic、order、GMV、take rate、revenue 和 cost 是不同層。把 population、denominator 與 economic meaning 一層層對回去。
6. 查 Supply 與 Service Constraint
需求是否已經超過可服務 capacity？如果 fulfilment、cancellation、support burden 或 subsidy 同時惡化，這些就是 growth 是否穿過營運 handoff 的證據。
7. 再決定這是不是 System-level Improvement
如果局部 KPI 改善，下一個具有經濟意義的 handoff 卻沒有跟上，先把它留在 local win。等證據穿過後面的 chain，再升格成 growth win。
這也正好解釋開頭的 marketplace。便宜、量大的 acquisition 是一個真實改善，但它沒有同等程度地穿過 demand quality、cohort value 與 supply/service capacity。沒有任何一個部門必須「錯」，只是整個系統沒有得到同樣幅度的改善。
最後留下的判斷規則只有一條：
一個指標還不能算真正的綠燈，直到它的改善穿過下一個具有經濟意義的交接點。
References
- Google Ads Help, About Conversion Lift
- ScaleXP, Customer Acquisition Costs
- Gupta et al., Modeling Customer Lifetime Value
- Airbnb, 2020 Form 10-K
- eBay, 2024 Form 10-K
- Amazon Seller Services, Pricing
- Journal of Economic Interaction and Coordination, Congestion, network effects and platform competition
- OpenStax, Principles of Managerial Accounting, Chapter 3 Summary