Build the normal bands that make alerts meaningful
Baselines computed from history: spend, CPA and volume bands per account, the prerequisite for every alert.
IntentWhat 'normal' is, per account and metric, so deviations mean something.
- 2
- Steps
- 4
- Tools
- 1
- Rules
- 1
- Failure modes
When to use it
Use it when
- Before setting up monitoring.
- Quarterly baseline refreshes.
Do not use it when
- Accounts younger than a quarter: bands from a month are guesses.
What it needs first
No single source is required: this one reads across whatever you have connected.
Preconditions
- The account is ticked in the dashboard, confirmed via list_accounts.
Inputs
window- Analysis window.Default: last 30 days.
Procedure
In order. Every tool named is one the gateway ships, and links to its reference.
Pull 90 days of daily figures per platform.
Compute weekday-aware bands per metric and write them down.
Decision rules
The observable condition, what it lets you conclude, and what takes the conclusion back.
When
A metric's variance makes bands uselessly wide
Conclude
Alert on that metric's drivers instead: wide bands are a finding about the metric, not a failure of the method.
Evidence every conclusion must carry
- Every figure carries its account, metric and window.
- Anything below a readable sample size is reported as unjudged, not as zero.
Where the agent stops
- The readout changes nothing. Any change it motivates goes through Safe Writes: preview, human confirmation, then apply.
How it goes wrong quietly
The cases where the analysis is wrong and still looks right. Read them before trusting a number.
- Bands built across a promo period normalise the promo: exclude or annotate exceptional windows.
What the answer contains
- 01Readout
- The figures, with windows and accounts named.
- 02Flags
- What deserves a deeper skill or a human decision.