訂閱（Subscription）狀態、事件與資料優先權
toobo
上次更新 5 個月前
【這篇解決什麼問題】
你想掌握訂閱的狀態與事件邏輯，避免資料覆蓋衝突，確保指標計算正確。
【訂閱的核心規則】
【訂閱事件類型】
【source 優先權（避免覆蓋錯誤）】
優先順序：manual > api > inferred
【重新啟用的重要細節】
【常見問題】
Q1：為什麼暫停後 MRR 下降？
因為 paused 訂閱不計入 MRR，屬於預期行為。
Q2：系統推導（inferred）資料可以強制蓋過 API 嗎？
不行，這是保護外部系統資料的一致性設計。
【下一步】
你想掌握訂閱的狀態與事件邏輯，避免資料覆蓋衝突，確保指標計算正確。
【訂閱的核心規則】
- 每位客戶在每個商家下只能有一筆訂閱（唯一約束）
- 訂閱狀態：active、cancelled、paused
- paused 不計入 Active Customers 與 MRR
【訂閱事件類型】
- created：首次訂閱
- upgrade：升級
- downgrade：降級
- cancel：取消
- reactivated：重新啟用
【source 優先權（避免覆蓋錯誤）】
優先順序：manual > api > inferred
- 高優先來源可覆蓋低優先來源
- inferred 不可覆蓋 api
【重新啟用的重要細節】
- started_at 保持不變（保留首次訂閱時間）
- current_period_start 會更新為新的週期起點
【常見問題】
Q1：為什麼暫停後 MRR 下降？
因為 paused 訂閱不計入 MRR，屬於預期行為。
Q2：系統推導（inferred）資料可以強制蓋過 API 嗎？
不行，這是保護外部系統資料的一致性設計。
【下一步】
- 指標判讀請看 SaaS 指標文件
- 若要追蹤事件串接，請看 Webhook 設定指南