Meta API v25 對台灣代理商廣告投放的 8 個改變（含歸因視窗實戰）
Meta Marketing API v25 對台灣代理商最關鍵的三個改變：① v23 以下版本於 2026-06-09 全面汰除，必須升到 v24＋（建議直上 v25），否則報表端點會斷線變空白；② 7 天與 28 天 view-through 歸因視窗已被移除、只剩 1 天 view，跨月比較必須標明歸因視窗，否則 ROAS 會無預警縮水；③ 轉換計算要用優先序白名單 first-match（omni_purchase → purchase → offsite_conversion），把彙總型與子類相加會雙算高估購買數。Admetry 把 Meta 版本常數集中於單一檔案並加週排程版本看門狗，串接層以正確的轉換認定避免雙算，再由 Gemini 產出跨平台對齊的洞察，台灣代理商不必自己追 Meta changelog。
Meta Marketing API 在 2026 年有兩個會直接打斷台灣代理商報表的硬改變：v23 以下版本在 2026-06-09 全面汰除，以及部分歸因視窗被移除。這不是文件上的小字，而是我們在把 Meta 串進 Admetry 時真的踩到、必須改 code 才能拉到正確數字的東西。以下 8 點按「會不會讓你的月報數字錯」排序。
1. v23 以下 2026-06-09 全停，必須升 v24＋（建議直上 v25）
Meta 公告所有 v24.0 以下的 Marketing API 版本在 2026 年 6 月 9 日汰除，建議直接升到 v25.0（2026-02-18 發布）以減少未來遷移。代理商最容易中招的地方是：你用的第三方匯入工具或自建串接把版本字串寫死在好幾個檔案，到期那天部分端點直接斷線、報表變空白。我們的做法是把版本常數集中在單一檔案、再加一條 CI 檢查禁止任何檔案散落寫死版本——升版只改一處。
2. 歸因視窗大改：7 天 / 28 天 view-through 被移除
這是最容易讓「同一個活動上月 ROAS 3.8、這月變 2.9」卻不是投放變差的元兇。Meta 移除了 7 天與 28 天的 view-through（曝光後轉換）歸因視窗，只保留 1 天 view 等較短選項，截止調整日為 2026-01-12。如果你的報表或客戶 KPI 還用 28 天 view-through，數字會在無預警下縮水。月報一定要標註當期歸因視窗，跨月比較才有意義。
3. 轉換重複計算陷阱：彙總型不可與子類相加
這是我們串接時實際抓到、且很多工具默默算錯的點。Meta 的 `actions` 同一列會同時回彙總型（如 `omni_purchase`）與組成子類（如 `offsite_conversion.fb_pixel_purchase`）。如果你把整列相加，購買數會雙算高估；如果你用前綴加總，又會把 add_to_cart 之類子類灌進轉換。正確做法是優先序白名單、first-match：認最高優先那一型就好，不跨型相加。我們的轉換認定固定走 `omni_purchase → purchase → offsite_conversion.fb_pixel_purchase` 的優先序，命中即停。
4. Advantage+ Shopping / App 不能再用 Marketing API 建立或更新
從 v25.0 起，Advantage+ Shopping 與 Advantage+ App 活動無法再透過 Marketing API 建立或更新，90 天後擴及所有版本。如果你有自動化建單流程，這條會讓建單失敗——讀取報表不受影響，但「自動開活動」要改回介面或調整流程。
5. 自動升版不可靠，工具必須主動釘版
Meta 自 2024-05-14 起「可能」把舊版呼叫自動升到下一版而非直接失敗，但官方明說不保證所有端點、非長久之計。代理商不要賭這個——主動把串接釘在明確版本（我們釘 v25 常數），到期前自己排程升版，比讓 Meta 幫你「猜」要穩。
6. token 過期要主動處理（error code 190）
長期跑的代理商帳號，access token 會過期或被使用者改密碼後失效，Meta 回 error code 190。沒有處理的串接會在某天早上整批同步失敗、報表停更。串接層要把 190 當「需重新授權」分類、推播通知，而不是當一般錯誤吞掉。
7. 跨平台比較必須鎖同一歸因口徑
當你把 Meta、Google Ads、LINE LAP 放進同一張 ROAS 排名表，每個平台的歸因視窗、時區、轉換定義都不同。Meta 縮歸因視窗（第 2 點）後，這個落差更大。我們在對帳時的鐵則是：每筆對照值都記錄「抽樣時間點 + 當時口徑設定」，否則平台數據隨歸因回填變動，會製造看起來像 bug 的假落差。
8. 版本字串集中化是維運護城河
把上面這些濃縮成一句維運心法：API 版本是會過期的資產。我們的做法是版本集中一處 + 週排程的版本看門狗，釘選版本距 sunset ≤90 天就自動告警。代理商自建或選工具時，可以直接問一句：「你們的 Meta 版本寫在幾個地方？到期會主動通知嗎？」答不出來的，到期日就是你報表斷線日。
常見問題（FAQ）
Q：v23 到期那天會發生什麼事？ A：v24 以下端點開始回錯誤或被不保證地自動升版，報表可能變空白或數字跳動。務必在 2026-06-09 前升到 v24＋。
Q：歸因視窗變了，舊月報數字還能比嗎？ A：可以比，但要在報表標明各月的歸因視窗；7/28 天 view-through 移除後，跨期直接比會低估近期表現。
Q：怎麼確認我的工具沒有把 Meta 購買數雙算？ A：用一筆同時有 omni_purchase 與 offsite_conversion 的資料測：正確結果是只認一型、不相加。
想確認你的 Meta 串接有沒有踩到歸因視窗縮減或轉換雙算？可以先 [預約免費廣告健檢](/free-audit)，我們用真實帳號核對你的數字口徑。