歸因窗口是什麼？為什麼不同報表的轉換數對不起來

先說結論：三種報表在回答不同問題

廣告平台和分析工具的轉換數不同時，不要先挑一個數字當唯一真相，也不要把所有平台轉換直接相加。先判斷你正在回答哪一種問題：

• 實際成交多少？ 以去重、扣除取消退款後的訂單系統、CRM 或財務資料為基準。
• 跨渠道如何分配轉換功勞？ 使用同一事件定義與歸因規則的 GA4、資料倉儲或其他跨渠道分析。
• 某廣告平台要如何出價與優化？ 看該平台依自身可觀測接觸、窗口與模型計算的轉換。
• 如果沒有廣告，這筆轉換還會不會發生？ 一般歸因報表回答不了，需要有對照組的增量實驗。

不同數字不一定代表追蹤壞掉。平台可能看見不同接觸、使用不同窗口、把轉換歸到不同日期，或以不同方式處理瀏覽、點擊、跨裝置、同意狀態與重複事件。真正需要警戒的是：差距無法用明確規則解釋、同一規則下突然跳變，或平台事件和後端訂單無法透過交易識別碼合理對帳。

歸因窗口是什麼？它不是「廣告影響力保存期限」

歸因窗口（attribution window／conversion window）是：從一次符合資格的廣告接觸開始，往後多長時間內發生的轉換，仍可以依該系統的規則記給這次接觸。

Google Ads 將轉換窗口定義為廣告互動（例如點擊或影片觀看）後，轉換仍會被記錄的一段時間。它可以依轉換動作設定；點擊後、參與觀看後與瀏覽後轉換也可有不同窗口。窗口縮短，較晚完成的轉換就不會被該轉換動作計入。

GA4 則在歸因設定中區分報表歸因模型、可獲得功勞的渠道，以及關鍵事件回溯窗口。這表示「往回看多久」和「在合格接觸之間怎麼分功勞」是兩個不同設定：

1. 窗口先決定候選集合：哪些較早接觸仍在可計入範圍。
2. 模型再分配功勞：最後點擊或資料驅動模型如何處理候選接觸。

窗口不是廣告實際影響力的自然邊界。七天窗口不代表第七天仍有影響、第八天突然完全沒有；它只是衡量規則。較長窗口會納入更多晚轉換，也提高接觸重疊與多平台同時認領的機會；較短窗口較接近近期反應，卻可能漏掉長決策週期。

為什麼同一筆訂單，三套系統會出現不同數字？

1. 看見的接觸不同

廣告平台通常最清楚自己站內的曝光、點擊與登入訊號，卻不一定完整看見其他平台、電子報、自然搜尋、門市或口碑。跨渠道分析工具能接收多種來源，但仍會受到標記遺失、Cookie、跨裝置、瀏覽器限制與使用者同意影響。

Meta 官方說明，Conversions API 可把網站、App、門市、CRM 與其他後段事件傳回 Meta，用於衡量與優化；它能改善連線可靠度，但不是繞過隱私選擇的工具，也不會讓平台自動擁有公司全部商業事實。

2. 點擊、瀏覽與影片參與的資格不同

一位顧客可能看過社群廣告但沒點，之後點搜尋廣告完成購買。若社群平台的瀏覽後接觸仍在設定窗口內，而搜尋平台的點擊也在窗口內，兩邊都可能依自己的規則列為轉換。GA4 的一般跨渠道歸因與廣告平台的瀏覽後欄位也未必涵蓋相同接觸種類。

3. 歸因模型不同

最後點擊會把全部功勞給最後一個符合資格的接觸；資料驅動歸因則可能把同一個關鍵事件拆成小數功勞分給多個渠道。Google 官方也提醒，歸因模型會影響 Conversions 與 All conversions 欄位，並進一步影響使用這些資料的自動出價。

因此，看到某渠道在資料驅動模型下得到 0.4 筆轉換，不代表後端出現四成訂單；它代表一筆事件的部分歸因功勞。

4. 計數方式與轉換欄位不同

Google Ads 的轉換動作可以選擇 Every（一次互動後每次符合條件的轉換都計入）或 One（一次互動後只計一次）。Every 常適合每筆銷售都有價值的情境；One 常用於同一廣告互動後重複送表，但只想辨識一位名單的情境。

此外，Conversions 通常只包含被設為主要的轉換動作；All conversions 還可能包含次要動作與其他轉換類型。拿不同欄位、不同事件或不同計數設定互比，差異本來就會存在。

5. 轉換被放到不同日期

