每日廣告品質看板 v25b

判讀：① 本期 5 個下層 campaign 的 ROAS 可能含認領成分（🔴 0、🟠 5；另 ⚪ 1 個因訊號無資料未完整檢查，共 7 列）。
② 不是下層變強，是分母被抽掉而分子沒跟著走：ROAS 變好時先看訊號二——本期 臺灣史、其他 的下層日均花費比基線月少 25% 以上，這幾條線的 ROAS 要先扣掉減量效應再看。
③ 驗證方法＝小規模加碼—觀察—回退：把單一課程線的下層日預算拉回基線月水準跑 5 天，看宣稱營收是否等比例上升；沒有等比例上升就是認領。
⚠️ 這一區是純提醒，不改變任何判定（2026-08-09 Jeff 裁決）。⑯ 判紅的組合仍可能因為虛高 ROAS 被 ⑫／⑮ 自動判成「可加碼」，看的人要自己攔；請注意 ⑦⑨⑨-b⑫⑮ 這些模組的下層 ROAS 可能含認領成分。

各線本期 vs 基線月（2026-09-01～09-30）
未來必修課：本期下層 5 個組合、日均 17,396；基線 22 個組合、日均 12,953，+34%。基線「購買÷LPV」按評價群：scroll75 0.00%（1 組）；購買 1.36%（18 組）；開始結帳 0.00%（3 組）
臺灣史：本期下層 12 個組合、日均 5,181；基線 24 個組合、日均 14,531，-64%。基線「購買÷LPV」按評價群：購買 1.41%（18 組）；開始結帳 0.23%（3 組）；其他測試事件 0.00%（3 組）
其他：本期下層 1 個組合、日均 2,804；基線 29 個組合、日均 7,444，-62%。基線「購買÷LPV」按評價群：購買 1.31%（26 組）；開始結帳 0.69%（1 組）；其他測試事件 0.00%（2 組）
歷史課：本期下層 5 個組合、日均 2,673；基線 9 個組合、日均 3,557，-25%。基線「購買÷LPV」按評價群：購買 0.75%（9 組）
語文課：本期下層 0 個組合、日均 —；基線 12 個組合、日均 4,029。基線「購買÷LPV」按評價群：購買 0.99%（12 組）

門檻的來由（modules.md ⑯）：訊號一的基線——2026/7 各線「購買 ÷ LPV」落在 3.2–4.4%（舊定義、只含優化購買的下層），是站上點擊行為的合理區間；2026/8/1–8/6 語文課 22.6%、臺灣史 125%，這種數字不可能由點擊產生，所以 ≥3× 紅、1.8–3× 橘。訊號二——花費是 ROAS 的分母，減量期的 ROAS 一定被「歸因底線」撐高，這一格的作用是讓人先看到減量、再看 ROAS（≤−50% 紅、−50～−25% 橘）。訊號三的基線是 10.7%（decisions.md：GA4 只認得真實成交的約 10.7%，2026/7/25–7/31 實測 11.3% 與它吻合），<1% 紅、1–5% 橘。
判色：任兩紅 → 🔴 ROAS 可能不可信；一紅 → 🟠 存疑；零紅 → 🟢 可正常判讀。「無資料」永遠不計紅；零紅但有訊號無資料時標 ⚪ 未完整檢查，不冒充 🟢（Jeff 2026-09-27 裁定）。「花費 0 元」不單獨定罪，它是與訊號一、二互相佐證用的。
限制：訊號三是層級共用值不是逐組合；分子是 ga4_agg.json 下層的 purchaseRevenue（fetch_ga4_tiers.py 2026-09-27 起補抓），本份資料有這欄，訊號三已判色。hero 裡的 GA4 購買人數是 totalUsers 口徑，不拿來冒充營收認列比。GA4 同期有大量 (not set) 工作階段（YouTube／App 內開啟掉 utm）。訂單分類沿用 orders_cls.py 三分類器，已知限制相同（Teachify 不回傳結帳網址，團購靠方案名稱與折扣碼字串比對）。Meta insights 不回傳整期零曝光的組合，「花費 0 元仍有購買」只在 API 有回列時才抓得到。
口徑：本期＝adset MTD 檔（m_mtd.json，2026-10-01～10-06，與 ⑮⑫ 同源）依 meta0805.tier_of_rec 判為下層的組合，按 campaign × 評價群（group_of：優化購買／開始結帳／scroll_90／分頁點擊／scroll75／其他測試事件）彙總成列；上層／中層／未定層不列、不判、不計紅燈；KOL 型＝campaign 或 adset 名含「KOL」（只標示，門檻不變）；「名稱寫上層／中層」＝名稱層 ≠ 事件層的對帳標記，不改歸層。產品線用 meta0805.norm_line（KOL／DPA／地理課歸「其他」，基線同法）。基線＝上一完整月 2026-09-01～09-30（data/2026-10-01/ 的 adset MTD 檔，同一套 meta0805.load 判層）；本期日均÷6 天、基線日均÷30 天。訊號一的基線比值按「該線 × 同評價群」算（層級定義 v2 的下層含 CONTENT_VIEW／開始結帳等 LPV 大、購買近 0 的組合，混在一起會把優化購買的列灌成假紅——分子分母要同口徑）；訊號二是線級共用值（該線本期下層日均 ÷ 該線基線月下層日均），campaign 每月換名無法逐一對應，列上另印本組自己的日均。這兩個取法 Jeff 2026-09-27 裁定採納（modules.md ⑯）。「今天」分頁的紅點＝本區判 🔴 的列數（0）。

