How sync works
The warehouse model, freshness warnings, and why changes made in Apple's UI are invisible until re-synced.
Tap & Scale reads from a warehouse, not from Apple in real time. A background worker keeps the warehouse current, and every strategic read is measured against how fresh that data is.
The sync model
Apple has no webhooks and no change-events API, so sync is a scheduled pull:
- Nightly full pull — a 14-day backfill across all dimensions (campaigns, ad groups, keywords, search terms, ads) and their daily metrics.
- Six-hourly incremental — all dimensions plus yesterday's and today's campaign facts.
Metrics are stored in micros. Apple soft-deletes, so removed entities are flagged deleted rather
than dropped, which keeps history intact.
Freshness
Strategic reads return a dataFreshness signal, and reads warn when data is older than 24 hours.
Before you act on numbers — or let the copilot act — confirm the latest sync succeeded:
- App: the sync status indicator on the account.
- MCP:
asa_get_sync_status; if the latest run failed or data is stale,asa_trigger_sync, wait, then re-read.
Don't act on stale or thin-history numbers. A keyword with two days of data isn't proven either way — the freshness warning covers both cases.
Why UI edits are invisible
Because there is no change-events API, edits you make directly in the Apple Search Ads UI are invisible here until the next sync re-reads that state. There is no way to reconstruct who changed what in Apple.
That's also why the app keeps its own ledger. The History page (and
asa_list_action_history) records the what / when / why / who / result of every change this app
made — not a mirror of Apple's account history, which doesn't exist. Reverts work only because each
write snapshots its own prior state.