Google 官方的跨產品說明以一個很直接的例子指出：使用者在 7 月 19 日點廣告、7 月 20 日購買時，Google Ads 可把轉換歸到 7 月 19 日的點擊日，Analytics 則把事件放在 7 月 20 日的實際發生日。

所以逐日報表對不起來，不代表整段期間一定也不同。比較前要先確認時區、日界線與日期歸戶規則；月底或促銷截止日前後尤其容易把同一筆轉換拆到不同報表期間。

6. 資料成熟時間、建模與退款處理不同

GA4 官方說明，標準資料處理可能需要 24 至 48 小時，歸因功勞也可能在關鍵事件記錄後持續調整。Google Ads 的近期資料則會受轉換延遲影響：費用已完整出現，晚轉換尚未回補時，CPA 看起來偏高、ROAS 偏低。

後端還可能在訂單成立後才收到取消、部分退款、付款失敗或人工剔除測試單。若這些調整沒有同步回廣告平台，平台歸因營收自然會高於財務淨營收。

完整例子：一筆 3,000 元訂單，平台加總卻出現兩筆轉換

以下是虛構教學案例，用來呈現規則差異，不是任何平台或客戶的實際結果。

某顧客完成同一段購買旅程：

日期	接觸	可確認事件
7 月 1 日	點擊平台 A 的廣告	平台 A 與網站收到點擊識別
7 月 4 日	點擊平台 B 的廣告	平台 B 與網站收到點擊識別
7 月 6 日	從電子報回到網站	GA4 收到 Email 工作階段
7 月 8 日	完成 3,000 元訂單	後端建立一筆唯一訂單

再假設平台 A 使用七天點擊窗口，平台 B 使用三十天點擊窗口；兩邊都能把訂單與先前點擊配對。不同系統可能呈現：

系統	看到的結果	為什麼
後端訂單	1 筆／3,000 元	實際只有一個唯一訂單編號
平台 A	1 筆歸因轉換	購買落在 A 的假設窗口內
平台 B	1 筆歸因轉換	購買也落在 B 的假設窗口內
GA4 事件範圍報表	合計 1 筆功勞	依所選跨渠道模型分給合格接觸，總和仍是一筆事件

平台 A 加平台 B 等於兩筆，卻不能推導公司賣了兩筆。它只表示同一訂單同時符合兩套平台歸因規則。若把兩個平台的歸因營收相加，會得到 6,000 元，剛好是實際收入的兩倍。

再看日期：平台若按互動日歸戶，A 的轉換可能回到 7 月 1 日，B 回到 7 月 4 日；後端與 GA4 的事件日期則在 7 月 8 日。逐日比較全部不相等，但把範圍拉長、改用同一交易 ID 對照，就能看出它們指向同一筆訂單。

這個例子不表示平台一定「高估」，也不能證明哪個接觸造成購買。平台數字適合各自優化投放；跨渠道資料適合在統一規則下分配功勞；真正要判斷廣告是否增加了原本不會發生的訂單，仍要靠增量測試。Google 將 Conversion Lift 明確區分為有廣告的實驗組和沒有廣告的控制組，用兩組差異估計因果增量。

應該相信哪個？建立「決策問題 × 資料來源」分工

決策問題	優先資料	必須補充的限制
本月實際成交、淨營收與退款多少？	訂單／CRM／財務	去重、付款狀態、取消、退款與稅務口徑
使用者從哪些渠道來、跨渠道功勞如何分配？	GA4 或資料倉儲	同一歸因模型、窗口、身分與事件範圍
某平台要以哪些訊號出價？	該廣告平台的主要轉換	平台視野、窗口、模型與回傳品質
各渠道預算如何做管理比較？	後端成果＋統一跨渠道規則	不直接相加平台歸因；固定版本與觀察期
廣告真正增加多少轉換？	隨機或合適的地理增量實驗	樣本、外溢、實驗期間與可推廣範圍

這個分工也能避免把 ROAS 當成財務營收。若平台營收和後端差距很大，先用站內的ROAS 與實際獲利拆解確認取消退款、成本與多平台重複認領，而不是直接拿最高的平台數字做預算。

八步對帳流程：先校正口徑，再找追蹤故障

1. 寫下唯一商業事件與主鍵

先明確定義要對帳的是付款成功、訂單建立、有效名單還是成交。購買至少要傳遞唯一交易 ID、金額、幣別與事件時間；名單也要有可安全去重的內部識別方式。沒有共同主鍵，只能比總數，無法判斷漏記和重複。

2. 先驗證後端，再驗證標籤

用測試訂單走完成功、失敗、重新整理、跨網域付款與退款流程。確認網站事件只在正確時機觸發，瀏覽器與伺服器雙路回傳有做去重，金額與幣別一致。若事件本身錯了，調窗口只會把錯誤分配得更精緻。