⚠️ 目標仍是 2608 版：本月（2610）的目標與預算尚未提供，這一區的目標值、達成率與「追平所需日均」都是拿 2608 的數字算的，資料不足，不要拿來下結論。補上 targets/2610.json 即自動切換。

口徑：花費與成果為 Meta 自報（購買含模型推估），絕對值不可對外引用，真實成交看 ⑦。產品線由行銷活動命名歸類，子課程（中國史／東亞史／世界史）收斂到歷史課，（高效讀寫／文學課／應用文）收斂到語文課。
月目標與廣告預算取自 targets/2608.json（每月從 mkt_廣告預算 檢核計算區人工轉錄一次），沒有目標的線列出但不判定。

⚠️ 目標仍是 2608 版：本月（2610）的目標與預算尚未提供，這一區的目標值、達成率與「追平所需日均」都是拿 2608 的數字算的，資料不足，不要拿來下結論。補上 targets/2610.json 即自動切換。

整體：MTD 自營 605,198 元／MTD 目標值 1,645,161 元＝ 36.8%（月目標 8,500,000 元，全月達成率 7.12%）。含團購客服 745,304 元也才 45.3%。
⚠️ 這個 36.8% 的分子分母線別不一致：分子是全站自營營收，分母只有五條有月目標的線。只算那五條的話 MTD 自營是 671,110 元＝ 40.8%（跨線組合包同時計給兩條線，這個數字會略為高估）。真實值落在 40.8%～36.8% 之間，兩端都給，不挑好看的那個。
預算：MTD 花費 191,068 元／MTD 預算目標 907,492 元＝ 21.1%。† 追平所需日均 ＝（月預算 − MTD 花費）÷ 剩餘 25 天 ＝ 全帳戶 179,906 元／天。最近一天（10-06）實際花了 33,485 元，只有需求的 19%——要追平必須把日花費拉高 5.4 倍。

怎麼讀這張表：達成率如果每天都在同一個水位，代表落後是穩定的、可以用「乘以幾倍」推估；如果它一路往下掉，代表缺口在擴大，光是維持現況不夠。
分子同上是全站自營營收、分母只有五條有目標的線，所以這一欄同樣是上限值；逐日之間的相對變化不受影響。
口徑：日期是台北時間（Teachify 的 created_at 是 UTC，已 +8 轉換；沒轉的話台北 08:00 前的訂單會被算到前一天）。當日花費是 Meta campaign 層級加總，已與帳戶層級逐日對帳。
月目標與月廣告預算取自 targets/2608.json（每月從 mkt_廣告預算 檢核計算區人工轉錄一次）；MTD 花費是 Meta API 即時值。跨線組合包同時計給兩條線，逐線加總會超過總額。

