Stripe 每月 SaaS 報告：Cowork 核對 MRR 與流失變化

月報要解釋變化，唔係只貼幾個數字

MRR升咗，可以係新客、加購、升級，亦可以有匯率影響。只睇一個總數，未必知道公司實際發生乜。Cowork可以幫你整理月報，但第一步係取得可對照嘅歷史資料。

先用匿名示例匯出試做。唔需要客戶Email、付款資料或密鑰，就唔好提供；唔叫模型從環境變數讀出或展示Stripe key。

1. 用已確認嘅報表與指標設定

Stripe Billing Analytics提供訂閱指標及下載報表。先記低你帳戶嘅MRR與訂閱者設定，再取同一期間、同一口徑嘅月度摘要及變動資料。折扣等設定不同，報表就可能不同。

MRR係月度化嘅訂閱指標，唔等於當月現金入帳。年繳、試用、折扣、用量計費與不同幣種應跟當前報表定義處理，唔只將所有invoice加埋。

只有今天嘅訂閱快照，唔足以重建過去每個月底。缺歷史匯出或事件資料就先講明限制，唔靠目前狀態猜上月。

2. 用可對數嘅變動表

請用指定Stripe匯出，整理 [月份] 嘅管理報告草稿。先列來源、期間、時區、幣種、帳戶指標設定及缺資料範圍。

列期初MRR、新增、擴張、重新啟用、縮減、流失及匯率等調整，再對期末MRR。分類沿用已確認來源定義。對唔平就列差額與待查項目，唔接受未解釋嘅差額。

訂閱者同訂閱宗數分開。分析流失時按指定定義列分子分母，唔將一位客戶取消其中一份訂閱就一概當整位客戶流失。分母為零寫不適用。

逐項指出主要變動及支持數據，事實同可能原因分開。冇使用紀錄、訪談或明確取消原因，就唔猜產品問題。

輸出Markdown月報、計算表及需我核對嘅問題。唔更改訂閱、唔退款、唔催款、唔發挽留訊息。

3. 對數比美化圖表更重要

逐項對返同期間Stripe報表。取消再啟用嘅客戶要保留實際時間線，唔一律刪掉兩個事件。部分資料未取得、分頁未完成或來源報錯，都要標明，唔輸出完整報告嘅假象。

Cohort要先定義入組事件；Stripe以首次產生正MRR作基礎，唔係Customer物件建立日。比較留存時，未到相同觀察月份嘅組別唔直接並排下結論。

LTV若用簡化估算，要列公式、期間及假設。流失樣本少、分母為零或短期大起大落時，寧願唔提供一個貌似精準嘅數字。

4. 做成固定節奏前，先保留快照

每月保存來源、設定與已核對版本，之後先可以公平比較。排程只負責整理已有資料，唔會補回從未保存、亦無法從來源取得嘅歷史。設定見訂單整理教學。

其他訂閱平台： 可以沿用報告結構，但唔好照搬Stripe狀態與指標名稱，先做欄位與定義對照。

加入產品使用分析： 先確認帳戶ID點配對，以及你有權使用嘅資料範圍。一個付費帳戶可以有多位使用者，唔假設Customer ID等於單一人。

每週觀察： 可以縮短期間睇異常，但每週數據唔等於月度結算。避免因一兩筆變動就自動改價或發起營銷。