兩家公司都說自己今年的「業務規模」成長 30%。

一家是 SaaS，簡報第一頁放 ARR；另一家是 Marketplace，放 GMV。若只看成長率，30% 對 30% 很乾脆。問題是，ARR 跟 GMV 根本沒有在回答同一件事。

ARR 通常描述經常性業務的 run-rate；GMV 則是在算平台上發生了多少交易。ARR 和會計營收之間還有一道定義邊界，平台也不會把整筆 GMV 都認成自己的收入。比較之前，先把指標背後那份「計量合約」拆開，通常比找更多 benchmark 有用。

先確認你到底在量誰

「每個客戶貢獻多少」聽起來很直白，直到兩家公司對「客戶」的定義完全不同。

SaaS 可以用 account、subscriber、contract、seat 或 workload 當分析單位。Marketplace 同時面對消費者、商家、供給者與交易本身，留存、獲客成本、收入和服務成本未必能掛在同一個分母上。

我會先找一個最小分析單位，讓營收、可變成本、留存與獲客經濟性都能一致地掛在它身上。這裡說的 Economic Unit 是分析工作用的定義，不是會計準則術語。

Spotify 的 Premium ARPU 很適合拿來看這件事。年報把算法直接拆開：季度 Premium subscription revenue、平均每日 Premium Subscribers，再除以三個月。Spotify 2025 Annual Report

所以看到熟悉的 KPI 名稱時，我反而會先問：母體是誰、期間多長、分母怎麼算。名字一樣，不代表算的是同一件事。

GMV 很大，不代表平台營收也一樣大

Marketplace 最容易出現的錯位，是把交易規模和公司收入疊在一起看。

Airbnb 對 Gross Booking Value 的定義包含 host earnings、service fees、cleaning fees 與 taxes，再扣除取消與變更。這個數字描述平台上的交易活動，和 Airbnb 認列的營收是兩個不同層次。Airbnb 2020 Form 10-K

如果要再往下看平台到底拿走多少價值，才會碰到 take rate 或 Net Revenue Margin 這類比率。eBay 的文件把 take rate 定義成 net revenues 除以 GMV。這個比率看起來只有一條除法，但期間、幣別、交易母體、取消與退款口徑只要不同，兩家公司算出的 percentage 就未必可比。eBay 2024 Form 10-K

SaaS 也有類似問題。ARR、MRR 可以很好地描述 recurring business 的規模或 run-rate，卻不會自動變成 GAAP 或 IFRS revenue。合約、usage、minimum commitment、services 等項目怎麼處理，要回公司自己的定義看。

因此同樣一句「成長 30%」，我會先辨認它在講活動量、run-rate，還是公司實際認列／捕獲的收入。這一步還沒做完，30% 本身沒有太多可比性。

SaaS 與 Marketplace 的五層指標對照：經濟單位、活動、價值捕獲、可變經濟性與 cohort durability。圖中提醒 ARR 不等於 GMV、GMV 不等於營收，而且 NRR 高於 100% 仍可能有客戶流失。

各列對齊的是同一個經濟問題，不代表左右兩個指標可以直接互比。ARR/MRR 描述經常性業務規模；take rate 則用來觀察 Marketplace 如何把 GMV/GOV 轉成平台營收。

Retention 的分母常常比答案更重要

留存數字最容易讓人產生「這個生意很黏」的直覺，但要先看留的是什麼。

假設期初有 100 個 account，10 個流失，logo retention 是 90%。剩下 90 個客戶若因升級或 usage 增加，讓同一 cohort 的 revenue 從 100 成長到 110，revenue retention 仍然可以超過 100%。所以 NRR > 100% 可以和 logo churn 同時出現。

這也是為什麼 logo retention、GRR、NRR 不能互換。Logo retention 看單位有沒有留下；GRR 看既有 cohort 在 churn、contraction 後保住多少 revenue；NRR 再把同一批客戶的 expansion 放回來。

Snowflake 在年報裡計算 Net Revenue Retention Rate 時，會固定既有 customer cohort 與 measurement window，再比較同一 cohort 的收入。Snowflake Fiscal 2025 Annual Report Cloudflare 的 dollar-based net retention 也是先鎖一批既有 paying customers，再比較這一批的 annualised revenue。Cloudflare 2021 Annual Report

Marketplace 又多一層：它常常沒有單一的 customer。DoorDash 這類 multi-sided marketplace 同時有 consumer、merchant 與履約供給側，各自有 acquisition、activation、retention 與 service economics。分析時需要分開看各側的 CAC 與留存；把它們壓成一個「customer retention」或一個 CAC/LTV，很容易把不同機制互相抵銷。DoorDash 2024 Form 10-K

新客變多，也會讓整體平均值看起來不一樣

