電商搬系統後 ROAS 為什麼會掉？真正的問題是 content_ids 沒有統一規範
但如果 ROAS 下滑的時間點，剛好發生在「電商系統搬家」之後，我會先看一件更底層的事：
你的 content_ids 有沒有延續同一套商品識別邏輯這件事聽起來很技術，但它其實不是單純的追蹤設定問題，而是商品主資料管理問題。
因為對 Meta 這類廣告系統來說，它不是只需要知道「有人來過網站」、「有人加過購物車」、「有人完成購買」。它還需要知道，這個人到底看了哪一個商品、加購了哪一個商品、最後買了哪一個商品。
而讓廣告系統辨識這些商品行為的關鍵，就是事件裡的 content_ids。如果電商搬系統後，ViewContent、AddToCart、Purchase 裡的 content_ids 規則變了，廣告系統眼中就可能不是「同一個商品搬到新網站」，而是「一批全新的商品身分」。
表面上，Pixel 有裝。事件有觸發。訂單有進來。廣告也有繼續投遞，但在演算法眼裡，原本看得懂的商品行為鏈，可能已經斷掉了。這也是為什麼有些電商搬完系統後，廣告設定明明沒有大改，素材也沒有明顯變差，ROAS 卻會從原本的 5、6、7，掉到 4 以下。
真正的問題可能不是廣告變差，而是廣告系統原本認得的商品，突然全部改名了。這，剛好是我們客戶上禮拜才發生的事情。
電商搬系統後 ROAS 下滑，真正該先問什麼？
電商搬系統後 ROAS 下滑，真正該先問的不是「廣告有沒有繼續跑」，而是「content_ids 有沒有延續同一套商品主 ID」。如果 content_ids 沒有固定規範，每一次搬系統、換外掛、接新工具、改事件追蹤方式，都可能讓廣告系統重新認商品，很多團隊在搬站後會先檢查這些事情：
Pixel 有沒有安裝
ViewContent 有沒有觸發
AddToCart 有沒有觸發
Purchase 有沒有觸發
訂單有沒有進來
廣告有沒有正常投遞
網站轉換流程有沒有明顯錯誤
這些當然都要檢查，但更核心的問題是：
你的商品 ID 是由誰定義的？是公司內部的 SKU 定義，還是每個電商平台、廣告平台、外掛工具各自定義？
如果商品 ID 是由平台各自決定，那搬系統後成效震盪幾乎是必然的，因為你不是只有換網站，你是把廣告系統原本認得的商品身分，全部打散重編。
content_ids 到底應該用什麼？最佳解是 ERP 裡的 SKU
content_ids 最佳解，不是讓每個平台自己產生一組看起來可以用的商品 ID，而是回到公司內部穩定的商品主資料。實務上，最好的做法通常是：content_ids 應該跟 ERP 裡的 SKU 相同。
為什麼？因為 SKU 才是零售管理裡最接近「商品身分證」的東西。
電商前台可以換。結帳系統可以換。追蹤工具可以換。廣告平台可以換。資料報表工具也可以換，但只要商品還是同一個商品，SKU 就應該穩定存在。如果你的 content_ids 是跟 ERP 裡的 SKU 對齊，那搬系統時就不會因為新平台重新產生商品 ID，而讓廣告系統誤以為商品全部變成新商品。
比較成熟的資料邏輯應該是：
ERP 裡的 SKU 是商品主 ID
ViewContent 的
content_ids使用同一組 SKUAddToCart 的
content_ids使用同一組 SKUPurchase 的
content_ids使用同一組 SKUGA4 的
item_id盡量使用同一組 SKUCRM、會員系統、報表系統都能對應同一組 SKU
其他商品資料串接，也應該能回到這一組 SKU
這樣，搬系統才只是「平台更換」，不是「商品身分重置」，如果你的商品識別邏輯是平台決定的，那每一次搬家，商品就可能被迫改名，如果你的商品識別邏輯是 SKU 決定的，那平台只是承載資料的容器。
這兩件事的差異非常大。
如果沒有 ERP，也沒有 SKU，問題就不只是廣告追蹤
有些人可能會問：如果我的品牌還沒有 ERP，也沒有很完整的 SKU 規劃呢？
那這件事就不只是廣告追蹤問題了，這代表你的商品管理還停在非常初階的狀態。當然我不是說有了 SKU，品牌就一定會長大；但如果連商品主資料都沒有穩定規則，日後不管要做廣告、報表、庫存、CRM、再行銷、自動化、會員分群，都會開始撞牆。
很多電商長不大，不一定是因為流量不夠，也不一定是因為廣告不會投，有時候是基礎管理本身就是硬傷。
你可以早期用人工方式撐。你可以用表格管理。你可以靠熟悉商品的同事記得每個品項。但只要商品數量增加、通路變多、廣告開始擴大、會員資料開始累積，沒有 SKU 規範這件事就會開始反噬。
常見後果包括：
廣告事件無法穩定對應商品
商品銷售報表無法跨系統合併
庫存資料與廣告資料無法對照
CRM 無法判斷會員買過哪些商品
再行銷名單無法依商品行為精準分群
熱銷商品、滯銷商品、回購商品無法被一致識別
搬系統、換外掛、接新工具時，每次都要重新整理商品資料
所以，content_ids 表面上是廣告事件參數，但背後其實是這間電商有沒有把商品當成一套可被管理、可被追蹤、可被放大的資料資產。
content_ids 沒有統一，為什麼會讓廣告系統看不懂？
content_ids 是網站事件中用來告訴 Meta「這次行為對應到哪一個商品」的商品識別碼。當使用者瀏覽、加購或購買商品時，ViewContent、AddToCart、Purchase 事件中的 content_ids，應該使用同一套穩定商品 ID。
如果這些 ID 對不起來，Meta 就無法正確理解使用者行為與商品之間的關係，動態商品廣告、商品再行銷與演算法優化都可能受到影響。
舉例來說，使用者在網站上看了一件商品，網站會觸發 ViewContent 事件。使用者把商品加入購物車，網站會觸發 AddToCart 事件。使用者最後完成購買，網站會觸發 Purchase 事件。
但這些事件不能只是告訴 Meta：
有人看了商品
有人加購了商品
有人買了商品
它還要告訴 Meta：
這個人看的是哪一個商品
這個人加購的是哪一個商品
這個人最後買的是哪一個商品
這時候 content_ids 就是關鍵。
如果使用者看的是 A 商品，那 ViewContent 事件裡的 content_ids 應該回傳 A 商品的 SKU。
如果使用者加購的是 A 商品，那 AddToCart 事件裡的 content_ids 也應該回傳 A 商品的 SKU。
如果使用者最後買的是 A 商品，那 Purchase 事件裡的 content_ids 也應該回傳 A 商品的 SKU。
這樣廣告系統才有辦法理解一條完整的商品行為路徑：
這個人看過 A 商品
這個人加購過 A 商品
這個人最後購買了 A 商品
A 商品對這類使用者有吸引力
下次遇到類似行為的人，可以優先推這類商品，或拿這些購買訊號去找更可能購買的人
如果這些 ID 對不起來，Meta 看到的就不是一條完整路徑，而是一堆破碎事件。
它可能知道有人看過某個商品、有人加購過某個商品、有人買過某個商品，但它不知道這些事件是不是同一個商品，換句話說，資料不是沒有回傳，而是回傳了，卻不能被理解。
為什麼 Pixel 有觸發，ROAS 還是可能下降？
Pixel 有觸發，只代表事件有被送出，不代表事件裡的商品資料能被 Meta 正確理解。若 content_ids 在不同事件中使用不同商品識別邏輯，Meta 仍然可能無法串起商品瀏覽、加購與購買路徑。
這也是電商搬站後最容易誤判的地方。
很多廠商會說：「我們 Pixel 有裝啊。事件也有觸發啊。Purchase 也有收到啊。」
但問題不在「有沒有」，而在「能不能對得起來」。
例如同一個商品，內部 SKU 應該是 SKU-12345，但不同事件送出的 ID 卻長這樣：
| 使用者行為 | 事件回傳的 content_ids | 正確應對應的 SKU | 問題 |
|---|---|---|---|
| ViewContent | 12345 | SKU-12345 | 商品頁使用平台內部 ID |
| AddToCart | product_12345 | SKU-12345 | 加購事件使用另一套商品 ID |
| Purchase | variant_98765 | SKU-12345 | 購買事件改用規格 ID |
| 內部商品主資料 | SKU-12345 | SKU-12345 | 真正穩定的商品身分沒有被用上 |
這時候，看起來每個事件都有資料，但它們其實講的是不同語言。
對廣告系統來說，12345、product_12345、variant_98765、SKU-12345 很可能不是同一個商品。
所以問題不是「沒有資料」，問題是資料無法被合併、無法被比對、無法被演算法拿來正確學習。
所以請記得三件事情：
有事件，不代表事件有效
有商品 ID，不代表商品 ID 有統一
有 Purchase，不代表廣告系統知道這筆購買到底是哪個商品帶來的
這也是為什麼有些電商團隊會覺得困惑：明明追蹤看起來正常，為什麼廣告成效還是掉？
因為在廣告系統眼裡，追蹤可能只是「有亮」，但不代表「看得懂」。
商品 ID 對不起來，會影響哪些廣告功能？
當 content_ids 沒有統一時，影響的不只是報表數字，還可能影響 Meta 對商品行為的理解能力，也就是說，這不只是歸因問題，也可能變成優化問題。
可能受到影響的功能包括：
動態商品廣告
瀏覽再行銷
加購再行銷
購買者類似受眾
Advantage+ 商品學習
商品組合推薦
高價值商品的投放判斷
商品層級 ROAS 判斷
再行銷排除邏輯
動態商品廣告的核心價值，是把「使用者行為」跟「商品」串起來。使用者看過 A 商品，就再推 A 商品。使用者加購過 B 商品，就提醒他回來買 B 商品。使用者買過 C 商品，就排除 C，或推薦互補商品 D。但這一切都有一個前提：
Meta 必須知道 A、B、C、D 到底是不是同一套商品主資料裡的商品。
如果 content_ids 對不起來，動態商品廣告就會失去最核心的判斷依據，表面上，你還在做商品再行銷。但實際上，系統可能只拿到一堆無法串起來的事件。
這就像你開了一間店，每個店員都有記錄顧客行為，但每個人記商品的方式都不一樣。
有人寫「黑褲」。有人寫「塑身褲」。有人寫「P001」。有人寫「SKU-998」。有人寫「黑色高腰款 M 號」。
最後你要分析哪個商品最容易被瀏覽、哪個商品最容易被加購、哪個商品最容易成交，就會發現資料根本合不起來。
搬系統後最常見的 content_ids 斷裂有哪些？
電商搬系統後，content_ids 最常見的問題，不是完全沒有 ID，而是不同事件開始使用不同規則，常見的斷裂有四種。
一、商品主 ID 跟規格 ID 混用
很多商品會有不同顏色、尺寸、規格。例如同一件塑身褲，可能有黑色、膚色，也可能有 M、L、XL 不同尺寸。在某些電商系統裡，商品本身有一個商品主 ID，每個規格又有自己的 variant ID。
如果商品頁瀏覽事件回傳的是商品主 ID，但加購事件回傳的是 variant ID，購買事件又回傳 SKU，廣告系統就很難把這些行為串起來。
二、新系統重新生成商品 ID
這是搬站時很常見的狀況，商品資料匯入新系統後，新平台可能會重新產生一組商品 ID。
前台看起來商品一樣，商品名稱一樣，商品圖片一樣，甚至商品網址也有做轉址。但對廣告系統來說，如果 content_ids 跟著新平台內部 ID 改掉，它可能就不再被視為原本那個商品。這會導致原本累積的商品瀏覽、加購、購買訊號無法自然延續。
結果就是，商品還在，但商品歷史訊號斷了。
三、外掛或追蹤工具各自產生 ID
有些網站的事件追蹤不是由內部統一規劃，而是由電商平台外掛、GTM 模板、第三方追蹤工具各自處理，這時候就很容易發生：
商品頁事件用平台商品 ID
加購事件用外掛產生的 ID
購買事件用訂單明細裡的規格 ID
CAPI 又用伺服器端另一套欄位
每一個工具都覺得自己有送資料，但整體看起來，資料是碎的。
四、多個系統各自改寫商品 ID
一個成熟電商通常不只接 Meta，它可能同時接 GA4、Google Ads、Google Merchant Center、LINE、CRM、EDM、自動化工具、會員系統、ERP、POS。如果每個系統都使用不同商品 ID 規則，資料就會變成碎片。
常見情況像是：
Meta Pixel 用一套 ID
GA4
item_id用一套 IDCRM 用一套 ID
電商後台用一套 ID
CAPI 用另一套 ID
內部報表又靠人工整理另一套名稱
最後，行銷團隊看到的是同一個商品，工程團隊看到的是不同欄位，廣告系統看到的是無法對齊的事件。
另外還有產品目錄 Product Feed 要不要管？要，但它不是主角
Product Feed 當然要管，但它不是這篇的主角。電商搬系統時，Product Feed 的產生方式本來就可能改變。新平台可能有新的 feed 規則，也可能有不同的欄位結構。所以真正重要的不是「永遠不要動 Product Feed」，而是 Product Feed 應該跟著你的商品主資料走。
也就是說，順序應該是：
先定義公司內部穩定 SKU
再讓
content_ids使用這組 SKU再讓 Product Feed、GA4、CRM、CAPI 等系統盡量對應這組 SKU
Product Feed 是資料輸出的其中一站，不應該反過來成為商品主 ID 的唯一來源。如果你讓平台產生的 feed ID 變成主 ID，搬系統時就很容易被平台綁架。
一換平台，商品身分就換了。
一換工具，追蹤邏輯就斷了。
一換資料來源，報表就接不起來。
所以 Product Feed 可以改，但商品主 ID 不應該隨便改。
商品 ID 對不起來，為什麼會讓 ROAS 真的下降？
商品 ID 對不起來，會同時影響兩件事：第一是報表歸因，第二是演算法優化。前者會讓 ROAS 看起來變差，後者則可能讓廣告實際投放能力也變差，這兩件事不完全一樣，但常常會同時發生。
一、報表歸因會變差
如果 Purchase 事件雖然有回傳，但商品 ID、事件參數、使用者識別資料不完整，Meta 能辨識與歸因的轉換就可能變少。這時候，電商後台可能仍然看得到訂單，但 Meta 廣告後台看不到完整轉換。
所以你會看到一種落差：
電商後台營收沒有掉那麼多
Meta 後台 ROAS 掉很多
GA4、電商後台、Meta 後台數字開始對不起來
廣告投手以為素材變差，但其實是歸因資料斷裂
這不一定代表廣告完全失效，也可能代表 Meta 能歸因、能理解、能串接的資料變少了。
二、演算法優化會變差
更麻煩的是，Meta 不是只拿事件來做報表，它也拿事件來優化投放。如果商品事件變得破碎，Meta 對使用者商品興趣、加購傾向、購買行為、商品組合的理解都會變差。這會直接影響動態商品廣告、商品再行銷、購買者類似受眾、Advantage+ 商品學習，以及高價值商品的投放判斷。
所以這不是單純「報表變醜」而已，更嚴重的是，演算法真的可能開始找錯人，因為它原本用來學習的商品行為路徑，斷掉了。
電商搬系統後，應該怎麼檢查 content_ids 是否一致？
如果電商剛搬完系統，廣告 ROAS 就開始下滑，應該先做一份「商品事件 ID 檢查」。不是只看 Pixel Helper。也不是只問廠商事件有沒有裝。而是要直接檢查每個事件送出的 content_ids 是否使用同一套商品主 ID。
建議依照以下順序檢查：
先確認公司內部商品 SKU 規則
確認舊系統事件原本送出的
content_ids確認新系統 ViewContent 事件回傳的
content_ids確認新系統 AddToCart 事件回傳的
content_ids確認新系統 Purchase 事件回傳的
content_ids確認 Pixel 與 CAPI 是否送出同一套商品 ID
確認 GA4
item_id是否能對應同一組 SKU確認商品目錄與其他廣告串接是否能對應同一組 SKU
可以用這張表檢查：
| 檢查項目 | 正確狀態 | 常見錯誤 |
|---|---|---|
| 內部 SKU | 有穩定、可延續的商品主 ID | 沒有 SKU，或每個平台各自命名 |
ViewContent content_ids | 使用內部 SKU | 使用新平台商品 ID |
AddToCart content_ids | 使用同一組 SKU | 改用 variant ID 或外掛 ID |
Purchase content_ids | 回傳商品 SKU | 回傳訂單 ID、活動 ID 或內部流水號 |
| Pixel / CAPI | 兩邊商品 ID 一致 | 瀏覽器端與伺服器端送不同商品 ID |
GA4 item_id | 能對應同一組 SKU | 和 Meta 使用完全不同欄位 |
| CRM 商品欄位 | 能對應同一組 SKU | 只能看商品名稱，無穩定 ID |
| 商品目錄 | 能對應 SKU | 吃到平台重新產生的 ID，且無 mapping |
這些檢查才是真正能判斷「廣告系統是否看得懂商品資料」的重點，如果只是確認事件有沒有亮，很容易錯過資料結構已經斷掉的事實。
搬系統前應該怎麼做 SKU 與 content_ids 規劃？
電商搬系統前，不只要做 URL Redirect，也要做 SKU 與 content_ids 的規劃。URL Redirect 是給搜尋引擎與使用者看的，content_ids 規劃則是給廣告系統、分析系統與資料系統看的。
很多電商搬站時，非常重視 URL Redirect，舊網址要轉到新網址。SEO 權重要銜接。搜尋流量不要斷。使用者不要進到 404 頁面。但對廣告系統來說，只有 URL Redirect 不夠，還要確認商品 ID 的延續性。搬站前應該先完成這些事：
盤點舊系統商品 ID
盤點 ERP 或內部 SKU
確認哪些商品沒有 SKU
補齊商品 SKU 規則
確認 ViewContent 要送哪個 SKU
確認 AddToCart 要送哪個 SKU
確認 Purchase 要送哪個 SKU
確認 Pixel 與 CAPI 使用同一套 SKU
確認 GA4
item_id是否能對應 SKU建立舊 ID、新 ID、SKU 的對照表
這些事情如果搬站前沒有規劃，搬完後才補，通常會很痛，因為你不是在修一個小參數。你是在重新整理商品資料、事件資料、廣告追蹤、報表系統、會員資料之間的共同語言。
這件事對行銷人的啟示是什麼？
這個案例最值得提醒行銷團隊的一點是：現在的廣告優化，已經不只是操作後台，而是管理資料結構。過去談廣告優化，大家很容易集中在素材、受眾、預算、出價、版位、活動目標。
這些當然還是重要，但在演算法投放越來越依賴事件資料的情況下，底層資料結構會直接影響廣告系統能不能穩定學習。
行銷團隊至少要能意識到這些問題：
商品有沒有穩定 SKU
事件有沒有正確回傳
事件參數有沒有完整
content_ids是否使用同一套商品主 IDPixel 與 CAPI 商品參數是否一致
value 和 currency 有沒有正確
商品資料是否能跨系統對應
會員識別與購買行為能不能延續
搬站後商品歷史訊號是否被切斷
這些看起來像技術問題，但最後都會反映在廣告成效上，如果這些事情沒處理好，投手再怎麼調素材、調受眾、調預算，都像是在一個失憶的系統裡反覆做實驗。
你以為你在優化廣告。其實你只是在餵演算法一堆斷裂訊號。
電商搬系統最可怕的不是網站換了，而是商品身分被重置了
電商搬系統後 ROAS 下滑，不一定代表廣告投放能力變差。更有可能是搬站後，content_ids 的商品識別規則沒有延續，導致 Meta 原本累積的商品行為資料無法自然接上。
簡單說，廣告系統不是沒收到資料，而是看不懂資料。
它看不懂這個人看過哪個商品。看不懂這個人加購過哪個商品。看不懂這筆購買到底對應哪個商品。也看不懂搬站前後的商品到底是不是同一個。所以搬站後 ROAS 掉，不要急著先罵廣告，也不要急著重做素材。
先問一個更底層的問題：
你搬過去的，到底只是網站？還是連廣告系統看得懂的商品身分，也一起搬過去了？
電商搬系統真正該檢查的，不只是 Pixel 有沒有亮，也不是 Purchase 有沒有觸發。
而是這幾件事能不能對起來：
ERP 或內部 SKU
ViewContent 的
content_idsAddToCart 的
content_idsPurchase 的
content_idsPixel 與 CAPI 的商品參數
GA4 的
item_idCRM 與會員系統裡的商品欄位
商品目錄與其他廣告串接資料
如果對不起來，Meta 看到的就不是完整的商品行為路徑，而是一堆無法串接的資料碎片，這時候 ROAS 掉下來，不是玄學。不是單純演算法震盪。也不只是廣告素材不夠好，而是你的廣告系統，真的看不懂你在賣什麼了。
常見問題 FAQ
電商搬系統後 ROAS 掉，一定是 content_ids 的問題嗎？
不一定。ROAS 下滑仍可能與素材疲乏、網站轉換率、付款流程、追蹤漏失、CAPI 設定或市場淡旺季有關。但如果 ROAS 下滑時間點明確發生在搬站後，content_ids 是否延續同一套商品主 ID，應該被列為優先檢查項目。
Pixel 有觸發，為什麼還要檢查 content_ids？
因為 Pixel 有觸發，只代表事件被送出，不代表事件裡的商品資料能被 Meta 正確理解。若 ViewContent、AddToCart、Purchase 使用不同 content_ids 規則，Meta 仍可能無法串起商品瀏覽、加購與購買路徑。
content_ids 應該使用商品 ID、SKU，還是 variant ID？
實務上，最佳解通常是使用 ERP 或內部商品主資料中的 SKU。重點不是某個名稱一定叫 SKU，而是它必須是一組穩定、可延續、跨系統可對應的商品識別碼。最糟糕的不是選錯某一種 ID，而是不同事件各用各的 ID。
沒有 ERP，也沒有 SKU，可以做廣告追蹤嗎？
可以做，但會有長期風險。早期商品少時，可能靠平台商品 ID 或人工管理還撐得住；但商品數量增加、通路變多、廣告規模放大後，沒有穩定 SKU 會讓報表、庫存、CRM、再行銷與廣告事件追蹤越來越難整合。
Product Feed 在這件事裡重要嗎？
重要，但它不是主角。Product Feed 應該跟著公司內部商品主資料走，而不是反過來決定商品主 ID。真正該優先確認的是 content_ids 是否使用穩定 SKU，接著才是其他商品資料輸出是否能對應同一套 SKU。
搬站前只做 URL Redirect 夠嗎？
不夠。URL Redirect 主要是讓使用者與搜尋引擎能從舊網址到新網址，但它不會自動解決廣告系統的商品身分延續問題。電商搬站除了 URL Redirect，也應該規劃 SKU 與 content_ids，確保商品行為資料能延續。
.jpeg)
留言
張貼留言