Google changed a number in a beta help page last week, and it touches every agency that lets software judge campaign performance. The performance-based cost adjustment for Demand Gen campaigns on target CPA or target ROAS can now stay active for up to 60 days instead of three weeks, as Search Engine Land reported on October 16.
This is not a bidding change. Bidding behaves the way it did. What changed is how long the platform may reach back and rewrite what a campaign cost — and that length of time is the hidden assumption inside most automated reporting, budget reallocation, and anomaly alerting.
What the documentation actually says
For eligible Demand Gen campaigns on tCPA or tROAS, Google may retroactively lower cost when conversions land below what its models predicted during the learning phase, pulling delivery back toward the target. The adjustment activates automatically within five days of campaign start; there is no opt-in. Three details matter if you automate around it:
- No line item. Adjustments appear in final reported cost. There is no separate credit, no invoice entry, and no notification — and reporting can lag up to five days.
- Not guaranteed. Eligibility depends on account age, the authenticity of account activity, conversion-tracking quality, and bidding and budget practices. Meeting the baseline does not mean an adjustment is applied, and it may apply only to certain campaigns or days.
- The docs disagree with themselves. Checked today: the English help page says the adjustment “remains in effect for up to 60 days,” while the UK English version of the same page still says “up to three weeks” (Paid Media Collective flagged the split on October 18). Same canonical page. Two answers.
Three places an automation stack breaks
1. The “settled data” timer. Almost every reporting agent I have seen declares a campaign settled after 14 to 28 days, then starts computing CPA deltas and moving budget on them. Under a 60-day adjustment window, the cost basis of a four-week-old campaign is still provisional. The agent is not wrong about delivery; it is optimizing against a number the platform can still revise.
2. Retroactive rewrites versus cached history. Because the correction is retroactive, a spend figure your pipeline cached last week may no longer match what the API returns today. Agents that alert on “spend changed since last sync” will now fire on legitimate platform adjustments and label them as tracking breakage. Expect false positives for the next two months, then tune the rule rather than the pipeline.
3. Blended benchmarks. Period-over-period and cross-account benchmarks now mix two cost bases: campaigns past their adjustment window and campaigns still inside it. Any agent that scores performance against a trailing-90-day baseline is comparing a settled number to an unsettled one, and the error lands on whichever campaigns are newest — usually the ones a client is most anxious about.
What to change in the workflow
- Store the window as campaign metadata, not as code. Write the campaign start date, bid strategy, and the documentation version and locale you verified into the same record your agents read. When Google changes 60 to something else, you edit a record instead of shipping code.
- Split reporting into provisional and settled cohorts. Days 0 to 60 are provisional for eligible Demand Gen tCPA/tROAS campaigns; everything after is settled. Report both, and never let a provisional cohort drive a cross-client ranking.
- Gate automation on outcomes, not cost deltas. For the first eight weeks, auto-pause and auto-scale rules should read qualified conversions or revenue, not raw cost movement. Cost movement may be Google’s correction, not a change in demand.
- Reconcile monthly, and log the inference. Without a credit line, the only trace of an adjustment is reported cost landing below what delivery implies. Compare cost against expected delivery on a monthly cadence and log the gap as “possible adjustment, unconfirmed” — do not book it as savings.
- Never forecast it. A conditional mechanism is not a discount. Publishing a budget that assumes adjustments will arrive is the fastest way to miss a client’s target and lose the account.
The bigger lesson: platform docs are configuration
The locale split is the useful part of this story. One canonical help page, two durations, both live today. If a human copies a rule into a runbook or a prompt, the number they get depends on which locale their browser resolved. If an agent scrapes the page, it depends on the request header. Either way, nobody notices until a report disagrees with an invoice.
The fix is not more monitoring. It is a small register of platform facts — the rule, the exact wording, the URL, the locale, and the date someone last verified it — that both your prompts and your reporting logic reference. We wrote about the same discipline in AI metadata fact-checking for agency workflows: models and scripts are only as current as the facts you hand them, and a fact without a date is a guess.
Guardrails matter more than ever here. We have argued that agents should not spend before the guardrails are set, and that spend caps belong in your own stack, not only the platform’s. A 60-day retroactive window is the same category of problem: the platform changed the rules of the game quietly, so the automation has to be told the new rules explicitly.
This week’s checklist
- Pull every active Demand Gen campaign on tCPA or tROAS and record launch date and bid strategy.
- Find every hard-coded 14-, 21-, or 28-day settle period in your reporting templates and agent prompts.
- Add “provisional” to the labels on any dashboard a client sees for campaigns under 60 days old.
- Write down which locale of the help page you read, with today’s date, and ask your Google rep to confirm the duration for your accounts.
The practical read: Google just gave its own models a longer leash, and every downstream system that assumed performance goes quiet after three weeks is now working from a stale assumption. If you would rather not audit that by hand, have our team map your paid-media automation against the new adjustment windows and flag the rules that are scoring on unsettled data.