判讀：自營營收從 8/01 的 227,200 元走到 8/08 的 50,629 元。✅ GA4 已更新至 10-06，與 Meta 側同期。取數走 service account + GA4 Data API（scripts/fetch_ga4_tiers.py），不再依賴桌面橋接或 Supermetrics。 ⚠️ 10-05、10-06 仍在回填，這幾天的數字之後還會變，不要拿來下結論或做逐日精確比較。 參考值：期初工作階段 5,312、期末 5,102。
MER 很高但不要開香檳：分母只有 Meta 的 191,068 元，Google 花費完全沒算進去（hist.db 的 daily_google 只到 8/02，本次未能補——真實 MER 會比這裡低。而且 MER 高的原因主要是廣告根本沒花錢（月預算執行率 4.08%），不是效率變好。
團購佔比 18.8%，比 2026/7 的 30.1% 又高一截。跨月比較前一定要先對齊口徑。
口徑限制：團購／共學是用方案名稱與折扣碼字串比對當代理指標，Teachify 的 list_orders 不回傳結帳網址，所以「網址後綴含 studygroup」無法在訂單端直接執行。待方案名稱改成固定前綴（已建議 SG_）後可改成精確比對。
未成交付款嘗試已排除（2026-08-23 起）：Teachify payments 端點按建立時間抓，含 failed／not_paid 的未完成刷卡與 ATM 取號（本期 26 筆、144,810 元，上表 ⓪）。失敗的刷卡嘗試以前會被分到自營灌水 MER。看板每天整月重抓，整月一體適用此口徑；2026-08-23 前產出的舊看板未排除這批，自營營收會略高於本表，屬口徑差異不是業績變動。

⚠️ 本期無法出帶：8 月起的日訂單序列改用台北時間 created_at 為基準，而 7/31 以前 hist.db 裡的序列是另一套基準（實測 8/01 差 1 筆／2,550 元、8/02 差 8,010 元，疑為 UTC 起訖）。前 7 天有 5 天落在舊基準上，混著算會得出一條假的帶，所以這一期不出帶、只列原始序列。等 8/08 之後前 7 天全部落在新基準上，帶會自動恢復。
這正是「口徑錯了比沒有數字更糟」——寧可空著，不要給一條看起來很專業的錯誤基準線。

樣本量：5 天合計 121 筆。日筆數在 4～25 之間，低於 10 筆的那兩天（8/01、8/02）不足以支撐任何逐日比較，它們落在月初減碼觀察期內，中下層全數停投，本來就不是常態。

⚠️ 目標仍是 2608 版：本月（2610）的目標與預算尚未提供，這一區的目標值、達成率與「追平所需日均」都是拿 2608 的數字算的，資料不足，不要拿來下結論。補上 targets/2610.json 即自動切換。

⚠️ 資料不足，未判定：目標檔 targets/2608.json 沒有這些線×層的 tier_budget，算不出「到今天該花」，只能列出本月零花費的：歷史課 中層、語文課 下層。要判定請在目標檔補上該線×層的月預算。

「到今天該花」＝ 該線該層月預算 × 已過天數 ÷ 當月天數。本區的花費是 MTD 2026-10-01～10-06 的 Meta 即時值。
⚠️ 目前只投影「零花費」這一種紅格。⑮ 上另外兩種紅（花費執行率 < 線性一半、單位成本 > 2× 目標）還沒有對應的派工規則，所以這一區不等於「⑮ 所有紅格」——別把它當成完整待辦清單。
⚠️ 2026-09-26 起層級依優化事件分（層級定義 v2）：上層暫不配預算、不列；目標檔的 tier_budget 若仍是舊定義（上層＝導流、中層＝開始結帳／scroll_90），要依新定義重切（舊上層→中層、舊中層＋下層→下層）才對得上本區的花費。
看板只讀不寫：本系統不呼叫任何修改廣告的 API（不開關、不改預算、不改受眾），也不回寫 Google Sheet。這裡列的是待辦，執行與記錄在 ⑥-c。

🔴 2 項未通過、1 項警示。「不通過就不判定」——下面 ②／④／⑦ 的比率在這些項目修好之前都要打折看，尤其是被點名的那一層。
2026-08-13 起改為即時重算。在那之前這一區是 v21 的凍結 HTML，停在 08-02～08-04 —— 而它是整個流量頁的前置條件：「在確認流量是真的之前，下面所有比率都可能被污染」。前置條件十天沒有被檢查，下游卻每天拿它的結論當前提。
判定方式：0-2 看「LPV → GA4 工作階段」逐日轉換率是否偏離前 7 日中位 ≥ 50%（那是 Meta 側與 GA4 側的接縫，量測壞掉會先在這裡不連續，而且對花費規模不敏感）；0-3 數「入口頁開始結帳日均 ≥ 5 且入口階段日均 ≥ 100」的頁數（卡住的從來不是流量而是轉換事件的日樣本，只看流量會有 12／14 頁達標、等於沒在檢查）；0-4 檢查天數夠不夠建滾動 7 日基準；0-5 ＝（已標記 −t／−m／−p 的工作階段）÷（全部 facebook/cpc 工作階段）。門檻沒有校準過（照凍結版的判定方向訂：77.7% 當時判紅），要調請改 render_gate.THRESHOLDS，不要在下游補救。
滑鼠移到每一格可以看細節。

