轉換延遲是什麼？ROAS 很低時，該等待還是調整？

什麼是轉換延遲？為何會影響 ROAS？

轉換延遲，是廣告互動到指定成果發生之間的時間。 訪客可能今天點擊，過幾天才付款；付款後，資料進入報表也可能再花時間。廣告費已到齊、成果尚未到齊時，近期 CPA 看起來偏高，ROAS 看起來偏低。但早期比率差，只能提醒你調查，不能證明之後一定有營收補回。

群組是固定的一批人，例如某個投放日點進 Campaign 的訪客。先固定這批人的廣告費，再追蹤歸給他們的後續成果，與「今天總共收到多少付款」是不同問題。比率與金額口徑可先看 ROAS 的公式與意思。

Google 的轉換延遲說明提醒，近期 CPA 與 ROAS 可能受尚未到齊的轉換影響，預測也應與已觀測結果分開。本篇教你建立可比較的檢查表，不重複討論歸因視窗該設幾天。

目前只有 0.5x，不等於未來一定變成 2x

以下全部是假設教學數據。A、B 是兩批不同投放日的訪客，各花 USD 100，花費均已結算。每筆有效付款訂單只計一次，每單 USD 50；採相同的點擊歸因規則，假設各檢查點的訂單對應與回報完整，幣別一致，初始金額不含退款、稅與運費。時間從每批最後一次廣告點擊後的完整天數計算，兩批的日內點擊分布相同。

較早的 A 已觀察八個完整日，新的 B 只有一個完整日。累計已觀測成果如下：

以各自最新截止時間看，A 有四單、B 有一單。直接拿 A 的 2x 與 B 的 0.5x 排名，混入了觀察長度差異。對齊滿一天的檢查點，兩批都是一單、ROAS 0.5x、每單 CPA 為 USD 100。這只代表首日已觀測數字相同，不能證明最終品質相同，更不能當成統計上可靠的平手。

A 滿七天時，ROAS＝USD 200 ÷ USD 100＝2x，每單 CPA＝USD 100 ÷ 4＝USD 25。B 的後續欄位仍是未知；不可把 A 的成果套給 B、把未到期欄位填成零，或挪用其他群組今天的付款補進來。七天只是教學檢查點，不是通用成熟標準；連 A 的七天數字也可能繼續變動。

分開記錄顧客等待、回報等待與報表日期

選一筆依法可保留且已對應的紀錄，記下廣告互動、業務成果完成、報表開始顯示三個時間。假設 9/1 點擊、9/4 付款、9/5 報表才顯示，就是顧客三天後付款，再等一天才回報。本例用 UTC，自己的檢查表也必須約定時區。

尚未付款，與目標系統已有付款但廣告報表沒有，是兩回事。後者應查事件傳送、對應、資格與處理狀態；多等幾天不會自動修好沒有接上的追蹤。

Google 的轉換時間欄位說明區分按點擊時間與按轉換發生時間呈現的欄位。9/4 的付款可能更新 9/1 點擊群組，同時在按付款時間的報表列入 9/4；兩個日期並沒有改變顧客的實際歷程。

評估獲客 ROAS，應對應取得那批流量的花費。把今天所有付款除以今天花費，可能混入過去取得的客戶。跨工具核對可接著使用 ROAS 報表對帳檢查表，不要為了讓報表數字相同就隨意改歸因設定。

用完整歷史資料選檢查點，不靠固定天數猜測

先挑較早且可比較的群組，確認選定的轉換視窗已經過完，預期回報也已完成。Google 的 Days to conversion 操作說明要求報表期間至少結束於三十天前；視窗更長時還要更早。這是在取得完整歷史，不是要求每次決策都一律等三十天。

用一致的檢查點，分別記錄累計轉換次數與金額。少數大單晚到，對金額的影響可能比次數更大。短的記錄視窗也會遮住較晚成果：七天報表沒有第九天訂單，不代表顧客不會在第九天買。請把 歸因視窗政策與現在觀察到哪一天分開管理。

假設完整歷史顯示，三十天內 USD 1,000 的金額中，滿七天已出現 USD 900，那麼七天涵蓋的是「該歷史樣本三十天已觀測金額的 90%」，不是終身價值的 90%。也不能直接把新 Campaign 的早期金額乘以 1 ÷ 0.9；素材、受眾、商品組合與回報涵蓋都可能變了。資料少或情況不同時，預測就標成不可用，約定下一次實際檢查。

資料成熟，不代表金額只能往上增加

後續購買可能增加金額，取消與退款則可能減少。假設 A 的四筆 USD 50 訂單中，後來有一筆全額退款；採扣除退款的營收口徑，修正後金額是 USD 150，比率為 1.5x，廣告費仍是 USD 100。原始訂單、保留訂單與調整日期要分開，不能默默把原本的毛額改稱淨營收。

Google 的轉換調整文件說明，受支援的轉換可以重述價值或撤回，條件與期限仍依設定而定。業務系統有退款，不證明每個廣告工具都已收到修正。已觀測、預測與後續調整後的金額，必須各自標示。

今天先做什麼？哪些判斷留到下次？

每次保留一筆決策紀錄：群組日期、時區、花費是否完整、成果定義、幣別、歸因政策、已觀察長度，以及上一次完整回報時間。附上相同觀察長度的比較、未對應或待處理資料，以及下一檢查點。先寫判斷規則，再看有沒有比較漂亮的後續數字。

• 資料傳送未完成： 抽查少量已對應紀錄，處理缺漏或拒收。未知成果與已確認零訂單要分開；零訂單時每單 CPA 無法定義。
• 群組尚新但追蹤正常： 先比較相同觀察長度，維持事先約定的花費上限。早期訊號用來調查，最後的購買判斷留到排定檢查點。
• 可比較的成熟群組仍差： 調查 offer、受眾與頁面體驗，選一個有界限的測試。一直等並不是策略，追蹤完整也不能證明訂單是廣告造成。

若已證實目標站故障、付款流程壞掉或預算超限，應立即暫停或限制花費。轉換延遲不能成為忽略故障的理由，任何公式也不能把少量樣本變成可靠結論。

MeetROAS 可協助分開看安裝、首次開啟與已串接的後續事件，找出成果在哪一段停止出現。目標系統仍須正確回傳與對應；安裝不是付款營收。可依 事件串接文件確認涵蓋，再保留目標系統的訂單與退款帳作對帳依據；這不代表系統會自動預測延遲或同步退款。