1. 前言：Day 14 開場那兩張圖其實已經把答案說出來了

Day 14 的開場拿了 LINE 重訓襪專案的兩張圖，cr-line-trn-p2 的點擊率 2.11%，cr-line-trn-p1 只有 1.66%，當時我寫兩張圖在人物、按鈕、色調、主打商品上都不一樣，差距從哪裡來要等 Day 17 把通路、受眾和商品都控管完成之後才能談，今天回頭看這兩張圖，在合成器會影響點擊率的三個設計屬性裡只差一個，p2 有人物、p1 沒有，p1 的按鈕在中間、p2 沒有按鈕，兩張都不在右下，主色一張中性一張冷色，都不是暖色，2.11 除以 1.66 是 1.27，又很接近合成器設定的人物乘數 1.25，一對圖的比值本來就會受各自的雜訊影響，這麼接近有運氣的成分，但拿它當主要例子等於挑了一個現成的答案，所以今天改用全部的圖一起比。

同一段話裡還有一句要收回，合成器算點擊率的公式裡只有通路的基準點擊率、設計屬性、每張圖自己的雜訊、素材疲乏、受眾和每天的雜訊，主打商品根本不在裡面，所以在這份資料裡商品不會影響點擊率，今天也就不用控管商品，這是合成資料的簡化，真實的廣告帳戶裡商品一定會影響點擊率，要比的時候商品也得放進分層裡。

還有一件事要先講清楚，今天的題目不是盲考，人物 ×1.25、按鈕在右下 ×1.10、暖色 ×1.10 這組答案 Day 05 就公開在合成器的設定裡，Day 06 對帳時也用設計規格算過一次（×1.28、×1.13、×1.08），換成 Day 16 AI 看圖讀出來的特徵，結果會一樣這件事在 Day 16 對完旗標時就知道了，今天真正沒看過的是兩件事，轉換率有沒有差別，以及沒植入效果的特徵會不會被誤判成有效果，今天的查詢都不呼叫 Gemini，全部在 BigQuery 免費額度內。

今日核心目標：

1. 把 Day 16 的特徵表和點擊率、轉換率 JOIN 在一起，在同一個通路、同一群受眾裡比較有沒有某個特徵的圖差幾倍
2. 先把判準寫死再看結果，補考 Day 13 留下的 S4，並加兩題「應該看不出差別」的反向檢查
3. 回答篇名，什麼樣的廣告圖比較會賣，把點擊率、轉換率和每次曝光帶來的成交分開看

2. 系統架構全景與設計理念

💡 核心工程理念：

1. 判準寫在結果之前：Day 13 的原則是看完成績不回頭改判準，要改就另開一版，今天的 criteria_v2.sql 在第一次執行之前 commit，run.sh 發現判準或分析的 SQL 有沒 commit 的修改就直接停下來
2. 分析只讀 AI 讀出來的東西：特徵來自 Day 16 的 mart_creative_features，規格留在答案資料集，run.sh 用 grep 確認分析的 SQL 沒有碰到 martech_gt 和還留著規格欄位的 raw 表
3. 不同的東西不混著比：再行銷受眾本來就比較會點、也比較會買，有某個特徵的圖如果剛好多半投在再行銷，直接平均就會把受眾的差別算成設計的差別，所以一律在同通路、同受眾裡比

3. 核心技術深度拆解

3.1 先寫判準：五道題裡有兩道的答案是看不出差別

Day 13 的成績單把 S4 標成「Day 17 再考」、門檻留空，今天照 Day 13 定下的規則另開第二版 criteria_v2.sql，其他訊號的判準逐字照抄第一版，S4 拆成五項：

