
看到「$1M ARR」,先問那是五個數字裡的哪一個
同一張核實頁,我算出三個不同的年收
你在 Threads 或 X 上滑到一則貼文:某個一人開發者說他的產品做到「$1M ARR」,底下一片恭喜。你想知道那是多少錢,但你手上只有那四個字。
今天早上我打開一家我們報導過的公司的營收核實頁——AEO Engine,用 Stripe 金鑰直連核實營收。同一張卡片上,我讀到五個數字:近 24 小時 8,244 美元、近 30 天 76,316 美元、近 12 個月 872,728 美元、累計 2,284,795 美元、現行 MRR 80,601 美元。
MRR(月經常性收入)是把所有還在生效的訂閱,換算成月費之後加總。Stripe 的定義:
active與past_due訂閱的月度標準化金額總和,排除稅金、免費方案,以及所有按量計費的產品。ARR 通常就是 MRR 乘以 12——它是一個推算出來的年化速率,不是過去 12 個月實際入帳的錢。
ARR 是速率,不是歷史。這就是所有口徑打架的源頭。
我用同一張頁面,算出三個不同的年收
| 算法 | 得到的「年收」 | 這個數字是什麼 |
|---|---|---|
| MRR × 12 | 967,212 美元 | 訂閱速率年化,最標準的 ARR |
| 近 30 天 × 12 | 915,792 美元 | 把上個月當常態,含一次性收入 |
| 實際近 12 個月 | 872,728 美元 | 過去一年真的進來的錢 |
前兩格是我自己乘出來的;第三格是頁面直接給的。最標準的那個 ARR 比實際收到的錢高出約 11%。三個都不算造假,差別在你不知道發文的人用的是哪一個。
而拿最近某一天的營收乘以 365,同一張頁面會給出 300 萬美元——這不是這家公司的說法。我們寫過一位開發者自己公開說明他的百萬美元年收就是這樣算出來的。
六個口徑,六種不同的錢
第一,MRR 是一個設定,不是一個事實。 Stripe 讓商家自己決定要不要把折扣從 MRR 裡扣掉。
第二,按量計費永遠不在 MRR 裡。 我們寫過的一家 token 轉售閘道:近 30 天流水 158,166 美元、MRR 55,984 美元,創辦人自己註明 MRR 只計兩個訂閱產品。
第三,流水不是收入。 那 158,166 美元裡有一大塊是要付給模型供應商的成本,平台自己抽的是 5%。gross volume 是經過你的錢,revenue 是留下來的錢。
第四,累計金額的起算點可能是另一家公司。 AEO Engine 的 all-time 起算自 2018 年,但這個品牌 2026 年 1 月才定名,源頭是同一位創辦人開的 Amazon 代理商。
第五,合約總額不是實收。 「先收到 8,400 美元」拆開可能是 7 個人各買 3 個月、每月 399 美元。
第六,同一張卡上的欄位,硬度不一樣。 TrustMRR 的頁面寫得很清楚:營收相關欄位是用金流商 API 金鑰直接讀出來的,創辦人提供的描述則是使用者產生的內容。一半是機器讀的,一半是人打的。
核實頁也有保存期限
金鑰直連不會造假,但會過期。 一張核實頁上放著三種時間的數字:最後同步時間、站方存下就不動的快照(MRR、訂閱數),和跟著今天往前滾的逐日表。三者不同步,頁面就自己跟自己打架。
我 9 月 18 日重讀三張頁面,剛好三種狀況:
| 頁面 | 同步狀態 | 同一頁上 |
|---|---|---|
| 某電商選品工具 | 金鑰 8 月 16 日過期,同步停在前一天 | 近 30 天寫 49,511 美元,逐日表 30 格全是 0 |
| 某 AI 影音工具 | 當天同步成功 | 近 6 個月全是 0,快照仍寫 MRR 28,537 美元 |
| VectoSolve | 當天同步成功 | 近 30 天 3,199 美元,逐日表我加起來 3,176 美元 |
第二張要分兩層看。核實層收到 0,不等於生意死了,收款可能換了金流。但它近 12 個月的 122,814 美元,我加了一下,剛好是 2025 年 9 到 12 月四格的和。
機器讀到的那一句,更容易過期。 兩張有問題的頁面,寫給搜尋引擎的描述仍是舊數字,第一張還寫著月成長 29%。所以我先找同步時間,再把逐日表加一加,對不上就不引用。
你可以帶走的三個問題
第一,這是速率還是歷史? MRR 和 ARR 回答「照現在這樣跑一年會是多少」。近 30 天、近 12 個月、all-time 回答「已經進來多少」。
第二,這是經過的錢還是留下的錢? 問一句「你的 take rate 是多少」,比問營收有用。
第三,這個數字是誰算的? 是金流商 API 讀出來的、還是本人打上去的?起算點是不是同一家公司?
沒有任何一個口徑是「正確」的那一個。 投資人看 ARR、稅務看實收、經營者看現金。真正的判準不是「他有沒有灌水」,而是「他有沒有告訴你他用的是哪一格」。
查核備註:MRR 定義取自 Stripe 官方 Billing 分析文件,該頁未定義 ARR。AEO Engine 讀數是我 2026 年 8 月 27 日讀 TrustMRR 公開端點所得;「MRR × 12」「近 30 天 × 12」與 8,244 乘 365 都是我自己按的,不是這家公司的宣稱。9 月 18 日三張核實頁讀的是 TrustMRR 公開 .md 端點與頁面描述,兩個不具名標本的收款是否移往他處,我沒有查到。本文不構成投資建議。
FAQ
常見問題
- MRR 跟 ARR 差在哪?
- MRR 是所有生效訂閱換算成月費後的總和,ARR 通常是 MRR 乘 12。兩者都是速率,回答的是「照現在這樣跑一年會是多少」,不是「過去一年實際收到多少」。把速率當成歷史,是這個題目最常見的誤讀。
- 為什麼有些公司的 MRR 會低於它近 30 天的收入?
- Stripe 的 MRR 定義排除按量計費產品,也排除一次性發票。所以年約、客製合約與用量型收入雖然真的進帳,卻不會進 MRR。反過來,年繳攤提也可能讓 MRR 高於某一個月的實收。兩個方向都會發生。
- 「Stripe 核實」的營收數字可以完全相信嗎?
- 可以相信它的來源,但要看清楚範圍與時點。核實服務通常只有營收相關欄位是金流商 API 讀出的,其餘欄位是本人自填;金流商不同讀到的口徑也不同;而 API 金鑰斷線後頁面數字會凍結,看起來仍像現況。先找最後更新那一行。
SOURCES
- ASubscription analytics — Billing metric definitions(Stripe 官方文件)
- AAEO Engine — TrustMRR 公開純文字端點(2026-08-27 讀取,頁面標最後同步 2026-08-27T02:04:57Z)
- AGoTall — TrustMRR 公開純文字端點(2026-08-27 讀取,頁面標最後同步 2026-08-26T23:51:38Z)
- ATrustMRR llms.txt(驗證方式與公開端點說明;2026-09-18 讀)
- AVectoSolve — TrustMRR 公開 Markdown 頁(2026-09-18 讀)
來源分級:A = 一手公告/論文/官方文件 · B = 可信媒體 · C = 可參考但需脈絡 · D = 觀察用,不可當事實。
UPDATE HISTORY
- First published.
- 依 EDITORIAL-SIGNALS §4 長度上限瘦身(2026-09-17 健檢裁示):2070 → 971 漢字,只刪不加——砍暖身段、第二種說法與旁枝;事實、數字、立場與查核備註未新增。砍前全文見 docs/content/signals-submissions/_trim-2026-09-17.md 所指的 git 歷史。
- 新增〈核實頁也有保存期限〉一節(Vincent 2026-09-17 裁示:「核實過的營收也會過期」併回本篇做更新段):同步時間、快照、逐日表三種時間不同步時的讀法,附 9 月 18 日重讀的三張核實頁(兩張不具名)。原「核實會過期」一句併入新節;查核備註補一句讀取範圍。
本文由 AI 協助研究,矽基前沿編輯部撰稿,總編輯廖玄同審閱定稿。 編輯方針與 AI 使用說明


