本簡報以 16:9 橫向為主
請旋轉手機
或改用平板 / 桌機觀看
Meta Pixel 九大事件 → CAPI 後端直送 → event_id 去重 + EMQ 提分——
三步把iOS ATT 後廣告效能找回來。
iOS 14 / ATT 上線後，Browser Pixel 平均掉 30% 事件——
沒 CAPI 補的廣告，學習期永遠不會結束。
不是看懂——是能上線、能驗證、能截圖給老闆看。
九件事、三層分組——
覆蓋電商與 B2B 的主要轉換漏斗。
Meta 的演算法吃標準事件訓練；自訂事件很難被最佳化。
先把標準事件做對，ROAS 就贏一半。
Purchase），GA4 用 snake_case（purchase）——dataLayer 用一套，在 GTM Tag template 轉換就好。
TWD / USD）。缺 value = 變 $0 歸因，演算法以為這筆「不重要」。'product' 或 'product_group'。缺 content_ids = 無法做 DPA（動態商品再行銷），catalog 對不回來。fbq('init', PIXEL_ID, { em: hashEmail, ph: hashPhone, fn: firstName })——email/phone 必須 SHA-256 hash 後才送，明文 Meta 直接拒收。EMQ 6.0+ 是廣告效能良好的門檻。
Meta 沒有官方 GTM Template（有社群版本），自訂 HTML Tag 是傳統做法。
裝完第一件事：到 Events Manager Test Events 分頁驗證。
fbq('track','Purchase',{value, currency, content_ids})某電商把 Meta Pixel base code 放在 </body> 前、PageView 又自己寫在按鈕 onclick——
PageView 平均 8 秒後才觸發，使用者很多在 8 秒內就關掉。
</body> 前 + PageView 綁 onclick → 覆蓋率 62%，廣告學習期一直不結束。<head> 內、PageView 由 base code 自動 fire。其餘自訂事件（ViewContent / AddToCart）才另外觸發。iOS ATT 後 Browser Pixel 量減 30%——
CAPI 從你的 server 直送 Meta，不怕 adblocker、不怕 ITP。
不要三條都試——挑一條走完。中大型客戶走 A，小客戶走 B 或 C。
woocommerce_order_status_completed hook + curl_post 到 Meta Graph API。零月費，但要寫 / 維護 PHP。建議用 facebook-business SDK。Browser 與 CAPI 的同一筆 Purchase 必須共用同一個 event_id，Meta 才能去重。
四步都對才生效，少一步就雙算。
crypto.randomUUID() → 寫進 sessionStorage + push 進 dataLayer。fbq('track', 'Purchase', {…}, {eventID: 'xxx'}) ——第三個參數帶進去。order_item_meta），讓後端 hook 拿得到。event_id 欄位帶入 → 送 Meta。order_id 當 event_id 也行——但可被猜測，不如 UUID 安全。前端 UUID v4、後端 UUID v5 也算「對不上」，統一用一種。
CAPI 不是萬能解藥——如果 EMQ 只停在 6 以下，等於只是把事件送過去但 Meta 匹配不到使用者。
關鍵是使用者資料的 hash 品質（email + phone + fbp + fbc + IP + UA 至少 5 個）。
裝好 CAPI 不等於完事——EMQ 分數低代表 Meta 認不出使用者，
廣告最佳化沒效。把「做對」推到「做好」。
Events Manager → 選 Pixel → Overview → 找 Purchase → 看 Deduplication 欄位，應該顯示「Server + Browser 事件去重成功，X% 重複」。
Event Match Quality 衡量 Meta 把事件匹配到 Facebook 使用者的能力。
低於 4.0 廣告效能會明顯受損；每補一項通常 +0.5 到 +1.0。
trim + lowercase 再 hash；phone 移除非數字（E.164）再 hash。明文 Meta 直接拒收，分數歸零。
user_data: {
em: sha256(lowercase(trim(email))),
ph: sha256(only_digits(phone)),
fn: sha256(lowercase(first_name)),
ln: sha256(lowercase(last_name)),
fbc: cookie._fbc, // 不要 hash
fbp: cookie._fbp, // 不要 hash
client_ip_address: $_SERVER.REMOTE_ADDR,
client_user_agent: $_SERVER.HTTP_USER_AGENT
}
① Test Events 看到 Purchase 完整 9 大事件至少 5 個，value / currency 正確
② 從 GTM SS / Make / PHP 任一條路徑送 Purchase，看到「Browser + Server 接收」標記
③ Events Manager 顯示 Purchase EMQ ≥ 6.0、去重率 ≤ 10%，截圖存證
三項都完成 = 能上線、能驗證、能對老闆交代。
EMQ 一直 3.x 卡關 → 機動時段帶來，逐項補。
Meta 那一套打對之後，回頭看其他三大平台——
名稱不同、API 不同，但底層邏輯都是 Pixel + Server-side + 去重。
Meta 三件套打對 → 其他三平台套同一套邏輯。
後四週都會回頭對照這個 event_id 與 EMQ 框架。