下限不是隨手寫的，criteria_v2.sql 的初稿寫的是 1.02，交給獨立的審查者用合成器的雜訊設定模擬，發現按鈕在右下這一題就算完全沒有效果，算出來超過 1.02 的機率也接近一半，原因是各組裡的特徵沒有平衡，Day 05 設計素材時有照受眾把四個屬性平均分配，但切成通路 × 受眾四組、又排除素材疲乏的 cr-meta-evg-p1 之後，每組只剩五、六張，例如 Meta 開發新客那組唯一一張有人物的圖 cr-meta-trn-p1，同時也是右下按鈕加暖色，人物的效果會一起被算進去，所以三題的下限統一拉到 1.05，沒效果時超過 1.05 的機率降到一成以下，上限沿用第一版 S1a 的做法取答案值的 1.2 倍。

反向檢查是今天新加的，合成器沒有替文字多寡植入任何效果，轉換機率也只看通路和這是第幾次造訪，跟圖長什麼樣子無關，一套分析方法如果連沒效果的東西都說有效果，找到的那幾個也不可信，轉換率的範圍寬很多，因為成交比點擊少很多，3.4 節會看到它的信賴區間有多寬。

為了證明判準是先寫的，run.sh 在 criteria_v2.sql、lift.sql、score.sql 任何一個有沒 commit 的修改時直接停下來，這次判準的 commit 時間是 9/30 16:13:53，第一次評分是 16:14:43，評分時再把整張判準表算一個指紋，連同評分時間存進一張只加不刪的表 acceptance_s4_runs，檢查要求每次評分的指紋都一樣，這防的是評分之後再回頭改判準，評分之前有沒有先偷看，看的是 commit 時間早於第一次評分。

3.2 為什麼一定要分層：同樣八張圖直接比連方向都會反過來

先看每張圖的成效，23 張（排除 Day 09 找到素材疲乏的 cr-meta-evg-p1）依受眾分兩群，差別非常明顯：

再行銷的名單是來過網站的人，點擊率本來就高，轉換率更是高出一倍左右，這個差別和圖怎麼設計無關，如果不分層、把 23 張直接分成有沒有某個特徵兩堆來比，結果會被兩堆裡的受眾比例牽著走，下表是轉換率的倍數（算法在 3.4 節說明）：

按鈕在右下的圖有 8 張，開發新客、再行銷各 4 張，看起來很平均，但開發新客的 4 張裡有 3 張是跑了兩個月以上的常態或專案素材，再行銷的 4 張裡卻有 2 張是只上 16 天的秋日素材。

轉換率是把工作階段加起來算的，跑得久、曝光多的圖分量大，右下按鈕這一組的工作階段有七成七來自開發新客，沒有右下按鈕的那組只有五成八，開發新客的轉換率低，於是不分層算出 0.907，看起來右下按鈕讓人比較不買，分層之後變成 1.133，方向整個反過來，兩個數字其實都不代表按鈕影響轉換率，3.4 節會說明，但這個例子說明了直接比兩堆會得出什麼樣的錯誤結論。

分層的做法沿用 Day 06 對帳時的 verify.sql，通路 × 受眾共四組，每組裡把有、沒有這個特徵的圖分開，點擊率取幾何平均相除，四組的倍數再依組內張數加權合併：

EXP(SUM(LN(ctr_ratio) * ny * nn / (ny + nn)) / SUM(ny * nn / (ny + nn))) AS ctr_est

取對數再平均是因為效果是乘上去的，這樣算不會被點擊率本來就高的組拉走，ny、nn 是組內有、沒有這個特徵的張數，一邊只有一張的組權重小，兩邊張數接近的組權重大，今天四個特徵在四組裡都同時有「有」和「沒有」，四組都用上了。

3.3 點擊率：人物、右下按鈕、暖色都找到了而文字多寡沒有

點擊率分不分層差得不多是因為點擊率是一張圖算一票，按張數算兩堆的受眾比例本來就差不多，例如有人物的 11 張裡 5 張是開發新客、沒有人物的 12 張裡 6 張是，轉換率才會因為曝光大小不同被拉開，人物是三個特徵裡最明顯的，四組裡每一組都是有人物的圖點擊率比較高，組內倍數從 1.17 到 1.49，按鈕和暖色就沒那麼一致，暖色在 LINE 再行銷那組是 0.895，右下按鈕在 LINE 開發新客那組只有 1.005，每組只有五、六張圖，單一組的倍數會被一兩張圖左右，要看的是四組合起來的結果。

