廣告投放
把昨日花費併成一張表
三個廣告平台，三個分頁，三種對「昨日」的定義。每朝要人手併一次，併好之後又沒有人夠信心用它來做決定。取數本身是容易的一半。決定這張表值不值得存在的，是平台改動了你已經寫落去的數字之後，你怎樣處理。
- 觸發
- 兩個
- 執行頻率
- 每日兩次
- 工具
- 5 件
- 需要 durable execution
- 不需要
流程
上面那條負責取數同寫入，下面那條在同一日稍後重讀同樣的日期，因為第一次讀到的數並非最終數。
每朝一早
n8n 排程
讀取昨日花費
Meta Marketing API · Google Ads API
每個帳戶寫一行
Sheets · Airtable
下午再跑一次
n8n 排程
重讀最近幾日
Meta Marketing API · Google Ads API
數字有改動？
n8n IF
改正該行，並且講出來
Slack · WhatsApp
維持原行
—
逐步拆解
- 01
每朝一早
n8n 排程跑一次，時間要等所有平台按各自時區收完一日。這個時間要白紙黑字定一次，否則這張表每星期的意思都會悄悄變過。
- 02
讀取昨日花費
Meta Marketing API · Google Ads API每個平台一次請求，用同一段日期。幣值同帳戶按 API 回傳原樣記低——換算過而沒有記低匯率的數字，日後查不到源頭。
- 03
每個帳戶寫一行
Sheets · Airtable平台、帳戶、日期、花費，以及讀取的時間戳。三個星期之後，靠這個時間戳才分得出哪些是平台改過的數，哪些是有人打錯。
- 04
下午再跑一次
n8n 排程第二輪。它存在的原因是平台會持續修訂近幾日的數字；只跑早上那次，等於把一個從未定案的數字凍結了。
- 05
重讀最近幾日
Meta Marketing API · Google Ads API同一條查詢，但取一段短的往回窗口，而不是單一日期。取回之後，跟表上已有的那幾日比對。
- 06
數字有改動？
n8n IF門檻用金額定，不要用百分比。小帳戶改幾毫是雜訊；同樣的百分比落在最大那個帳戶身上就不是。
- 07
改正該行，並且講出來
Slack · WhatsApp覆寫數字，把舊數留在旁邊，兩個一齊出。一個靜靜改過的數字，比三個分頁更差，因為已經有人引用過它。
平台不容許的事
第二輪不是謹慎。它存在，是因為兩個平台的文件都寫明：剛回報的數字仍然會動。
Meta 對 Insights 的說明是：「Insights refresh every 15 minutes and do not change after 28 days of being reported.」早上七點讀到的花費，是一次讀數，不是結算。
Meta Marketing API — Insights best practices數據量大的話，Meta 叫你行非同步那條路——「Async to query for large volume of data to avoid timeouts」——並且警告「/GET or synchronous requests can return out-of-memory or timeout errors」。那個工作編號亦不是長期鎖匙：「Do not store the report_run_id for long term use, it expires after 30 days.」
Meta Marketing API — Insights best practicesMeta 的 Insights 上限按廣告帳戶計算，不是一個固定額度；standard access 之下是「Calls within one hour = 600 + 400 * Number of Active ads - 0.001 * User Errors」。X-Business-Use-Case-Usage 這個 header 會回傳 call_count 同 estimated_time_to_regain_access，流程可以據此退讓，而不是硬撞。
Meta Graph API — Rate limitingGoogle Ads 計的是每日操作次數：Basic access 每日 15,000 次，而「API operations are the total sum of get requests and mutate operations」。整份報表本身很便宜——「One SearchStream request counts as one API operation irrespective of the number of batches」——但出錯不會免費：「Requests that are rejected with a GoogleAdsFailure still count against the user's daily operation quota.」
Google Ads API — API limits and quotas
什麼情況不值得做
以下三種情況，維護成本會高於每朝換分頁的代價。
沒有人會因為這個每日數字而做決定。如果那張表反正到月尾才有人看，平台自己的匯出已經做到同樣的事，多做一個流程只是多一件會壞的東西。
花費集中在單一平台。那樣「跨平台比較」根本不是重點，你在建一張只有一行有意義、另外兩行是零頭的表。
「一日」的定義未有共識。時區、帳戶幣值、平台的數字有沒有計手續費，這些要先由人拍板。把一場爭論自動化，只會更快地產出一張人人都不信的表。