How to review a bid or budget change before you make it

Before recommending any target-CPA, target-ROAS, or budget change, pull the platform's own forecast for that exact change first: Google's campaign and ad-group simulators, or the impact estimate attached to a bid/budget recommendation. State what the platform predicts, and either accept it or give a specific reason to reject it.

This sounds obvious, but it's the step most commissioned recommendations skip in favor of pattern-matching from what worked on a different account. "We didn't check the simulator" is not a defensible state for a bid change on money that isn't yours.

The number that actually determines whether a change was worth making is the marginal cost of the delta: the extra spend divided by the extra conversions the change produced, not the new average cost-per-result. Average CPA after a budget increase will almost always look fine, since it blends the cheap conversions you were already getting with the expensive ones the extra budget bought. The marginal cost is where the money actually went, and it's the number that should be compared against a client's real per-conversion ceiling.

A platform simulator's current-state point (the anchor) is usually well calibrated once you've verified it against actuals. Its projected slope, how response is predicted to change as you move the bid, deserves much less trust, especially for anything not already bidding competitively.

In low-bid regimes where a bid increase crosses a page-eligibility threshold, we've seen simulators underpredict the real jump in response by four to five times on accounts we manage; the simulator's linear-looking curve badly understates a genuine step-change in auction eligibility. And a low-bid manual campaign's response curve tells you nothing about a competitive smart-bidding campaign elsewhere in the same account; bid elasticity does not transfer across bidding regimes, even within one advertiser.

Any bid-target change of roughly 20% or more on a campaign that matters should run as a platform-native 50/50 experiment (search-based split, at least 14 measured days, with rollout and kill rules written and agreed before the experiment launches), not as a full-campaign change made on a hunch. Compare arms using platform-counted conversions on both sides; any attribution inflation in the platform's counting methodology cancels out between arms, so the relative read stays clean even when the absolute counts aren't perfectly accurate.

Snapshot the platform's forecast at the moment you act on it, for every change, and adjudicate the actual result against that snapshot afterwards. Over enough changes this produces a real, account-specific calibration factor on how much to trust that platform's forecasts on that account, which is a far better prior than trusting the simulator equally everywhere.

Before calling any conversion-rate movement a drop, a win, or an anomaly, place the comparison point on the account's actual demand curve: was it a seasonal peak, a trough, or a genuine baseline? We've seen headline conversion rates presented internally as "the normal level" that, once checked against a full year of data, turned out to be a spring seasonal peak, with the honest year-round baseline sitting a meaningful amount lower. Charts shown to a client need to extend far enough back to make that reference point's position visible, because if they don't, the client will extend the axis themselves eventually, and find the framing error before you do.

A platform's own recommendation panel (budget raises, broad-match suggestions, automated opt-ins) is a hypothesis ranked by claimed marginal cost, produced by a system with an incentive to grow spend, not evidence of what will actually happen on your account. It earns a real test only after you've decomposed which specific conversion actions it's counting and whether they represent real value, and it never skips the same approval gate every other change goes through.