Seasonality Adjustments: The Right Tool Only for Short, Sharp Events

A seasonality adjustment tells Smart Bidding to expect a temporary conversion rate change and bid accordingly, for a window you set in advance. It is built for a narrow set of short, predictable events, and most of the situations managers reach for it in are better handled with patience, a data exclusion, or no intervention at all. Using it on the wrong kind of change makes the bid strategy worse, not better.

What does a seasonality adjustment actually change inside Smart Bidding?

A seasonality adjustment applies a percentage change to expected conversion rate over a defined date range, and Smart Bidding uses that expectation instead of its own historical model for the duration. It does not touch budgets, targeting, or the bid strategy type. It is a single input, conversion rate expectation, applied on a timer.

This matters because Smart Bidding is already forecasting conversion rate from recent performance. A seasonality adjustment overrides that forecast on purpose, which is only useful when you have a specific reason to believe the historical pattern will not hold. Compare this against how Smart Bidding versus manual bidding normally lets the algorithm learn from live signals without a manual override.

Why is a seasonality adjustment usually the wrong tool?

Most of what managers label a seasonal shift is actually normal week-to-week volatility, a slow trend the bid strategy would catch on its own within a few days, or a change that needs a budget or targeting fix rather than a conversion rate override. Applying a seasonality adjustment to noise tells the algorithm to expect a swing that never really happens, which degrades bidding accuracy right when the account needs it to be stable.

The safer default is to let the bid strategy respond on its own and only intervene once a pattern is confirmed across more than a single data point. If the strategy is still new, check its learning status first, because a strategy still learning will absorb a seasonality adjustment differently than a stable one.

What kind of event is a seasonality adjustment actually built for?

Google's guidance is explicit that this feature is meant for short, sharp events with a known start and end date, typically a few days to two weeks, where conversion rate is expected to move sharply and briefly. A flash sale, a one-day promotion, or a site outage that suppressed conversions are the textbook cases.

• A 48-hour flash sale with a discount steep enough to change buying behavior
• A site or checkout outage that temporarily zeroed out conversions
• A single-day event tied to a specific date, like a product launch

Full detail on setup and the recommended date range limits is in Google's seasonality adjustments help page. Outside of events shaped like these, the feature is being used for something it was not designed to solve.

How does a seasonality adjustment differ from a data exclusion?

A seasonality adjustment changes what Smart Bidding expects going forward. A data exclusion changes what Smart Bidding learns from looking backward, by removing a date range from the historical training data so an anomaly like an outage or a tracking bug does not skew future bidding. They solve opposite problems and are not interchangeable.

If conversions dropped because of a tracking outage, the fix is a data exclusion on that window, not a seasonality adjustment. The data exclusions guide covers when to exclude a range and how long the effect persists in the model, and Google's own data exclusions help page documents which bid strategies support it.

What happens if a seasonality adjustment runs too long?

The feature is not meant to run for more than about two weeks. Left on longer, it stops functioning as a temporary correction and starts acting like a permanent thumb on the scale, which fights the bid strategy's own learning instead of assisting it. If a change in conversion rate is going to last more than two weeks, that is a structural shift the bid strategy should be allowed to learn on its own, not something to keep forcing with an adjustment.

When should a conversion-rate test use an experiment instead?

If the real question is whether a new landing page, offer, or targeting change affects conversion rate on an ongoing basis, that is a controlled comparison, not a seasonality event. Run it as a proper split test so the result is measurable against a holdout, rather than blending it into the bid strategy's expectations. The experiments guide covers how to structure that comparison correctly.

Reserve seasonality adjustments for events with a known, brief start and end date and a real reason to expect a sharp conversion rate swing. For anything longer or less certain, let Smart Bidding learn on its own or use a data exclusion instead.