和泰標籤撈取程式碼 Review — 2026-05-21 (v3)

一、先回答 Andy 早上問的兩個關鍵問題

Q1：「出沒地帶 226 萬人只有 162 萬人有標籤」是合併算錯還是真的沒消費？

結論：合併 bug，CK 上午已修。Excel 已驗證修復有效。

修復後 P36M 數字：

• 消費時間 / 顧客消費力 = 2,268,573（即總會員 UU）
• 出沒地帶 = 2,259,448（99.6%）
• 工作時段消費區域 = 2,192,849（96.7%）
• 非工作時段消費區域 = 2,229,264（98.3%）

已不再是 162 萬。修法在 3_資料整合.py:42-46（stream_filter chunk 邊界 bug）。

Q2：自炊者比例過高

不是 bug，是定義門檻太鬆。整套標籤體系都有「一年買過一次就上低標」的共通設計問題，詳見 §三 D2。

二、Bug 清單

🔴 P0-1：百貨公司消費時間 — 白天/晚上 label 反了

位置：2_標籤專案資料撈取加速版.py:181-186 註解定義：白天 06:00–18:00 / 晚上 18:00–06:00

when dayofweek in (0, 6) and (hour>=18 or hour<6) ... then '假日白天'   -- 18-06 標白天 ❌
when dayofweek in (0, 6) and hour>=6 and hour<18  then '假日晚上'         -- 06-18 標晚上 ❌
when dayofweek not in (0, 6) and (hour>=18 or hour<6) ... then '平日白天' -- 同上 ❌
when dayofweek not in (0, 6) and hour>=6 and hour<18  then '平日晚上'     -- 同上 ❌

Excel 佐證：百貨「假日白天」16% 違反直覺——假日午後是百貨黃金時段不可能最少。 客戶回饋佐證：和泰驗證的同事亦表示「與百貨消費時段認知不符合」。 修法：把四個分支「白天」「晚上」字串對調。

🔴 P0-2：DB 帳密明碼寫死在原始檔

位置：2_*.py:20-25 + 2_*.py:62-68 + 3_*.py:14-19

明碼包含使用者帳號與密碼（Redshift production）。zip 已外傳 Andy/Xians，請 CK 知會 IT 立刻換密碼，並把交付版改成 os.getenv() 或 placeholder。

🔴 P0-3：低頻品類 fall-through bug

位置：3_資料整合.py:58-72

Excel 鐵證：西裝 P36M = 5,324 < 2024 P12M = 7,703（ratio 0.69x）。三年合併後比任一年都少——邏輯上不可能，除非合併把資料丟掉。

機制：目前是 per-member fall-through。2024 買過西裝的會員 A，只要在 2026 有任何發票（即使一杯咖啡），他的所有標籤就只從 2026 取。2026 沒買西裝 → 標籤消失。

受害範圍（P36M / max(P12M) < 1.15 的低頻 tag）：

對照：高頻黏著類標籤（消費時間/出沒地帶/工作時段/折扣敏感）P36/max 都在 1.27-1.28 — 這才是合理區間。

修法：per-member fall-through → per-(member, tag_type) fall-through。對每個 tag_type 獨立做年度回補。

🔴 P0-4：搭乘計程車 vax_no 過窄，2024/2025 完全壞掉

位置：2_*.py:2814-2833 — and vax_no = '83118125'

2024/2025 只撈到個位數——不是低消費，是這個 vax_no 在那兩年沒在 dw.r_invoice 出現。現行 P36M 搭乘計程車實際上等於 2026 single year，不是三年合併。

請 CK 確認：Uber 是否在某時點才換成此統編？或還有其他統編需要加入？

🔴 P0-5：搭乘計程車 tags 改為分級規格（客戶新規）

位置：2_*.py:2814-2833

現行：tags 是「1, 2, 3, ..., 100+」的計次字串，下游難用，且大量 (Tag_type, Tags) 組合人數 < 200（見 P0-6）。

客戶指定新規格：

年度發票 < 4 張    → 低
年度發票 4–10 張   → 中
年度發票 10–25 張  → 高
年度發票 >= 25 張  → 特高

修改 SQL：

select
    member_id,
    '搭乘計程車' as tag_type,
    case
        when inv_count >= 25 then '特高'
        when inv_count >= 10 and inv_count < 25 then '高'
        when inv_count >= 4 and inv_count < 10 then '中'
        when inv_count < 4 then '低'
    end as tags
from (
    select member_id, count(distinct inv_id) as inv_count
    from dw.r_invoice r
    where r.inv_date >= '{start_time}' and r.inv_date < '{end_time}'
      and r.create_time < '{create_time}'
      and vax_no = '83118125'   -- 連同 P0-4 一起補擴大名單
    group by member_id
);

🔴 P0-6：新交付規則 — Tags 人數 < 200 不應交付

規則：單一 (Tag_type, Tags) 組合人數 < 200 的不交付給和泰。

P36M 影響範圍：281 個組合需排除，分佈：

實作建議：在 4_資料彙整.py / 4_資料彙整_年度.py 加入：

report = report[report['Tags人數'] >= 200]

注意：BMW 195 距 200 僅 5 人差距，若重跑後仍 < 200，需告知客戶；目前 BMW 不交付。

🟡 P1-1：SQL 邏輯運算子優先序錯（潛在 bug）

位置：2_*.py:182, 185

