網店有一張訂單，瀏覽器傳送一份事件，伺服器再傳送另一份。有兩份本身不是錯誤；問題在於整合無法辨認它們是同一次行動。因此，要測試的是事件身份，不只是連線是否成功。
Events API 是系統向 TikTok 傳送事件的途徑。同一行動同時經 API 及 Pixel 傳送時，TikTok 要求兩邊使用 event_id 處理重複事件。也要核對事件名稱及現行的配對條件。 [1]
1. 與開發人員訂好事件規格
寫清楚系統何時視為購買、採用甚麼名稱、由誰產生識別碼，以及價值、貨幣和行動時間。重新載入網頁或修改訂單備註，不應為同一交易產生新的購買身份。
按 TikTok 標準事件清單核對名稱及參數。如果業務區分提交訂單與完成購買，事件對照表也要反映。更改報告名稱，不能修正錯誤的業務定義。 [2]
2. 測試兩條傳送路徑及重試
先測瀏覽器單獨傳送，再測伺服器單獨傳送，最後測同一行動經兩邊傳送。比較名稱、識別碼、時間及價值，並按整合文件記錄兩份事件如何處理。
接着模擬暫時傳送失敗及適當重試。重試不是新購買，整合設計必須保留同一行動的身份。價值或貨幣錯誤，應修正資料，而非反覆重送錯誤版本。
實際練習：整合驗收紀錄
以下是假設測試案例，由開發人員及量度專員在獲授權的測試環境填寫。
| 情況 | 檢查目的 | 建議驗收證據 |
|---|---|---|
| 同一行動經兩條路徑傳送 | 測試重複事件處理 | 記錄兩份事件如何處理 |
| 重試 | 保留行動身份 | 傳送紀錄能區分嘗試次數與訂單 |
| 價值錯誤 | 找出資料含義錯誤 | 拒絕或診斷狀態，以及修正行動 |
| 模擬延遲 | 了解時效及接受限制 | 行動時間、傳送時間及結果 |
| 不獲准分享的行動 | 檢查分享控制 | 按已批准設計不作傳送 |
每行補上實際結果、內部證據連結及處理負責人。「API 正常」並不足夠；應能從訂單系統追蹤至傳送及診斷，不能混淆嘗試次數與訂單數。
不要把存取權杖或客戶資料放進共用紀錄。使用測試識別碼，並按團隊權限及既定保留政策保存調查資料。
3. 對照來源紀錄閱讀診斷
Web Diagnostics 提供問題內容、嚴重程度及受影響資料集。把提示連結至測試個案：錯誤發生在建立事件、轉換資料，還是傳送？這有助確定負責人及重測範圍。 [3]
也要檢查行動至傳送的延遲。不要為了令紀錄看來較新，而以重試時間取代購買時間。與開發人員訂好持續失敗個案的處理方式，不能讓它們無人跟進。
4. 分開技術驗收與商業成效評估
通過驗收，只代表已通過商定案例，不等於銷售增加。覆蓋改善可能改變歸因數字，因此要把量度影響與業務評估分開。
交付事件對照表、測試紀錄、營運負責人及回退方案。不要因 API 測試成功就自動停用 Pixel，也不要把伺服器傳送當成資料分享控制的替代品。決定應按傳送設計、獲准分享的資料及業務需要作出。
官方參考資料
資料文件查閱日期：2026年10月16日。功能及資格要求可能改變，實施前請核對所連結的官方文件。