即使 cohort 已經鎖好，成熟度還會干擾比較。

高速成長的公司，母體裡通常塞進更多新 cohort；成長較慢的公司，成熟 cohort 占比可能更高。如果 churn、usage、order frequency 或 margin 會隨 tenure 改變，兩家公司同一季的 aggregate retention rate 就混入了不同的 cohort age mix。

Fader 與 Hardie 的 retention projection 研究指出，走到不同 tenure 的存量客戶並非同質母體，留下來的是哪些人，本身就會改變整體 retention pattern。How to Project Customer Retention LendingClub 的年報也用帶時間維度的 vintage／cohort 脈絡去觀察 originations 與 credit performance，這類做法提醒我們：aggregate average 可能把成熟度藏掉。LendingClub 2024 Annual Report

實務上，我會把 cohort 的進入時間、觀察窗、產品／價格條件和成本口徑一起記住。若留存或經濟價值會隨 tenure 明顯改變，再考慮 CLV 或 survival model。Berger 與 Nasr 的經典 CLV 模型就是這類方法的重要基礎。Customer Lifetime Value: Marketing Models and Applications

模型的工作只是逼我們把「誰、從什麼時候開始、看多久、現金流怎麼算」說清楚。

收入往下再走一層，才看得到成本邊界

現在假設交易活動、收入與 cohort 都對齊了，還是不能急著拿兩個 margin 排名。

SaaS 的 gross margin 會受到 infrastructure、support、third-party service cost 等分類影響。Marketplace 的 consumer incentives、merchant incentives、payments、fulfilment、support、refunds，則可能分散在不同 accounting 或 non-GAAP 邊界。成本放在哪裡，會直接改變一個 margin-like ratio 的外觀；incentive 若以不同方式和營收互抵，也會讓收入與 monetisation 指標變得更難直接比較。

看 Marketplace 時，我常先把實際經濟路徑寫成一條工作用的 bridge：

orders × average transaction value → GMV / GOV → monetisation → revenue → variable contribution

這條式子只是檢查順序，不是通用會計公式。DoorDash 的 Q1 2025 results 把 Marketplace GOV、revenue 與 monetisation／contribution 類指標分開揭露，正好讓這幾層可以逐段看。DoorDash Q1 2025 Financial Results

這裡最容易誤判的是 take rate。它上升時，平台可能真的捕獲更多價值；也可能同時付出更多 incentives、承擔更重的履約成本，或只是交易 mix 變了。要判斷 economics 有沒有變好，還得繼續往 contribution boundary 走。

若要把營收變動拆成交易量、average order value、mix、incentive、monetisation 等因素，最後也要能加總回原始差異；解釋不完的部分就保留 residual。這種 reconciliation 紀律和財務分析裡的 bridge 思路一致。IAS 7 Statement of Cash Flows

Snowflake 與 DoorDash，先翻譯再比較

到這裡再看 Snowflake 與 DoorDash，會比一開始直接比 KPI 安全很多。

Snowflake 這邊，我會先鎖定 customer/account cohort，確認 usage 或 contract 的範圍，再看 recurring activity 如何變成 product revenue；之後才接服務成本、gross economics，以及 logo retention、revenue retention、expansion。

DoorDash 的起點不同。先拆 consumer、merchant、order／transaction 等不同單位，再看 orders 與 Marketplace GOV；接著追 monetisation 怎麼變成營收，最後才進 incentives、payments、fulfilment／service cost 和 contribution economics。留存也要分清是哪一側，以及 repeat frequency 和 order economics 隨 cohort 成熟後怎麼走。

兩家公司最後其實是在回答同一串管理問題：量的是誰、發生了多少活動、公司從活動裡捕獲多少價值、為此付出了哪些可變成本，還有這套結果能不能在同一批 cohort 上持續。

這五層可以共用，原生 KPI 不需要共用。

混合型商模出現時，先知道什麼時候該停

現實中的公司很少一直待在乾淨的分類裡。SaaS 可以加 usage pricing、payments、ads 或 services；Marketplace 可以再長出 subscription、logistics、financial services 或 first-party commerce。標籤越混合，指標定義反而越不能省。

下一次兩個 KPI 被放在同一張 slide 上，我會檢查五件事：

  1. Unit：兩邊是不是在量同一種經濟單位？
  2. Activity：這個數字是在描述活動量、run-rate，還是認列／捕獲的營收？
  3. Value Capture：分子、分母、期間、幣別、取消與退款規則有沒有對齊？
  4. Variable Economics：成本邊界是否一致，incentive、payments、fulfilment 放在哪裡？
  5. Cohort Durability：兩邊比較的是不是相近成熟度、相同母體，而且產品與價格條件也一致的 cohort？

其中任何一題缺資料，就先停在那裡。

References