為了確認結論不是某一張圖撐起來的，報表第 4 段每次拿掉一張圖重算：

四個特徵都是拿掉 cr-meta-trn-p1 時最低，它是 Meta 開發新客那組點擊率最高的一張，四個特徵全部都有，人物和右下按鈕拿掉任何一張都還在門檻內，暖色就不一樣，拿掉這一張會掉到低於 1.05 的 1.031，文字多也一樣，拿掉這一張會變成 0.939，跑出反向檢查的範圍，被誤判成文字多讓人比較不點，也就是說暖色能過關、文字多看不出差別，都有一部分靠同一張圖，這兩個結論在 23 張圖上只能說方向是對的，要更有把握得有更多圖。

3.4 轉換率：點進來之後圖長什麼樣子看不出差別

轉換率是今天新加的，Day 06 的 verify.sql 沒有這一段，從廣告點進來的工作階段在 GA4 事件裡都帶著素材 ID（真實帳戶要靠網址上的 utm_content 對回素材），同一個工作階段有 purchase 事件就算成交，8/27 那天追蹤碼失效（Day 09 找到的），那天開始的工作階段不算，算法和點擊率有兩個不同：

1. 組內先合計再相除：秋日素材只上線 16 天，一張圖只有 4 到 13 筆成交，每張圖先算轉換率再取對數的話，萬一遇到 0 筆成交就算不下去，所以改成組內把工作階段和成交合計之後再相除
2. 依成交數加權：成交越少的組越不可信，各組的權重用 1 ÷（1 ÷ 成交_有 ＋ 1 ÷ 成交_沒有），同時算出 95% 信賴區間

四個信賴區間都包含 1，離 1 最遠的是按鈕在右下的 1.133，落在 S4e 的範圍內，反向檢查過關，這和合成器的設定一致，轉換機率只看通路和第幾次造訪，跟圖無關，但也要看清楚區間有多寬，23 張圖合計 623 筆成交，區間大約是倍數上下各一成五到兩成出頭，轉換率差一成的話這份資料分不出來，要差到三成左右才有把握分得出來，「看不出差別」和「沒有差別」是兩件事，今天能說的是前者。

篇名問的是比較會賣，最直接的指標是同樣的曝光帶來多少成交，報表第 7 段用同樣的分層和加權算每萬次曝光的成交數（這一段是第一次執行之後加的描述性指標，不在判準裡）：

有人物的圖每萬次曝光的成交是沒有人物的 1.395 倍，按鈕在右下是 1.274 倍，兩個區間都不包含 1，暖色和文字多看不出差別，這些倍數大致等於點擊率倍數乘上轉換率倍數，例如人物是 1.282 × 1.095，差別幾乎都來自點擊率，右下按鈕不分層時每萬次曝光的成交是 1.57 比 1.62，看起來還比較差，分層之後才是 1.274 倍，又是一個不分層就會看錯方向的例子。

圖的工作是讓人點進來，點進來之後買不買，在這份資料裡看的是這個人從哪裡來、來過幾次，這和合成器的設定一致，真實帳戶裡圖和網站說的不一致也會影響轉換，那是 Day 19 的題目。

3.5 揭曉：AI 讀的特徵換成規格結果一模一樣

最後一段才讀答案資料集，把同一套算法的 AI 特徵換成設計規格再算一次，另外把每張圖的點擊率直接設成答案乘數的乘積（不加任何雜訊），套同一套算法，看算法本身會算出多少：

AI 特徵和規格算出來完全一樣，23 張圖裡沒有任何一張的四個旗標不同，Day 16 唯一和規格不同的那一格是 cr-meta-trn-r2 的主色，規格寫 cool、AI 答 neutral，兩個都不是暖色，所以不影響今天的分析，在這批圖上 AI 讀出來的特徵可以直接取代設計規格，不過 Day 16 也說過，這批圖的文字和按鈕是程式畫上去的，條件比真實的廣告圖好。

