廣告投放
商品被拒登，當日就要有人知道
一件商品被目錄拒登，沒有任何通知。那件貨的銷售就這樣停了，而原因要兩個星期後、有人終於打開診斷頁面才浮面。兩個平台其實都已經用 API 公開了這個拒登結果。缺的不是資料，而是一個定時去讀、並且把受影響貨號送到修得到那個人面前的流程。
- 觸發
- 兩個
- 執行頻率
- 每日一次
- 工具
- 4 件
- 需要 durable execution
- 不需要
流程
上面那條接住上載時就失敗的，下面那條接住上載之後、在處理階段才失敗的——而商品實際上有沒有下架，只有後者知道。
輪詢上載結果
n8n 排程
取回該次的錯誤
Meta Marketing API
每件商品記一行
Sheets · Airtable
每朝一次
n8n 排程
讀取商品狀態
Google Merchant API
是否真的被擋？
n8n IF
把貨號發出去
Slack · WhatsApp
只記錄
—
逐步拆解
- 01
輪詢上載結果
n8n 排程Meta 沒有為上載完成發出通知，所以這一邊是定時去問：讀取上載紀錄，找出剛完成的那一次。每次上載都有自己的編號，所以同一次的錯誤可以整批讀出來。
- 02
取回該次的錯誤
Meta Marketing API向剛才那次上載索取錯誤報告。致命錯誤同警告要分開處理——把警告當成拒登，只會教識同事無視這條通知。
- 03
每件商品記一行
Sheets · Airtable貨號、出問題的欄位、錯誤原文、日期。同一個貨號一星期又一星期地出現，才是真正值得處理的訊號，而只有紀錄看得出這件事。
- 04
每朝一次
n8n 排程刻意排在上載之後一段時間，因為「上載成功」同「商品獲批」是兩回事。這個流程要處理的，正正是兩者之間那段空隙。
- 05
讀取商品狀態
Google Merchant API取回每件商品處理後的狀態，包括問題本身，以及受影響的曝光位置。這個讀數反映的是平台現時手上那一份，而不是你送出去那一份。
- 06
是否真的被擋？
n8n IF篩選的條件是「商品有沒有被阻止顯示」，而不是「有沒有問題」。大部分目錄都長期帶著一堆警告，照單通知就是一條通知頻道死亡的方式。
- 07
把貨號發出去
Slack · WhatsApp寫明是哪幾件貨、哪一個欄位出錯、影響哪個曝光位置。一句「有商品被拒登」只會逼對方再入後台查一次，而那正是你想省掉的工序。
平台不容許的事
為什麼要用排程去查，而不是上載一完就查——兩個平台的文件都寫明了原因。
Google 講得很白：商品不是你一送出就有裁決——「There is a delay, typically a few minutes, between when a productInput is inserted or updated and when the changes are reflected in the final processed product.」上載一完就檢查，查的是錯的那一份。
Merchant API — List your products data and product issues處理後的紀錄同時帶著 destinationStatuses——「an array indicating the approval status of the product for each destination」——以及 itemLevelIssues，而「each issue includes a description, severity, the affected attribute, and documentation to help you resolve it」。令通知可以直接動手的，正是那個出錯欄位，而它本來就在回應裡面。
Merchant API — List your products data and product issues不是每個問題都會令商品下架。Google 的 servability 欄位分開「disapproved: The problem prevents the product from being shown」同「unaffected: The product is still shown」，另有一個 resolution 欄位「informs if the merchant can solve the issue」。兩類都通知，就是把頻道靜音的做法。
Content API for Shopping — Product statuses在 Meta，排程商品檔不可能是你的快線：「Scheduled feeds do not support uploads more frequently than once per hour.」靠重新上載商品檔去修正，速度由這條上限決定，跟你的流程跑得多密無關。
Meta Marketing API — Catalog Feed API referenceMeta 不會在商品檔上載完成時發出通知，上載紀錄要靠列出來查，所以這一邊的第一個節點是排程，不是平台推送。
Marketing API — Product Feed UploadMeta 把該次上載本身的失敗做成一份可以取回的文件——「an error report about your data feed uploads, with warning errors and fatal errors highlighted」——上面那條軌道才可以一次讀完整個上載，而不用去後台逐頁抄。
Meta Marketing API — Product Feed Upload error report
什麼情況不值得做
以下三種情況，維護成本會高於靜默拒登的代價。
目錄小到用眼睛看得完。三十件貨，加每星期看一次診斷頁面，勝過一個流程，因為你會比通知更早發現少了那件貨。
沒有人改得到源頭資料。如果商品檔由一個你控制不到的系統產生，通知只會指出一個永遠改不到的欄位，每日一封變成一份無能為力的紀錄。
你的商品檔本身長期帶著一堆沒有人清過的警告。在這個底上建通知，每次都在報同一批舊帳；未捉到新問題之前，已經教識所有人不看它。