A seasonality adjustment is a briefing you give Smart Bidding before a short, sharp event: for this defined window, expect conversion rate to move by roughly this much. The algorithm folds that expectation into its auction-time bids from the first hour of the event, instead of spending the first day discovering the shift and the day after the event unlearning it.
It exists because Smart Bidding is a trailing learner. It reacts to evidence, and a two-day sale is over before the evidence accumulates. The adjustment is how you hand the algorithm information it cannot yet have.
How a seasonality adjustment works
You define a scope — campaign types, specific campaigns, devices — a start and end datetime, and the expected conversion-rate change as a percentage, up or down. During the window, bids account for the expected shift; when the window ends, the adjustment expires on its own and, importantly, the algorithm is told to treat the anomaly as explained — the spike does not contaminate its baseline understanding of your account.
The designed use case is narrow on purpose: events of a few days with a conversion-rate change you can predict from experience. A flash sale. A launch. A television moment. The prediction should come from your own history — what the same sale did to conversion rate last time — because the field is a forecast, and forecasts built from wishes mis-bid the entire window.
The misuses are the mirror image. Set an adjustment across a whole quarter and you are double-counting: Smart Bidding already models recurring seasonality — weekends, holidays, annual cycles — so a long adjustment layered on top pushes bids off target and muddies the learning data for months. Stacking an adjustment with simultaneous panic edits to targets and budgets compounds the distortion. And leaving one running past its event is a quiet tax: the algorithm keeps expecting a lift that no longer exists.
Afterwards, two checks: confirm the adjustment expired as scheduled, and compare the conversion-rate shift you predicted with the one that happened. That comparison is the calibration data for your next event.
Deriving the number from your own history
The number is the hard part, and the number is a reading job. An AI agent with account access can pull the prior event's actual conversion-rate shift — sale window versus surrounding baseline, by campaign and device — and hand you the adjustment as a figure derived from your own history rather than a guess. It can run the same comparison after the event, closing the loop: predicted versus observed, and what to enter next time.
The honest division of labour: the analysis is the agent's, the setting is yours. Deriving the number, checking the scope, verifying the expiry, writing the post-event comparison — all of that is exactly the multi-read, one-conclusion work an agent does well. A full pre-event checklist, adjustments included, is worked through in preparing Google Ads for Black Friday with AI — and since sale windows bend spend as well as conversion rate, pair the adjustment with budget pacing checks so the event does not end with an invoice surprise.