分層來自 GA4 的 sessionSourceMedium：2026-09-26 起依層級定義 v2：facebook / cpc-t＝中層（導流；舊定義稱上層）、cpc-m＋cpc-p＝下層（utm_medium 不改名）；上層（曝光／觸及／影片）沒有 utm 分層，GA4 側不比對。Meta 側各層依優化事件歸層。另有 facebook / cpc（未標記）16 個工作階段，分層標記覆蓋率 99.9%——未標記的那些會讓各層的 GA4 階段數被低估、到站落差被高估。
‡ 到站落差 ＝（LPV − GA4 工作階段）÷ LPV。不用「全部點擊」當分母，因為那個欄位包含按讚、留言、分享、點粉專名稱等根本不會導向網站的點擊，拿它當分母會把落差灌水。
下層顯示「回訪 N×」而非落差：LPV 只計算「從廣告點進來的那一次到站」，而下層是再行銷、同一個人本來就會多次回訪產生多個工作階段，所以 GA4 階段數超過 LPV 是正常的。這個數字越高代表再行銷受眾回訪意願越強，是正面訊號。
† 每有效人的口徑限制：分子是 Meta 的花費、分母是 GA4 的人數，中間隔著上面那個到站落差。它不是「Meta 幫你買到一個有效訪客的價格」，而是「你付的錢 ÷ 站上真的往下看的人」——沒到站的那筆錢也算在成本裡，這是刻意的。
⚠️ 本期樣本極小：中層 GA4 只有 384 個工作階段、下層 14,849 個，有效率與有效人→結帳都是幾十個人算出來的，只讀方向不要讀絕對值。

✅ GA4 已更新至 10-06，與 Meta 側同期。取數走 service account + GA4 Data API（scripts/fetch_ga4_tiers.py），不再依賴桌面橋接或 Supermetrics。 ⚠️ 10-05、10-06 仍在回填，這幾天的數字之後還會變，不要拿來下結論或做逐日精確比較。 ②-d 是 Meta × GA4 的合成表，兩邊必須同期，不可以只把其中一邊往前推——那會做出一列沒有分母的到站落差。
中層（導流）這 6 天發生的事：花費從 2,365 元／天拉到 4,244 元／天（1.8 倍），到站落差從 10-01–10-03 的 95.5% 走到 10-06 的 96.7%，同一天的秒/階段 0.09 秒、GA4 工作階段 80（前一天 36）。
⚠️ 標「未回填」的日期不要拿來下結論。GA4 當日與前一日都會回填，那幾天的工作階段與參與秒數都還會往上走。真正該做的是明天回來看同一格——如果回填後落差仍然 > 50%，那才是「放量把品質打壞了」的證據；如果回到 30% 上下，那就只是回填延遲。先記錄，不要先結論（decisions.md「追蹤壞掉」那次的教訓）。
口徑：花費與 LPV 取自 Meta campaign 層級，層級依該 campaign 底下組合的優化事件判定（層級定義 v2，名稱上的層級字不採用）；已逐日與帳戶層級對帳。GA4 分層來自 sessionSourceMedium：cpc-t＝中層、cpc-m＋cpc-p＝下層，上層（曝光／觸及／影片）沒有 utm 分層、不比對，未標記的 facebook / cpc 不在此表內，所以各層的 GA4 階段數是低估、到站落差是高估——但這個偏誤逐日一致，看趨勢是安全的，看絕對值不安全。

判讀：本期沒有任何版位變化超過 10 pp，組成穩定。
兩期總花費 312,996 → 240,115 元（-23%），量級相當，佔比變化可以直接讀成組成漂移。
口徑：Meta platform_position breakdown 即時取數；本模組同時餵頁首的「版位漂移」KPI 與流量分頁紅點。

本期觸發：中層。中層 花費 +90%，同期到站落差 82.8% → 96.6%，這正是護欄要攔的形狀：錢加下去了，但到站品質同時在掉。
✅ GA4 已更新至 10-06，與 Meta 側同期。取數走 service account + GA4 Data API（scripts/fetch_ga4_tiers.py），不再依賴桌面橋接或 Supermetrics。 ⚠️ 10-05、10-06 仍在回填，這幾天的數字之後還會變，不要拿來下結論或做逐日精確比較。 逐日明細見 ②-d。
比較期是滾動 7 天 vs 前 7 天，與 ②-b 的兩期比較同慣例，兩期等長，不受月初天數影響。資料另抓 daily_tier_guard.json 與 ga4_guard.json，不共用主窗口的檔——②-d 與頁首 KPI 要的是 MTD，期間不一樣。