不加雜訊的那一欄說明了暖色為什麼算出 1.08 而不是 1.10，就算每張圖的點擊率完全照答案走，這套算法也只會算出 1.086，因為分層只控管了通路和受眾，沒有控管另外兩個特徵，有暖色的圖剛好比較少有人物的時候，暖色的倍數就會被拉低，實測值和不加雜訊的期望值只差 0.02 以內，暖色和右下按鈕的偏差主要來自這 23 張圖的組合方式，人物和文字多則有一半左右是雜訊，要把三個特徵同時分開，得用迴歸把三個特徵一起放進模型，這一篇先用 Day 06 的算法，和當時的對帳結果對得起來。

4. FinOps 成本防護實踐：三道防線體系

1. 第一道防線：善用 Google Cloud 每月免費額度：今天全部是查詢，不呼叫 Gemini，run.sh 加報表的建表處理約 40 MB，全部查詢計費約 230 MB（每個查詢最少以 10 MB 計），在 BigQuery 每月 1 TiB 的查詢免費額度內，新增的五張表都只有幾列到幾十列
2. 第二道防線：架構層被動成本防護：fct_events 在 Day 07 就設了日期分區而且強制要帶日期條件，也依事件名稱叢集，lift.sql 只讀 session_start 和 purchase 兩種事件，忘了帶日期條件的查詢會直接被擋下，不會意外掃整張表
3. 第三道防線：Cloud Billing 預算警報：沿用 Day 03 由 Terraform 建立的預算警報（新台幣帳戶 NT$ 300／美元帳戶 US$ 10），50%、80%、100% 三段通知，今天的操作不會觸發

Day 16 建的用量表 ops_llm_usage 今天沒有新增任何一列，因為沒有呼叫 Gemini，今天的 Token 費用是 0 元。

5. Cloud Shell 實戰演練：一行指令從判準到揭曉

5.1 事前準備

• 先在 ~/ai-driven-martech-pipeline 執行 git pull，取得 Day 17 的 lift/ 目錄與 acceptance/criteria_v2.sql
• gcloud config get-value project 要印出你的專案 ID
• 已完成 Day 13（判準第一版與 gt_signals）、Day 15 的搬家（gt_creative_design）與 Day 16（特徵表 mart_creative_features）
• 確認 gcloud 有登入中的帳號，輸入 gcloud auth list，帳號前面要有星號

5.2 路線 A｜懶人包：一行指令跑完

cd ~/ai-driven-martech-pipeline && git pull && bash lift/run.sh

run.sh 先確認判準和分析的 SQL 都已經 commit，接著建判準第二版、算特徵與成效、評分，最後是 17 項檢查和七段報表，全程不呼叫 Gemini，可以重複執行，如果你改過 criteria_v2.sql 還沒 commit，它會直接停下來，這是故意的。

5.3 路線 B｜逐步教學：理解每一個步驟

步驟 1：判準第二版

cd ~/ai-driven-martech-pipeline
bq query --nouse_legacy_sql --format=pretty < acceptance/criteria_v2.sql

建立 martech_gt.acceptance_criteria_v2，印出 16 項判準，其中 S4a 到 S4e 是今天新加的。

步驟 2：特徵 × 成效

bq query --nouse_legacy_sql --format=pretty < lift/lift.sql

建立 mart_creative_perf（23 張圖各一列）與 mart_creative_lift（4 個特徵 × 點擊率、轉換率），印出分層與不分層的倍數，這一步只讀 martech_dw。

步驟 3：評分、檢查與報表

bq query --nouse_legacy_sql --format=pretty < lift/score.sql
bq query --nouse_legacy_sql --format=pretty < lift/check.sql
bq query --nouse_legacy_sql --format=pretty --max_rows=100 < lift/report.sql