3. 對齊事件、欄位與計數

列出每套系統實際比較的事件名稱、主要或次要狀態、Conversions 或 All conversions、One 或 Every，以及是否含瀏覽後轉換。不要拿「所有關鍵事件」和「主要購買轉換」比較。

4. 對齊日期、時區與歸戶日

記錄帳戶時區、後端時區、轉換實際時間，以及報表按點擊日、曝光日或轉換日呈現。先用至少涵蓋完整決策週期的範圍比較，再切到單日尋找邊界差異。

5. 對齊窗口與歸因模型

為每個轉換動作建立設定表：點擊後窗口、瀏覽後窗口、可獲得功勞的渠道、最後點擊或資料驅動模型，以及變更日期。Google Ads 官方說明，窗口變更只影響往後記錄的轉換；因此前後期間若設定版本不同，不應直接當成成效變化。

6. 分開檢查可觀測與建模資料

確認 Cookie、點擊識別碼、UTM、同意模式、跨裝置與伺服器事件的覆蓋。建模轉換是依限制下可用資料估計的結果，不是可逐筆還原的訂單。對帳表應分開「直接配對」「建模／估計」與「未配對」，不要把三者混成一欄。

7. 用交易 ID 建立差異分類

將可安全取得的訂單 ID 依下列狀態分類：後端有且平台有、後端有但平台無、平台有但後端無、同一 ID 重複、金額不同、窗口外、尚在延遲期。每一類抽樣查時間線，才知道該修標籤、去重、退款回傳，還是只要接受規則差異。

8. 建立固定對帳表與警戒線

每週或每月保存設定版本、成熟資料截止日、後端淨訂單、各平台歸因轉換、GA4 關鍵事件、直接配對率、重複率與差異原因。警戒線應依自己的穩定基線設定，例如「直接配對率連續兩天偏離過去區間」，而不是要求所有報表永遠相等。

若差距其實來自網站事件漏送、重複或工作階段定義，先回到網站 CVR 的追蹤與流量診斷；若後段成交與 CRM 沒有回傳，則可搭配廣告轉換目標的訊號品質檢查。

六個常見誤判與限制

把較大的平台數字當成「比較準」

數字大可能來自較長窗口、包含瀏覽後轉換、Every 計數或多種轉換動作，不代表更接近實際營收。先查設定，再談準確。

為了讓數字一樣，強迫所有工具用同一角色

後端不會知道每次廣告曝光，平台也不會自動知道所有退款與跨平台接觸。合理目標是可解釋、可對帳且適合決策，不是每一欄完全相同。

把歸因當成因果

接觸落在窗口內，只表示符合分配功勞的規則；不表示沒有這次接觸就不會購買。品牌搜尋、再行銷與既有顧客尤其容易得到漂亮歸因，增量仍需對照實驗。

用最近一天評估長決策週期

費用先發生、轉換後回補，近期 CPA 自然較差。至少等待常見轉換延遲與資料處理完成，再和同樣成熟的歷史期間比較。

只改窗口，不記錄版本

窗口、模型、主要轉換或計數方式改變，都會讓時間序列斷裂。設定變更應有日期、原因、預期影響與回復條件。

把更多資料連線當成隱私豁免

伺服器、CRM 或離線事件回傳仍須遵守適用法律、平台條款與使用者選擇。資料可用性、衡量需求與隱私責任必須一起設計；本文不是法律意見。

最後帶走這張對帳清單

• 歸因窗口決定哪些接觸仍有資格，歸因模型再決定如何分配功勞。
• 實際成交看去重後的訂單、CRM 或財務；平台轉換主要服務平台優化。
• 不直接相加多個平台的歸因轉換或營收，同一訂單可能被重複認領。
• 比較前固定事件、主要／次要欄位、One／Every、點擊／瀏覽、窗口與模型。
• 對齊時區，並確認報表按互動日還是轉換日歸戶。
• 等待轉換延遲與資料成熟，將直接配對、建模與未配對事件分開。
• 使用唯一交易 ID 對帳，把差異分類成漏記、重複、窗口外、退款或規則差異。
• 要判斷因果增量，使用有對照組的實驗，不用歸因窗口代替。

不同報表的轉換數對不起來，通常不是一道「到底相信誰」的選擇題，而是一道資料治理題：每套系統看見什麼、用哪套規則、服務哪個決策，是否都能被清楚說明。 先讓商業事件可去重、設定有版本、差異能分類，再用平台、跨渠道分析與後端資料各司其職，歸因才會從爭論數字變成可持續的決策工具。