Skip to content

Advertising

Put yesterday's spend in one table

Three ad platforms, three tabs, three definitions of yesterday. The daily number gets assembled by hand each morning, and by the time it exists nobody trusts it enough to act on it. Pulling the figures is the easy half. The half that decides whether the table is worth having is what happens when a platform revises a number you already wrote down.

Triggers
Two
Runs
Twice daily
Stack
5 tools
Durable execution
Not required

The flow

The top track pulls and writes. The bottom track re-reads the same dates later in the day, because the first figure is not the final one.

Orchestration

Early each morning

n8n 排程

Platform

Read yesterday's spend

Meta Marketing API · Google Ads API

Data

Write one row per account

Sheets · Airtable

Orchestration

Again in the afternoon

n8n 排程

Platform

Re-read the last few days

Meta Marketing API · Google Ads API

Orchestration

Figure changed?

n8n IF

Notify

Correct the row and say so

Slack · WhatsApp

Orchestration

Leave the row

Step by step

  1. 01

    Early each morning

    n8n 排程

    One run, after every platform has closed out the day in its own time zone. Set that time once, in writing, or the table quietly means something different each week.

  2. 02

    Read yesterday's spend

    Meta Marketing API · Google Ads API

    One request per platform for the same date range. Record the currency and the account as returned — a converted figure with no record of the rate is a number you cannot audit later.

  3. 03

    Write one row per account

    Sheets · Airtable

    Platform, account, date, spend, and the timestamp of the read. The timestamp is what lets you tell a revised figure from a typo three weeks from now.

  4. 04

    Again in the afternoon

    n8n 排程

    The second pass. It exists because the platforms keep adjusting recent days, and a morning-only pull freezes a figure that was never final.

  5. 05

    Re-read the last few days

    Meta Marketing API · Google Ads API

    Same query, a short trailing window rather than one date. Compare against what the ledger already holds for those days.

  6. 06

    Figure changed?

    n8n IF

    Set a threshold in money, not in percent. A few cents of revision on a small account is noise; the same percentage on your largest account is not.

  7. 07

    Correct the row and say so

    Slack · WhatsApp

    Overwrite the figure, keep the old one beside it, and post both. A number that changes silently is worse than three tabs, because now somebody has quoted it.

What the platform will not allow

The second pass is not caution. It is there because both platforms document that a recently reported figure is still moving.

  • Meta's own guidance on Insights: "Insights refresh every 15 minutes and do not change after 28 days of being reported." A spend figure read at 07:00 is a reading, not a close.

    Meta Marketing API — Insights best practices
  • For anything large, Meta directs you to the asynchronous route — "Async to query for large volume of data to avoid timeouts" — and warns that "/GET or synchronous requests can return out-of-memory or timeout errors". The job handle is not a permanent key: "Do not store the report_run_id for long term use, it expires after 30 days."

    Meta Marketing API — Insights best practices
  • Meta's Insights limit is calculated per ad account, not as a flat quota — on standard access, "Calls within one hour = 600 + 400 * Number of Active ads - 0.001 * User Errors". The X-Business-Use-Case-Usage header returns call_count and estimated_time_to_regain_access, so a workflow can back off instead of hammering.

    Meta Graph API — Rate limiting
  • Google Ads meters daily operations: 15,000 per day on Basic access, where "API operations are the total sum of get requests and mutate operations". A whole report is cheap — "One SearchStream request counts as one API operation irrespective of the number of batches" — but mistakes are not free: "Requests that are rejected with a GoogleAdsFailure still count against the user's daily operation quota."

    Google Ads API — API limits and quotas

When this is not worth building

Three cases where the upkeep costs more than the tab-switching.

  • Nobody makes a decision on the daily number. If the table is read at the end of the month anyway, the platforms' own exports already do this, and a workflow adds a thing that can break.

  • One platform carries almost all the spend. Then the comparison is not the point, and you are building a ledger to hold one meaningful row and two rounding errors.

  • There is no agreed definition of a day. Time zones, account currency, and whether a platform's figure includes fees all have to be settled by a person first. Automating an argument produces a table everyone distrusts, faster.

Related reading

Talk to us

Which of these should you actually build?

We run these flows for Hong Kong operators every week. Tell us the process that is costing you, and we will say whether automating it is worth the upkeep.

Start a conversation