投放與預算控制產品線
Advantage+ Catalog Ads 與 Dynamic Media 預設啟用
在 v24 之後，Advantage+ Catalog Ads 的 Dynamic Media 行為有一個關鍵改動：media_type_automation 對這類廣告將預設為 OPT_IN。這代表如果商品目錄裡同時有圖片與影片資產，系統會自動幫你選擇、混用含影片的創意組合，以提升投放表現。
過去透過 Marketing API 建立 Advantage+ Catalog Ads 時，Dynamic Media 預設是關閉的，所以很多整合根本沒有顯性設定這個欄位。升級到 v24 之後，如果你「什麼都不改」，新的預設行為就是會用影片，包含 Carousel、Collection 等格式都會被納入。這對依賴靜態圖片創意的廣告主來說，可能會造成預期外的創意呈現，像是商品影片還沒準備好就被拿去投放。
比較好的實務做法，是在 ad creative 結構裡把 Dynamic Media 視為顯性的開關。如果品牌對創意控管很嚴，建議一律在 API 裡設定「要不要啟用」，而不是依賴預設值。若你不想用 Dynamic Media，就在 2025 年 9 月 1 日前明確在程式碼裡 opt out，避免 9 月到 10 月 20 日之間 rollout 完成後才發現創意行為變了。
Daily Budget Flexibility 從 25% 提升到 75%
Meta 對每日預算的使用彈性也有明顯調整。原本系統最多可以在單日多花 25% 的 daily budget，現在提升到最多可以多花 75%。意思是，如果每日預算是 100 單位，遇到效果好的那一天，有可能實際花到 175 單位，但在其他天則會少花一些。
關鍵在於 Meta 把 daily budget 定義成「一週平均」，也就是七天總和不會超過「每日預算乘以七」。如果你的 campaign 長度不到七天，總花費則不會超過每日預算乘以實際天數。對以「長期最佳化」為目標的廣告主來說，這樣的彈性有利於在尖峰轉換日更多吃到流量，但對短期預算非常緊的廣告主，需要教育他們理解「單日」超支是機制設計的一部分，而不是失控。
在實作層面，相關行為會反映在建立與更新 ad sets、campaign 的預算設定上。雖然你不需要在 API 裡做什麼特別設定才有這個彈性，但在報表與預算控管邏輯上，要提醒內部與客戶不要把 daily budget 當成硬性單日上限，而是看「週期總額」是否符合預算規畫。
Ad Set Budget Sharing 最高 20％ 的跨 Ad Set 預算共享
Ad Set Budget Sharing 是 v24 帶來的新預算產品，用來補足「完全手動控管 ad set 預算」與「交給 Advantage+ campaign budget 自動最佳化」之間的中間地帶。
技術上，這個功能透過 is_adset_budget_sharing_enabled 這個 Boolean 欄位控制。如果設定為 true，同一個 campaign 底下各個 ad set 最多可以把自己每日預算的 20％ 挪給同一 campaign 中其他表現更好的 ad set。前提是這個 campaign 並沒有啟用 Advantage+ campaign budget，也就是你仍然是以 ad set 為預算單位。
這個機制很適合那種一方面需要對每個 ad set 有基本預算保證，另一方面又希望系統能根據實際表現稍微幫忙「調整水位」的場景。例如，你有多個不同受眾或地區的 ad set，合約上要求每個 ad set 至少要有一定曝光，但你也希望當某個 ad set 表現特別好時，可以有一點額外預算放大。開啟這個欄位之後，系統就可以在不完全打破原始配置的情況下提供這種彈性。
在 API 設計上，建議不要把這個欄位藏起來，而是讓操作端或設定檔可以明確選擇是否啟用。預設是 false，也就是關閉狀態，如果你的產品策略是「預算多交給系統判斷」，可以考慮在 UI 或 config 中提供一個對應的選項來啟用。
Limited Spend on Placements 排除版位的有限支出
Limited Spend on Placements 則是針對廣告版位控制的新選項。以往如果你想排除某些版位，只能在 placement targeting 裡「完全排除」，系統就絕對不會把預算花在那些位置上。v24 引入 placement_soft_opt_out 之後，你可以為特定版位設定「名義上排除，但允許最多 5% 的預算在表現好的情況下投放」。
這個欄位的結構和現有的 Placements API 相同，包含 facebook_positions、instagram_positions、audience_network_positions、threads_positions、messenger_positions 等子欄位，裡面填入具體位置，例如 rewarded_video、marketplace。系統會把這些位置視為「有限度的排除」，也就是如果機器學習模型判斷這裡有很好的轉換機會，可以在整體預算不超過 5% 的前提下進來投放。
對商品或品牌較敏感的客戶，你可以選擇繼續使用「完全排除」機制，確保廣告不會跑到他們不希望出現的版位。對於較重視績效的客戶，則可以在設定上改用 Limited Spend 模式，讓系統在尊重排除偏好的前提下仍有一點空間去捕捉機會。從產品設計角度，你可以在 UI 上把這兩種模式分開呈現，避免使用者搞不清楚是完全不投還是有限度投放。
Website Destination Optimization 自動最佳化落地頁
Website Destination Optimization 是一個著重在「落地頁選擇」的產品。當你啟用這個功能時，如果同一支廣告對應多個可能的落地頁，例如首頁與特定商品頁，系統會根據歷史表現與預測結果，動態決定實際把使用者導向哪一個 URL，以達到更好的轉換。
在 API 裡，這會透過 ad creative 的 destination_spec 等欄位來控制。當你為同一則廣告提供多個 destination，系統就有機會根據網站目的與使用者行為，選擇最合適的落地頁。這對於大型電商或有多種 funnel 的品牌特別有價值，因為不同族群可能對不同內容反應較好，不需要為每一種落地頁都建立獨立的廣告組合。
技術上，你需要確保 ad creative 在建立時就提供足夠結構化的 destination 資訊，並在查詢 /adcreative-id?fields=destination_spec 時能正確解析狀態。在產品層面，則可以提供一個選項，讓廣告主選擇是否允許系統自動替換預設落地頁。如果品牌對 landing page 控管很嚴，可能就會選擇關閉這個功能。
受眾與精準定位產品線
Lookalike Audience 與 lookalike_spec 型別強制檢查
Lookalike Audience 是用來放大高價值受眾的一個核心產品，Meta 會根據你提供的 seed 受眾與指定的地理區域、相似度範圍等條件，建立一個「與 seed 類似」的大型受眾。這次 v24 的變更，聚焦在 lookalike_spec 欄位的「型別與結構強制檢查」。
以前在 API 裡，有些實作者會用不完全正確的欄位型別或多加一些非文件列出的子欄位，Meta 大多會容忍並幫你轉換。v24 開始，lookalike_spec 必須嚴格符合官方文件中的型別與欄位定義，只要子欄位有不合法的內容或型別錯誤，建立 Lookalike Audience 就會失敗。這個規則先適用於 v24.0 以上版本，並將在 2026 年 1 月 6 日擴展到所有版本。
對工程與產品來說，這代表你需要在建立 lookalike audience 的 UI 或後端驗證中，明確約束使用者的設定同時在錯誤處理上，要把「欄位型別錯誤」轉成友善的錯誤訊息，而不是單純顯示 API 回傳的原始錯誤。建議先根據官方文件寫出一份 lookalike_spec schema，導入 schema 驗證工具，避免錯誤到 production 才被 API 拒絕。
Detailed Targeting Interests 合併與替代
Detailed Targeting Interests 是 Meta 提供給廣告主用來細分興趣、行為與喜好的重要工具。長期下來，平台累積了非常多重複、相近或過於細碎的興趣選項，導致設定與維護成本提高，也增加了系統後端模型管理的複雜度。
從 2025 年 10 月 8 日起，Meta 開始把某些興趣選項合併成比較大的群組。實際行為包含幾個面向。第一，在 Marketing API v24.0 上，部分舊興趣選項不再允許在新建或更新的 campaign 中使用，只要你試圖用它們，就會報錯。第二，當你透過 API 搜尋 interest，例如搜尋「Animal ethics」，系統會回傳新的合併選項「Animal rights」，並且這個新的選項包含原本與其相關的一組興趣。第三，從 2026 年 1 月 6 日起，所有 Marketing API 版本都不再接受被合併前的選項，而在 1 月 15 日後，仍使用這些舊選項的既有 campaign 也會停止投遞。
產品與工程的工作，就是把「舊興趣」與「新合併興趣」之間建立對應表。你可以在後端維護一份 mapping，當發現某個 ad set 或 targeting 設定使用了將被合併的選項時，主動建議使用者改成新的選項，甚至在 UI 端直接提供「一鍵更新」的操作。對於大量歷史 campaign，可以安排批次檢查，產出報表告訴營運團隊哪些廣告在 2026 年 1 月前必須調整，以避免投遞中斷。
Custom Audience 與 Custom Conversion 的敏感內容限制
Custom Audience 和 Custom Conversion 是讓廣告主把自己的第一方資料或自訂轉換行為帶入 Meta 生態系的核心工具。這次 v24 的更新，延續 Meta 在隱私與政策上的要求，針對可能包含敏感資訊的受眾與轉換進行更積極的限制。
從 2025 年 9 月 2 日開始，Meta 會更主動地檢測 Custom Audience 與 Custom Conversion 是否包含不被允許的資訊，例如名稱或條件暗示特定健康狀況，像是「arthritis」或「diabetes」，或是暗示財務狀態，像是「credit score」或「high income」。一旦被判定為不符合條款，這些受眾與轉換會被標記，不能在新的 campaign 中使用，現有 campaign 如果持續依賴它們，也可能在之後被限制投放。
在 API 整合上，你需要思考兩件事。第一，建立或更新受眾、轉換時，要能接住 Meta 回傳的錯誤狀態，並且把它轉成給使用者看的具體引導，例如「這個受眾名稱含有不允許的敏感字詞」或「這個自訂轉換無法再用於新廣告」。第二，在建立或編輯 ad set 時，如果選到已被標記的受眾或轉換，要在操作端給出清楚的提示與替代方案，例如建議重新命名、拆分或改用較高層級的事件。這個更新等於把「合規檢查」搬近到廣告主端，你可以把它視為產品的一部分，而不是純粹的 API 錯誤。
Commerce 與 Catalog 產品線
Product Items Upsert 整合新增與更新流程
在 Commerce 與 Catalog 管理上，v24 帶來一個很實用的能力，就是透過 allow_upsert 讓同一個 endpoint 同時處理「新增與更新」。過去很多系統在同步商品時，會先查詢目錄裡有沒有特定 retailer_id，有就走更新，沒有就走建立，邏輯與 API 呼叫都比較複雜。
現在在 POST /{product-item-id} 時，你可以帶 allow_upsert 參數。預設是 true，表示如果 retailer_id 已存在，就更新那一筆商品，不存在就建立新商品。若你明確設定為 false，而同一個 retailer_id 已存在，這次呼叫就會報錯。這個設計讓開發者可以用一套統一的 upsert 流程處理商品同步邏輯，減少「先查再決定要 call 哪一個 API」的多餘步驟。
從資料一致性的角度，請確保你的系統有明確定義「誰是 retailer_id 的權威來源」，並做好重複與版本控管。對於需要嚴格驗證的場景，例如不希望 API 意外覆寫某些關鍵欄位，你可以選擇在個別情境中把 allow_upsert 設為 false，強制在覆寫前先人工審核或跑額外流程。
Items Batch API 新增 30 MB Request 大小限制
Items Batch API 是一次處理大量 catalog item 的管道，過去僅有「每次最多 5000 筆 items」的數量限制。v24 起在 requests 參數上新增了 30 MB 的 payload 大小限制，目的是避免單次 request 過於龐大，造成錯誤或後端壓力。
對工程來說，如果你原本就是用比較輕量的 JSON 結構，每次傳幾百筆到一兩千筆 item，可能不會明顯感覺到影響。但若你在 item 中塞了大量文字描述、多語系內容或比較複雜的自訂欄位，又習慣一次推滿 5000 筆，就有機會超過 30 MB。最好的做法是先在串接層加入一個簡單的估算邏輯，依 item 平均大小在後端自動拆批，確保每一批的 payload 控制在安全範圍內。
從產品面向來看，可以在後台工具上展示批次同步的分段狀態，讓使用者知道「這次上架 12000 筆商品，被拆成 3 次呼叫」，遇到錯誤時也比較好定位是哪一批資料有問題，而不是整個 request 一次失敗卻不知道是哪一筆。
訊息與 WhatsApp 產品線
WhatsApp Templates Pagination 新錯誤碼與重新啟動分頁流程
對使用 WhatsApp Business API 的開發者而言，GET /<WHATSAPP_BUSINESS_ACCOUNT_ID>/message_templates 是讀取訊息模板的核心 endpoint。v24 增加了一個新的錯誤碼，用於處理「分頁 cursor 過期或無效」的情境。以前即使 cursor 已經失效，有時也只是回傳空結果或模糊的錯誤。
現在的規則是，如果你帶入的 before 或 after cursor 已經無效，API 會明確回傳新的錯誤碼，要求你改用不帶 cursor 的 request 從第一頁重新開始，取得新的分頁資訊。這是一個典型的 breaking change，因為很多現有整合把 cursor 當成可以長期持有的 token。
實作上，你需要在呼叫這個 endpoint 時加入新的錯誤處理邏輯：一旦收到「cursor 無效」的錯誤，就自動重送一個不帶 before、after 的 request，以新的 cursor 為準，並且在本地更新你保存的游標。如果你的系統有持久化儲存 cursor 的機制，要確保也同步更新，避免之後一直踩到同一個錯誤。
WhatsApp Cloud API Message Status Webhook 的 Conversation 物件調整
Message status webhook 用來告知訊息的送達與閱讀狀態，而過去的 payload 會包含一個 conversation 物件，這在舊的「以會話計價」模式下非常重要。隨著 Meta 在 2025 年 7 月 1 日全面改成「以訊息計價」，conversation 物件的意義開始弱化，因此 v24 針對這個欄位做了調整。
在 v24.0 以及更新版本裡，除了「免費 entry point 會話」以外，其他訊息的 webhook payload 不再包含 conversation 物件。對於免費 entry point，conversation 仍然存在，且每個 free entry point 會有自己的唯一 ID。在 v23.0 與更早版本中，conversation_id 的行為也改為「每則訊息唯一」，而不是「每個會話唯一」，同樣在免費 entry point 的情境下仍維持 per conversation 的邏輯。
如果你之前是用 conversation_id 來算 session 或費用，例如一個 conversation 底下有多少則訊息、對應多少成本，現在就需要全面調整。更合理的做法是改用 message ID 以及自己在後端定義的會話邊界，或是只在 free entry point 的情境下使用 Meta 提供的 conversation 物件。這部分會牽涉到 BI 報表、帳務對帳以及 CS 工具的對話串呈現，需要跨團隊共同調整規格。
Click to Messenger Lead Gen Ads API 停用（媽＊F**k）
Click to Messenger Lead Gen Ads 是一種點擊廣告後直接開啟 Messenger 對話並收集名單的廣告格式，過去可透過 Marketing API 建立。v24 宣布停止透過 API 建立這種廣告，僅保留 Ads Manager 的操作能力。
這個改動的實質意義是，第三方行銷工具與自動化平台不能再用程式自動大規模建立 CTMLG 廣告。若你的產品有提供這類功能，就需要調整產品說明與 UI，在相關位置明確註記「僅能透過 Ads Manager 建立」。也可以考慮在產品流程中加入引導，讓使用者在 Ads Manager 的建立流程完成後，回到你的系統綁定已建立的廣告，改為「管理已存在的 CTMLG 廣告」而非「從頭建立」。
Embedded Signup v4 一次完成多產品 Onboarding
Embedded Signup 是讓企業在第三方網站上直接完成 Meta Business Messaging 與廣告產品開通的內嵌註冊流程。v4 的更新重點在於「整合多個產品」，其中包含 Marketing Messages Lite、WhatsApp Cloud API、Click to WhatsApp Ads 以及 Conversions API。
以往這些產品常常需要分別做授權或設定，導致 onboarding 體驗破碎，使用者必須在不同介面與步驟間切換。v4 讓你可以在自己的產品裡嵌入一個比較完整的註冊流程，一次幫企業把上述產品都開通或串接好。對 SaaS 來說，這可以大幅縮短客戶從「註冊」到「真正可以發訊息、投廣告、回傳轉換」之間的時間。
在實作上，你需要閱讀 Embedded Signup v4 的版本說明，依照新的 versioning 規則更新整合，確保使用者在流程中看到的產品選項與最終權杖權限都是一致的。也可以在你的產品介面中，把「開通 WhatsApp Cloud API」「開通 Click to WhatsApp Ads」「啟用 Conversions API」這幾件事視為同一個導入任務，利用 v4 來一次完成。
影音與 Live 產品線
Facebook Video Feeds Placement 被 deprecated 並移除
Facebook video feeds 這個廣告版位在 v24.0 被 deprecated 並實際移除。Meta 會把現有使用這個 placement 的投遞自動轉移到其他相近的版位，以降低影響，但只要你在 v24 上試圖在 ad set 中設定 video feeds placement，就會直接收到錯誤。
這代表你在維護 placement 設定的程式碼或資料結構時，需要主動把 video feeds 從可選項目中移除，避免使用者選到之後才在發佈階段報錯。對 reporting 來說，也要預期未來不會再看到這個 placement 的新流量，只有歷史資料會保留。若你的產品 UI 有依照 placement 顯示表現報表，需要把新流量集中到其他相關的 video 位置上，並在說明文件中更新這項變更。
Live Video API 的 overlay_url 欄位移除
過去 Live Video API 的 GET /<LIVE_VIDEO_ID> response 中有一個 overlay_url 欄位，用來支援與第三方 Live Producer Graphics 產品的整合，透過這個 URL 可以在直播畫面上疊加圖像或圖層。隨著產品路線調整，v24.0 完全移除這個欄位，在 v23.0 及以前版本即便保留，同樣只會回傳 null。
如果你的直播工具或 production pipeline 有依賴 overlay_url 來取得即時圖形層 URL，現在必須改用其他方式，例如自家後端產生 overlay URL 然後透過你自己的前端播放器載入，而不是期待 Meta 提供這個欄位。從長期維護角度，把 overlay 的管理移回自己掌控，會比依靠平台的特定欄位更穩定。
Campaign 結構與 Advantage+ 產品線
ASC 與 AAC API deprecated 與遷移至 Advantage+ 結構
Advantage Shopping Campaigns（ASC）與 Advantage App Campaign（AAC）曾經是為銷售與 App 下載目標設計的「半自動化」 campaign 類型。隨著 Meta 推出更統一的 Advantage+ Campaign Experience，舊的 ASC 與 AAC API 正在逐步 deprecated。
在 v24.0 起，系統不再允許透過舊的 ASC/AAC API 建立新的 campaign。到 v25.0（預計 2026 年第一季）時，這些 API 的「建立功能」會正式移除，舊 campaign 仍可能在一定條件下可編輯，但無法再用舊結構建立新的。Meta 同時提供幾種遷移方式，包含透過 Copies endpoint 搭配 migrate_to_advantage_plus 將 ASC campaign 拷貝並轉成 Advantage+ 結構，或對既有 campaign 發 POST 並帶上 migrate_to_advantage_plus，在保留 campaign ID 的情況下升級結構。
這對第三方工具與大客戶來說是一個結構性改動，需要你先盤點目前有哪些流程還在建立 ASC 或 AAC。接著要決定未來的新 campaign 要怎麼在 UI 裡呈現 Advantage+ 的設定，例如預算控管、受眾設定與創意組合。針對既有的 ASC/AAC campaign，則要規畫一套批次或手動的遷移策略，並在文件中清楚說明哪些 campaign 可以一鍵遷移，哪些因為使用特定功能，例如 existing_customer_budget_percentage 或超過 50 則廣告，必須改用 Ads Manager 複製或重新建立。
開發工具與版本生命週期產品線
Meta Business SDK v24 與 Platform SDK deprecated 計畫
Meta Business SDK v24 會在 Graph API v24 上線後不久釋出，內容包括底層依賴套件升級、新功能支援，以及一些與 Instagram 根節點相關的調整。對開發者來說，這是建議升級的版本，因為它會同步支援這次提到的包含 Dynamic Media 預設啟用、預算彈性提升、Ad Set 預算共享等新功能。
同時，Meta 延續兩年的 SDK deprecated 策略，預計在 2026 年 1 月將 Facebook Platform SDK v18.0 及以下版本標記為 deprecated 並從支援範圍中移除。這意味著如果你還在使用很舊的 SDK 版本，不僅缺乏新功能，之後遇到相容性問題也不會再有正式支援。比較好的做法是先盤點目前各個專案使用的 SDK 版本，制定一個逐步升級到 v24（或未來更新版本）的時間表。
Graph API 版本 deprecated 時程與升級策略
依照 Meta 的版本政策，每個 Graph API 版本都有明確的生命週期。這次公告中特別提到兩個時間點。2026 年 1 月 26 日，Graph API v18 會被 deprecated 並從平台移除。2026 年 5 月 21 日則是 v19 的 deprecated 與移除時間。當一個版本被 deprecated 並正式移除後，所有對該版本的呼叫都會失敗，因此如果你在 URL 中還寫著 /v18.0/ 或 /v19.0/，在這些日期之後就會全面出錯。
建議的策略是，以「永遠往最新穩定版靠攏」為原則，而不是只在版本即將 deprecated 前才一次性升級。你可以設計一個中央設定，讓所有 API 呼叫的版本號可以集中管理，便於切換。每當新的主要版本推出時，先在測試環境針對關鍵功能與新行為做驗證，例如上面提到的 Dynamic Media 預設值、Lookalike 欄位驗證、Interest 合併等，確認無誤後再逐步把 production 的版本號切到新版本。
整體來看 v24 的變更不只是一堆「欄位更新」，而是圍繞幾個產品線做結構性的調整：投放與預算讓系統更有彈性，定位與受眾更強調合規與簡化，Commerce 與 Catalog 更方便維護資料一致性，訊息與 WhatsApp 產品線則調整計價與會話定義，Campaign 結構全面朝 Advantage+ 收斂，開發工具與版本生命週期則推動開發者持續跟上最新能力。開發者可以依照以上各產品線，拆成實作的工程任務、產品路線更新以及對客戶的溝通計畫。
