Meta Pixel 在 browser 觀察 page、商品和互動，Conversions API 從 server 或平台 integration 傳送事件。CAPI 較不受瀏覽器載入錯誤與阻擋影響，但它不會自動知道 viewport、click 和實際前端狀態；Pixel 也無法取代可靠訂單和退款資料。
Meta 官方建議網站事件可同時使用 Pixel 和 CAPI，核心工作是事件定義、去重和合法資料使用。
依事件來源分工
PageView、ViewContent、Search、AddToCart 等前端行為通常由 Pixel 或 Shopify app pixel 取得。Purchase、訂單狀態和後續退款較適合平台/server 來源。InitiateCheckout 等事件可雙送，但需能證明兩邊代表同一次行為。
建立 event matrix，列 browser、server、觸發、必要參數、consent、去重、owner 和預期延遲。沒有明確用途的事件不要為了 coverage 全部雙送。
同一事件共享 event_id
Browser 和 server 對同一次 Purchase 使用相同 event name 與 event_id，Meta 才能辨認重複。Purchase 可從穩定 order ID 衍生；add-to-cart 則需要在前端產生後帶到 server action，不能各自建立亂數。
Event_id 對一次商業事件穩定，對不同事件則唯一。重試沿用原值，刷新不建立新 Purchase。實作與診斷可參考 Meta Pixel 重複排錯。
Server 不要重建不存在的前端行為
Webhook 告訴你訂單建立，不能據此推測顧客看過哪些頁、點過哪張推薦或同意哪種個人化。只傳送有可靠 source 的事件，並保存 event_source_url、action_source 和時間。
Client event 因 ad blocker 缺失時，CAPI 可以補充 server 看得到的結果，不能用模型或規則偽造完整旅程。
User data 採最小化與核准
Email、電話、external_id、IP、user agent 和 click ID 可協助 match，但每個欄位都需來源、目的、consent/法律基礎、格式和保存規則。依 Meta 規格正規化與雜湊，不把未知值、測試資料或整包顧客物件送出。
雜湊資料仍可能是個人資料。Server log、queue、dead letter 和 debug 工具也需遮蔽與權限。
Consent 在兩條路徑保持一致
CMP/Shopify privacy 的選擇要傳到 browser 與 server pipeline。只阻擋 Pixel，CAPI 照常送，是常見治理缺口。Market、purpose 和撤回後的行為由隱私 owner 定義。
測接受、拒絕、部分同意、回訪和撤回，查看 browser request、server event 和 Meta diagnostics。不要用 match quality 分數取代政策判斷。
CAPI 需要可靠重試
Server event 放入 queue，設定 timeout、retry、idempotency、dead letter 和監控。HTTP 成功只代表 Meta 接收，不代表事件內容正確或已歸因。保存 request ID、event_id、response、錯誤碼和時間，不保存不必要的原始 PII。
延遲事件使用真實 event_time，不在重試時改成現在。超過平台接受窗口的事件另行處理，不無限重送。
對帳事件與商業結果
每天比較 browser、server、deduplicated、matched 和 Shopify order。Value、currency、order ID、取消、退款與 test order 使用固定口徑。Meta attributed purchase 會因視窗和模型與訂單不同，需參考 電商歸因差異。
監看 coverage 很高但 dedup 很低、server 突增、event_id 缺失、value 不一致和 match quality 改變。每項異常都要能下鑽到 sample。
選擇單一整合 owner
Shopify App、partner gateway、自建 CAPI 和 agency server 不要同時各送一套。選定主要 integration，其他移除或限定事件，文件列 Pixel/Dataset ID、token owner、權限與退場。
CAPI 和 Pixel 的合理分工，是各自使用最可信資料描述同一顧客旅程，透過 event_id 合併重複，並在 consent 與訂單對帳上維持一致。