Web 廣告歸因要回答三件事：用戶從哪條廣告而來、是否真正付款，以及訂單如何回傳給渠道。本文整理自小魏 2026 年 10 月 6 日《幫老闆節約 5 萬美金的歸因工具》，以線上圖片處理工具的付費額度為例，說明 Simple KUMA 的點擊追蹤、服務端回傳與訂單去重。
「5 萬美金」來自原文標題，並非本文已核驗的節省金額。免費軟體仍有 VPS、網域、開發、備份和維護成本；Web 測試也不能證明它可完整取代 App MMP。
Simple KUMA 可以負責什麼？
它可用於自架 Web 點擊與轉換追蹤、活動管理及基礎報表。作者另外自建 TikTok 回傳中繼；這是作者的實作，並不表示安裝後自動具備相同功能。業務後端仍須處理用戶關聯、訂單、支付驗證與重試。請核對官方指南及安裝版本。
把點擊、訂單與購買連起來
- 廣告點擊經追蹤入口進入網站。
- KUMA 產生 click_id，網站保存真實渠道標識並與用戶關聯。
- 建立訂單時，把歸因關聯持久化到服務端記錄，不只放在 Cookie。
- 後端驗證支付通知的真實性，核對訂單、金額、幣別和付款狀態。
- 確認付款後，以穩定事件標識記錄購買，再回傳 KUMA 及對應渠道。
完整流程為廣告點擊 → 追蹤入口 → 網站 → 訂單 → 後端確認付款 → 轉換記錄 → 渠道回傳。感謝頁被開啟並不等同付款成功。
區分三類標識
| 欄位 | 用途 |
|---|---|
| ttclid、fbc、fbp | 依適用情境協助渠道匹配點擊或瀏覽器，三者角色不同 |
| KUMA click_id | 串接追蹤點擊與註冊、訂單等業務行為 |
| order_id、txid、event_id | 辨識交易或事件，處理去重及重試 |
不要以 KUMA click_id 冒充 ttclid，也不要偽造 fbc、fbp，或把伺服器資訊當成用戶資訊。只使用實際取得且獲允許使用的資料。
同一訂單重試，事件 ID 不變
一次點擊為 K_DEMO_01，第一筆訂單是 O_DEMO_01，購買事件為 webimg:purchase:O_DEMO_01。第二筆訂單改為 O_DEMO_02，事件 ID 也跟著改變；第一筆訂單重試十次，仍沿用第一個事件 ID。
示例金額 19.90 USD 應從後端訂單讀取。不能信任瀏覽器提交的金額，也不能僅按 click_id 排除同一來源的第二筆真實購買。業務側先依訂單與事件類型做冪等，再依所用版本設定 txid、event_id 及事件鍵。欄位與規則見官方 Postback 文件。
分開驗證 Pixel、KUMA 與渠道回傳
本案例以後端確認的付款為購買依據。Meta Pixel 與 CAPI 同時發送同一筆 Purchase 時，核對事件名稱與穩定事件 ID。其他渠道依各自介面處理。KUMA 有記錄不代表渠道已接收，應保留入站與出站結果，重試時沿用原事件 ID。
放量前驗收
- 用真實測試點擊跑完註冊、訂單及付款。
- 重複支付通知或刷新感謝頁，購買數不應增加。
- 同一來源付款兩次，應有兩筆獨立購買事件。
- 失敗或未通過驗證的付款不能記成成功購買。
- 對齊訂單、追蹤器及渠道接收結果後，再逐步增加預算。
先比較總成本，不要為省工具費在未驗證的鏈路上投入大額預算。延伸閱讀：歸因差異排查、廣告優化漏斗診斷及投放教學。改編自小魏原文。
常見問題
Simple KUMA 能完整取代 AppsFlyer 或 Adjust 嗎？
不能從 Web 測試推論。應先比對 App 歸因、SDK、隱私框架、渠道支援及服務需求。
免費工具一定能省下 5 萬美金嗎？
不能保證。原文標題不是已核驗的節省金額，須計入伺服器、開發與維護成本。
同一個 click_id 可以對應多次購買嗎？
可以。不同訂單使用獨立事件標識，同一訂單重試保持不變，並按版本配置多次轉換與去重。
為何不只靠感謝頁回傳購買？
感謝頁可能刷新、遭攔截或中斷；應由後端驗證支付通知及訂單金額、幣別和狀態。