資料與報表
廣告命名先審，報表才靠得住
沒有人會刻意用一個文字欄位去支撐報表。事情通常倒過來發生：先講好一套命名規則，然後趕著開幾個廣告系列，半年之後，儀表板正在用一串字元的第三段來分組花費，而那一段有四個人寫出四種寫法。這種稽核便宜又沉悶。省掉它的代價會在後面才出現，形式是一份看起來很肯定、但其實錯了的報表。
- 觸發
- 兩個
- 執行頻率
- 每晚一次
- 工具
- 5 件
- 需要 durable execution
- 不需要
流程
上面那條存放規則和現有名稱。下面那條在夜間醒來，把每個名稱按規則拆開，分出報表可以安全分組的，和必須有人改名的。
先議定命名規則
Manual
把規則存成一張表
Sheets · Airtable
取回所有現有名稱
n8n · Make
每晚一次
n8n 排程
模型把名稱拆成欄位
OpenAI · Anthropic
是否符合命名規則？
n8n IF
寫入報表用來分組的標籤
Google Ads API
把不合規的交回負責人
Slack · WhatsApp
逐步拆解
- 01
先議定命名規則
Manual在把檢查自動化之前先寫下來：有哪幾段、次序如何、用什麼符號分隔，以及每一段容許的值清單。只存在於某個人腦中的規則，無法用來稽核。
- 02
把規則存成一張表
Sheets · Airtable一段一行，附上容許的值。把規則存成資料，而不是寫死成流程裡的一條正規表達式，市場同事下一季要新增一個地區時，就不必打開自動化流程。
- 03
取回所有現有名稱
n8n · Make把每個要出報表的帳戶的名稱集中成一份清單。已暫停的系列也要包括在內——上一季的花費仍然在報表裡，所以上一季的名稱仍然要拆得開。
- 04
每晚一次
n8n 排程選每晚，是因為昂貴的情況是一個名稱錯了幾個星期。在開設後翌日早上發現，和幾個月後才發現，分別在於改一個名，還是重做一份報表。
- 05
模型把名稱拆成欄位
OpenAI · Anthropic本來就合規的名稱，直接切分就處理得到；模型是為不合規那批而設——它把「HK_BF_2026」和「hongkong-blackfriday」對應到同一組欄位。它只做分類和抽取，不會計算任何花費，也不會創造容許清單以外的值。
- 06
是否符合命名規則？
n8n IF每一段都要在，每一個值都要在容許清單之內。這裡沒有「部分合格」可言——五段之中拆得出四段的名稱，一樣會令它本來要支撐的分組失效。
- 07
寫入報表用來分組的標籤
Google Ads API真正撐得住的不是名稱。把同一組欄位寫成標籤，再讓儀表板按標籤編號分組。之後改名不會有任何代價，因為下游本來就不是在讀那串字。
- 08
把不合規的交回負責人
Slack · WhatsApp寫明是哪一個系列、哪一段不合格、正確的值應該是什麼。一份只列出錯誤名稱、沒有建議改法的清單，看一次之後就不會有人跟進。
平台不容許的事
頭兩項界定標籤這條路可以走多遠；第三項界定你可以用多快的速度讀規則表和寫回稽核結果。
標籤是報表的正式維度，不是權宜之計：帶標籤的系列透過 campaign_label 資源查詢，而文件寫明「You can filter these report results by comparing the label.id field using any numeric comparison operator or the BETWEEN, IS NULL, IS NOT NULL, IN, or NOT IN operators.」按標籤編號分組屬於官方支援，按名稱的某一段分組則從來不是。
Google Ads API — LabelsGoogle Ads 的上限是單一實體最多套用 50 個標籤，每個帳戶最多套用 100,000 個。一個報表維度一個標籤，空間十分充裕；但每個廣告系列造一個新標籤的做法就不然，會在有人察覺之前先撞上帳戶上限。
Google Ads API — System limitsSheets 每個專案每分鐘容許 300 次讀取和 300 次寫入，每個使用者每分鐘 60 次；配額每分鐘重新補滿，之上沒有每日上限。逐行寫回結果的稽核，正是把每使用者那個數字用光的做法。
Google Sheets API — Usage limits
什麼情況不值得做
以下三種情況，維護成本會高於命名混亂的代價。
所有廣告系列由同一個人開設，而且沒有任何報表按名稱分組。規則正由最可靠的機制維持著——同一雙手；稽核在這件事上加不到什麼。
命名規則本身還未議定。在未定的規則上稽核，只會每晚產出一份人人有異議的違規清單，流程就變成一場定時上演的爭論。
名稱早已一團糟，而且沒有人會回頭補做。檢查程式對著一堆舊名稱，每晚回報同樣那幾百項失敗，直到沒有人再看為止；一份被靜音的報告，比沒有做更差。