when dayofweek in (0, 6) and (hour>=18 or hour<6) or hour is null then '假日白天'

SQL AND 優先於 OR，實際解析為：

(dayofweek in (0,6) AND (hour>=18 OR hour<6)) OR (hour IS NULL)

→ 只要 hour IS NULL 就一律落入「假日白天」分支（即使是平日）。

影響取決於 invhdr.inv_time 是否可為 null。請 CK 跟 DBA 確認。

🟡 P1-2：註解 vs 程式碼閾值不一致（至少三處）

車輛充電的 250 元門檻是極度偏低（一張充電發票就過），請 CK 確認 250 是不是寫錯。

請 CK 全面校對所有 tag 的註解 vs code，並更新交付給和泰的標籤說明書。

🟡 P1-3：折扣敏感度 LIKE '%優惠%' 關鍵字過寬

位置：2_*.py:1198

product_name like '%買一送一%' or product_name like '%優惠%' or product_name like '%折扣%'

「優惠」會中「優惠價」「會員優惠」等非真正打折商品 → 86.4% of total 被標折扣敏感，幾乎沒有區辨力。客戶驗證亦質疑此標數量過多。

建議：改用更精準詞（「買X送X」「N折」「特價」），或加 amount 比對基準價。

🟡 P1-4：環保綠能族 LIKE '%環保%' 同樣過寬

位置：2_*.py:1217 「環保袋」「環保餐具」「環保標章」都中 → 48.5% of total。建議改用 category_id 或更嚴格詞表。

🟡 P1-5：連鎖餐廳沒有 HAVING，導致外食族 < 連鎖餐廳 反直覺

位置：2_*.py:726-746

客戶疑問：外食族 88,463 < 連鎖餐廳 487,839，「外食族照理應該 > 連鎖餐廳」。

SQL 對比：

• 外食族 (2_*.py:895): having inv_count >= 48（年 ≥48 張才出現）
• 連鎖餐廳 (2_*.py:746): 沒有 having，「低」門檻是「年 ≥1 張」

兩者門檻不對等 → 連鎖餐廳數字遠遠膨脹。

建議：連鎖餐廳加 having inv_count >= 27（與「<27 低」的最低 bucket 對齊），讓兩個 tag 的「低」閥值一致。預估改後連鎖餐廳人數會從 89.3% 大幅下降，外食族 > 連鎖餐廳 自然成立。

🟢 P2-1：phone 共用一支電話的 Tag 衝突

位置：3_資料整合.py:91-97 若 cell_no 在 public.member 對應到多個 member_id，可能出現「同 phone 同 Tag_type 有兩個不同 Tags 值」。目前 dedup key (Phone, Tag_type, Tags) 不會丟資料，但下游若假設「一支 phone × 一個 Tag_type → 一個 Tags 值」會踩坑。

🟢 P2-2：商圈消費頻次 tags 是 integer 而非 string

位置：2_*.py:1156 其他 tag 的 tags 都是 string，這個是 integer 1-50。pandas concat 會 upcast 為 object，現況不會炸，但下游若用 .str.contains 處理會踩坑。

三、設計層級議題

D2：整套標籤「低 = 有買過一次就算」

整體設計選擇，造成多個 tag 覆蓋率異常高，「低」這個 bucket 訊號強度接近 0：

請 Andy/Xians 評估：

• 拉高所有「<N 算低」的標籤門檻（例如 ≥6 或 ≥12），或
• 在交付規格裡把「低」明定義為「曾有過此行為」而非「具備此特徵」

四、客戶 76 萬批次回饋逐項回應

客戶手上的測試批次母體為 76 萬人。注意：以下回應假設客戶手上的是修復前版本；若是修復後，數據結構應接近我們的 P36M 226 萬版本。請 CK 先確認客戶用的是哪個版本，必要時重新交付。

五、給 Xians / Andy 的下一步建議

今天必做：

• 立刻換 Redshift 密碼（P0-2）
• 跟 CK 確認客戶手上的 76 萬批次是修復前或修復後版本（決定要不要重新交付）
• 修 P0-1 百貨公司白天/晚上反向 bug，重跑該標籤
• 修 P0-5 搭乘計程車改分級

本週內：

• 決定 P0-3：要不要重構為 per-tag fallback？跟和泰確認需求
• 修 P0-4 搭乘計程車 vax_no（補名單或加 disclaimer）
• 在 4_資料彙整*.py 加入 P0-6 過濾規則（Tags 人數 ≥200）
• 修 P1-1（hour IS NULL 優先序）— DBA 確認 nullability 後
• 統一 P1-2（所有 tag 的註解 vs code 全面校對，特別是車輛充電 250 vs 6000）
• 修 P1-3 + P1-4（折扣 / 環保 LIKE 關鍵字精準化）
• 修 P1-5（連鎖餐廳加 HAVING ≥27）

待和泰回覆：

• D2「低」標的訊號強度是否堪用？要拉高門檻嗎？
• P0-3 per-tag fallback 是否要做？
• P0-4 搭乘計程車是否需告知範圍限制？
• 新生兒家庭 category_id 範圍是否擴大？

Review 方法：靜態 code review + Excel 數字交叉驗證 + 客戶回饋逐項對照 + 與團隊聊天記錄交叉驗證。所有結論已二次自檢，未經驗證的推論已標明「請 CK/DBA 確認」字樣。