ChatGPT 廣告事件重複怎麼查？從訂單事實到瀏覽器與伺服器去重

ChatGPT 廣告事件重複怎麼查？從訂單事實到瀏覽器與伺服器去重

網站只完成十筆訂單，量測卻顯示更多完成事件，問題可能不是生意突然變好，而是同一個事實被看了兩次。瀏覽器、伺服器通知與使用者重新整理，都可能造成重複。

去重必須先定義什麼是同一件事，再對應平台的正式規格。本篇提供內部設計與排查流程，實際欄位名稱及平台去重規則應由工程查核官方文件。

分清訂單與事件的關係

一張訂單可能包含建立、付款與退款三種不同事實，不能因訂單編號相同就全部合併。反過來，同一筆付款的多次通知也不應被當成多次成交。

先畫事件生命週期，標出哪些是新狀態、哪些只是同狀態的重送。這一步由業務與工程一起確認，避免純技術去重刪掉真正有意義的後續事件。

• 每種事實有清楚的完成條件
• 新狀態與重送分開標記

在事實產生時給穩定識別

同一事件應在最可靠的位置產生一次識別，再交給需要使用的傳送路徑。每次頁面載入重新生成識別，會讓系統難以認出其實是同一個完成動作。

假設付款已確認，瀏覽器與伺服器都要回報，就應共用能指向同一事實的內部識別，再按官方規格映射。不要直接拿姓名或電話充當事件識別。

• 識別不包含可讀個資
• 重送沿用原事件識別

用台帳看清每條路徑

台帳至少記錄業務事實、內部事件、來源路徑、發生時間與傳送狀態。只看總數，很難判斷是瀏覽器重複、伺服器重試還是跨來源重疊。

先挑少量測試交易逐筆追查，不必一開始匯出全部客戶資料。把異常分類，能讓修正對準問題，而不是一律關掉其中一種量測。

• 來源路徑使用固定名稱
• 台帳限制權限與保存期限

用故意重複的測試驗收

依序測成功一次、重整成功頁、返回再進入、連點提交與伺服器重送。每種情境事先寫出預期業務件數和事件件數，避免看到數字後才改標準。

也要測兩筆不同訂單是否被誤合併。去重太強會漏算，太弱會灌高，兩邊都需要反例，不能只證明重送沒有增加數字就宣布通過。

• 測試相同事實與不同事實
• 記錄每次測試的版本與時間

把對帳變成固定維護

每週比較訂單完成、已傳事件與平台報表，先校正時間與範圍。三者可能因歸因等因素不同，不能要求所有數字相等，但異常跳升必須能解釋。

交付一份異常處理順序：先查業務事實，再查識別與重送，最後查平台設定。把修正日期加進週報，避免將技術修復誤讀成市場表現變化。

• 追蹤重複率與誤合併案例
• 網站改版後重跑反例測試