有了共同語言，名單與報表才跑得穩。我的原則：先定義，再運算；先固定，再優化。時間一律以 T-1 24:00（+08:00）結算，隔天 09:00 產出。

我今天定的指標字典
• GMV_gross（毛 GMV）：區間內 payment_succeeded 的 amount 加總（未扣券）。
• GMV_net（淨 GMV）：毛 GMV − 區間內「折抵金額」（若資料沒有折抵欄，先用毛 GMV）。
• orders_paid（成功訂單數）：有 payment_succeeded 的唯一 order_id 數。
• customers_paid（成交客數）：區間內有 payment_succeeded 的唯一 member_id 數。
• AOV（客單價）：GMV_net ÷ orders_paid。
• pay_success_rate（付款成功率）：payment_succeeded 筆數 ÷ (payment_succeeded + payment_failed)。
• refund_amount（退款金額）：區間內 order_refunded 的金額加總（口徑與金額含稅/未稅需與 GMV 一致）。
• refund_rate（退款率）：order_refunded 筆數 ÷ orders_paid。
• coupon_issued（發券數）：區間內 coupon_issued 筆數。
• coupon_redeemed（用券數）：區間內 coupon_redeemed 筆數。
• coupon_use_rate_7d（7 日券使用率）：以「發券日屬於 T-7～T-1」的那批券為母體，看其中有在 T-1 前出現 coupon_redeemed 的比例。
• new_customers（新客數）：區間內第一次出現 payment_succeeded 的 member_id 數。
• d7_retention_rate（7 日留存）：以「在某日首購」的人為母體，觀察 +1～+7 天是否出現任意活躍事件（app_session_started、order_created、payment_succeeded 任一即算）之比例。
• d30_retention_rate（30 日留存）：同上，觀察 +1～+30 天。

金額口徑：我沿用前兩天的決定——全案統一採 含稅或未稅其一。今天先用你們慣用的口徑；之後要切換，再整批改版並把 spec_version +1。

我把日更看板需要的欄位列出來（每天一行）
• stat_date（統計日，例：2025-09-16）
• GMV_gross
• GMV_net
• orders_paid
• customers_paid
• AOV
• pay_success_rate
• refund_amount
• refund_rate
• coupon_issued
• coupon_redeemed
• coupon_use_rate_7d
• new_customers
• d7_retention_rate
• d30_retention_rate
• generated_at（產生時間，ISO 8601）
• spec_version（口徑版本，如 v1）

CSV 表頭
stat_date,GMV_gross,GMV_net,orders_paid,customers_paid,AOV,pay_success_rate,refund_amount,refund_rate,coupon_issued,coupon_redeemed,coupon_use_rate_7d,new_customers,d7_retention_rate,d30_retention_rate,generated_at,spec_version

我手動造一行假數據
2025-09-16,325000,310000,420,380,738,0.981,12000,0.028,1500,420,0.31,95,0.42,0.27,2025-09-17T09:00:00+08:00,v1

我今天做的三個決定
• 留存的「活躍」判定要寬一點：只要回來開 App（app_session_started）或有交易行為就算活躍，先衡量關係，不急著談因果。
• 券使用率先用「7 日視窗」：對行銷最有感；後續再擴充 14/30 日版本。
• 每個指標都要能回溯：每日輸出必帶 generated_at 與 spec_version，避免不同程式版本算出不同答案卻對不上。

小結：指標字典一旦定了，大家說話就能一致；明天開始我會把「資料品質稽核」寫出來，先確保每天數字能信，再談優化。

明日預告（Day 5）：我會列出資料品質稽核清單 v1（缺值、重複、時間序、金額平衡、分佈異常）與「每日檢查 10 分鐘」的小抄。