轉化率不同，常不是誰算錯，而是分母、事件粒度、時間窗與事件順序不同。同一句「六月付款轉化率」，可能是在算六月建單 cohort 最終付款，或六月內所有建單與付款事件的比值。先把 unit、stage、window、order 與取消／退款規則寫成契約，再比較數字。
一個公式，至少藏了五個決策
最簡單的轉化率是：
conversion rate = 完成目標的人數（或事件數） ÷ 進入起點的人數（或事件數）
問題都在括號裡。以「建單 → 付款」為例，先回答：
- Unit：一位 user、一張 order，還是一次 event？
- Stage：建單與付款分別由哪個欄位／事件定義？
- Window：固定日曆區間，還是每個起點後 N 天？
- Order：付款一定要發生在建單之後嗎？重複事件取第一次還是任一次？
- Eligibility：測試帳號、取消、退款、重建單如何處理？
只要任一項不同，兩個「轉化率」都可能各自正確，卻不能直接對比。
User-based 與 event-based：先確定分母單位
假設同一位使用者六月建立三張訂單，其中一張付款：
- User-based：只要這位使用者至少付款一次，就是 1 位轉化 user；分母也是 unique users。
- Order-based：1 張付款訂單 ÷ 3 張建立訂單 = 33.3%。
- Event-based：若付款重試產生兩筆成功事件，直接拿 events 相除甚至可能得到 2 ÷ 3。
User-based 適合回答「有多少人完成旅程」；order-based 適合回答「有多少訂單成交」；event-based 常用於事件管線健康或操作次數，但必須處理 retry／duplicate。不要在同一公式中用 unique users 當分子、orders 當分母。
最低限度要同時輸出 numerator、denominator 與 rate：
付費使用者 420 / 建單使用者 1,000 = 42.0%
單獨寫「轉化率 42%」無法驗證分母是否縮水。
Cohort window 與 calendar window 回答不同問題
假設使用者 6 月 30 日建單、7 月 1 日付款：
Calendar window（日曆窗）
分母是 6 月內建單，分子也是 6 月內付款。跨月付款不算。它適合描述「六月發生了多少事件」，但月末進站者天生只有很短的轉化時間。
Cohort window（cohort 窗）
先選 6 月內建單的 cohort，再觀察每位／每單在建單後 7 天是否付款。6 月 30 日建單、7 月 1 日付款會計入。它較適合比較不同起點 cohort 的轉化品質，但要等完整觀察窗結束；截至 7 月 3 日，6 月 30 日 cohort 尚未成熟。
兩者沒有誰永遠正確。營運日報可能需要 calendar view，產品流程優化常需要 cohort view。名稱要直接揭露口徑，例如「6 月建單 cohort 的 7 日付款率」，不要都叫「六月轉化率」。
事件順序與 stage 去重，決定漏斗是否成立
事件資料可能亂序、重送或補登。標準有序漏斗通常要求：
first_order_created_at <= first_payment_at
first_payment_at <= first_fulfilled_at
但「first」也需定義：每位使用者第一筆？每張訂單第一筆成功？如果使用者取消後重建，是否視為同一旅程？若 payment webhook 重送，應用 payment_id 或業務 key 去重，而不是把 event count 當人數。
建議為每個 stage 建一張診斷表：
| Stage | Unit key | Event／欄位 | 去重規則 | 時間欄位 |
|---|---|---|---|---|
| 建單 | order_id |
order_created |
每單第一筆 | created_at |
| 付款 | order_id |
payment_succeeded |
每單第一筆成功 | paid_at |
| 完成 | order_id |
fulfilled |
最早完成 | fulfilled_at |
這張表能及早暴露「付款表是一對多」或「status 是當前快照、不是事件歷史」等差異。
取消、退款與跨日轉化怎麼處理？
取消
取消前已付款的訂單，若問題是「付款流程是否成功」，可以算轉化；若問題是「最終成交」，可能排除。不要在沒有決策問題時直接選一個。
退款
付款率通常以付款成功事件為分子；net conversion 或 retained revenue 才可能排除退款。可同時報 gross payment rate 與 post-refund rate，避免一個數字承擔兩種意義。
跨日與時區
事件以 UTC 儲存、報表用 Asia/Taipei 截日，應先轉時區再決定日期。以半開區間 [start, end) 避免漏掉月底最後一秒後的小數時間；但 cohort 的 observation window 應從每個起點事件計算，而非再套同一個日曆月底。
可直接複用的漏斗 Plan 模板
## Decision question
- 我們要用這個漏斗決定什麼？比較哪兩個期間或族群？
## Population and unit
- Population：納入哪些帳號／訂單？排除測試、內部或機器流量嗎？
- Unit key：user_id / order_id / session_id
- Grain：中間表與最終表各一列代表什麼？
## Stages
- S1 名稱、事件／欄位、時間欄位、去重規則
- S2 名稱、事件／欄位、時間欄位、去重規則
- 是否強制順序？允許跳 stage 嗎？
## Time policy
- Cohort 起點：[start, end)
- Observation window：起點後 N 天
- Report timezone：Asia/Taipei
- 未成熟 cohort 如何排除或標示？
## Eligibility and reversal
- 取消、退款、重建、重試、NULL key 的處理
## Outputs
- 每 stage count、step conversion、overall conversion
- numerator / denominator 同時呈現
- 依必要維度分群，不事後任意切割
## Checkpoints
- 每 stage distinct unit 與 row count
- 順序違反、重複事件、NULL key、未成熟 cohort 數
- 找出最大絕對流失與最大相對流失 stage
## Limitations
- 事件缺漏、追蹤變更、無法推論因果之處
最大流失不要只看百分比
對每一段同時報：
absolute drop = stage_n count - stage_n+1 count
step conversion = stage_n+1 count / stage_n count
最大絕對流失指出「少了最多人」；最低 step conversion 指出「比例最弱」。兩者可能不是同一段。還要檢查 stage count 是否不合理地增加；若漏斗要求嚴格順序，增加通常代表去重、JOIN 或 unit 不一致。
Lantide Data 如何讓口徑在 Execute 前被看見
在 Lantide Data 的 Project Analysis 中，Agent 可先探索 schema 與事件分布，再把 unit、stage、denominator、時間窗與 checkpoints 寫進 Plan。PM 或業務 owner 可直接對 Plan 批註，不必先會改 SQL；口徑確認後由使用者按 Approve & Execute，Agent 再建立正式 SQL evidence 與 Report。實務流程見 Plan → Execute → Report。
SQL-first 的好處是分母與事件順序不只存在摘要：grain、JOIN、filter 與 aggregation 可在持久 SQL 分頁審閱，Report 應同時保留 counts、rates 與 limitations。這個工作流能讓爭議提早出現，但不會替團隊決定「退款算不算」或修復缺漏事件；最終口徑仍由對決策負責的人確認。更多做法見 SQL-first 工作流。
結語：先替指標取一個不能誤解的名字
下次有人問轉化率，先不要回單一百分比。用一句完整名稱回答：「6 月建單 order cohort、7 日內首筆成功付款、排除測試單但不排除後續退款的轉化率」。如果團隊無法同意這句話，就代表還沒到 Execute 的時候。