score.sql 印出五項的判定，check.sql 是 16 項流程檢查，第 17 項由 run.sh 用 grep 補上，report.sql 七段分別是每張圖的特徵與成效、分層與不分層、逐組拆開、每次拿掉一張圖、補考成績、揭曉與每萬次曝光的成交，只有第 5、6 段讀答案資料集。

5.4 驗證成果

• mart_creative_perf 23 列、mart_creative_lift 8 列，四個特徵都用上四組
• acceptance_scorecard_s4 五項都是「找到」，點擊率人物 1.282、右下按鈕 1.126、暖色 1.082、文字多 0.970，轉換率離 1 最遠的是 1.133
• run.sh 的 17 項檢查全部通過，其中一項確認判準在第一次評分之後沒有被改過，一項確認分析的 SQL 沒有讀答案資料集

5.5 用完後怎麼處理

mart_creative_perf 和 mart_creative_lift 留著，Day 18 要拿點擊率最低的幾張圖和今天的倍數請 AI 打改版草稿，acceptance_s4_runs 是判準沒有被偷改的紀錄，只加不刪，這幾張表加起來不到一百列，儲存費在免費額度內。

6. 工程實務避坑指南

1. 不分層就下結論：有某個特徵的圖如果多半投在某一群受眾，直接比兩堆會把受眾的差別算成設計的差別，今天右下按鈕的轉換率不分層是 0.907、分層是 1.133，連方向都反過來
2. 轉換率不能照點擊率的算法：點擊率每張圖有幾百到幾千次點擊，轉換率每張圖可能只有幾筆成交，取對數遇到 0 就算不下去，組內先合計再相除，並依成交數加權
3. 看不出差別不等於沒有差別：623 筆成交的信賴區間大約是上下各一成五到兩成出頭，差一成分不出來，要差到三成左右才有把握，報告時要連區間一起給
4. 追蹤碼失效的那天要排除：8/27 的 purchase 事件整天沒送出，那天的工作階段全部會被算成沒成交，會把有投放那天的素材轉換率拉低
5. 看完結果不改判準：判準和分析的 SQL 都要在第一次執行前 commit，一張圖就能把暖色的倍數從 1.08 拉到 1.03，看到結果之後很容易想調門檻或換算法，這時候改就是在替結論找理由
6. SQL 的 CTE 名稱不要和欄位同名：報表第 4 段第一版把 CTE 取名 est，裡面的欄位也叫 est，MIN(est) 讀到的是整列的 STRUCT，BigQuery 直接報錯，Day 16 變數和欄位同名是同一類問題

7. 總結與明日預告

今天把 Day 16 AI 看圖讀出的特徵和點擊率、轉換率 JOIN 在一起，在同通路、同受眾裡比，有人物的圖點擊率是 1.28 倍、按鈕在右下是 1.13 倍、暖色是 1.08 倍，文字多寡看不出差別，轉換率四個特徵都看不出差別，同樣曝光帶來的成交，有人物是 1.40 倍、右下按鈕是 1.27 倍，判準第二版在執行前 commit，S4 的五項全部找到，AI 特徵換成設計規格算出來完全一樣，全程不呼叫 Gemini，查詢量在免費額度內。

回到篇名，什麼樣的廣告圖比較會賣在這份資料裡答案是有人物、按鈕在右下的圖，而且是因為比較會被點，把視覺特徵和轉換率放在一起比，看到的是點進來之後買不買跟圖看不出關係，要得出這個結論得先在同一群受眾裡比，否則連方向都可能是反的，另外要記得這是 23 張圖、623 筆成交的結果，暖色能過關、文字多看不出差別都有一部分靠同一張圖，轉換率要差到三成左右才有把握分得出來，真實帳戶要下結論需要更多素材和更長的時間。

明日預告：Day 18《靈感卡關時，讓 AI 根據成效幫你打下一版素材草稿》，今天知道人物、右下按鈕、暖色這三個特徵和點擊率有關，明天把這些倍數和點擊率最低的幾張圖交給 Gemini，請它提出改哪個地方、為什麼、新的構圖怎麼寫。