Seasonal bid adjustments with machine learning 2026: Smart Bidding seasonality tools

Seasonality is the single most misunderstood input to Smart Bidding. Practitioners reach for manual bid levers around sales, holidays, and launches out of habit carried over from the manual-CPC era — but modern Smart Bidding models already ingest day-of-week, time-of-day, and year-over-year conversion-rate patterns, and they adapt daily as fresh conversion data arrives. The result is that most seasonality interventions in 2026 are not just unnecessary, they are actively harmful, because they double-count seasonality the algorithm has already priced in or over-state a conversion-rate lift that never materialises.

This guide draws the precise line between the two purpose-built tools Google provides — seasonality adjustments and data exclusions — and shows when each is correct, when neither is, and how to configure them surgically. If you are still deciding between bidding strategies in the first place, start with our companion pieces on Maximize Conversions vs Target CPA and when to use manual CPC vs Smart Bidding. This is the advanced layer that sits on top of a chosen strategy.

How Smart Bidding handles seasonality automatically

Before discussing manual tools, you have to understand what the system already does — because everything downstream depends on not duplicating that work.

Smart Bidding's models predict conversion rate and conversion value for each auction, in real time, using a large set of contextual signals: query, device, location, time of day, day of week, browser, language, audience signals, and historical performance patterns. Crucially, the time-based signals are not static. The models continuously fit recurring temporal patterns from your account's own history and from broader Google-wide patterns in your vertical.

What this means in practice — the system already anticipates:

• Day-of-week patterns: B2B accounts converting better Tuesday-Thursday, e-commerce peaking on weekends, the system learns and bids accordingly without instruction.
• Time-of-day patterns: lunchtime mobile spikes, evening desktop conversion windows — priced into bids automatically.
• End-of-month / end-of-quarter effects: common in B2B where buyers close before period-end; Smart Bidding fits this from history.
• Recurring annual holidays: Black Friday, Christmas, back-to-school — for any holiday the account has 1-2 years of data on, the model already knows the conversion-rate profile.
• Gradual seasonal ramps: the slow build into a peak season and the taper afterward; because conversion data arrives daily, the model tracks the ramp continuously.

The key property is daily adaptation. Smart Bidding does not set a bid in January and hold it. It re-evaluates constantly, so a gradually rising conversion rate through November is something it follows in near-real-time. This is precisely why long, gradual seasons need no manual seasonality adjustment — the algorithm is already doing the adapting, day by day.

Where the automatic system has a genuine blind spot: sudden, short, high-magnitude conversion-rate changes that have no historical precedent. The model adapts based on observed data, which creates an inherent lag. If your conversion rate triples for 48 hours during a flash sale you have never run before, the model only 'sees' that spike after conversions start landing — by which point the best hours may be gone. This lag, on short non-recurring spikes, is the entire reason seasonality adjustments exist. They let you tell the model about the spike in advance so it does not have to wait to observe it.

Understanding this boundary is the whole game. Everything the algorithm can learn from history, leave it. Only the unpredictable, short, sharp spike justifies intervention.

Seasonality adjustments vs data exclusions: the core distinction

Google ships two distinct seasonality controls inside Smart Bidding, and conflating them is the most common error we see in account audits. They point in opposite directions in time.

Seasonality adjustments are forward-looking. They tell Smart Bidding: 'For this specific upcoming window, expect conversion rate to be X% higher (or lower) than normal, so adjust bidding in advance.' The system uses this to bid more aggressively going into a known spike — closing the observation lag described above. They are the right tool when you know a short, sharp conversion-rate change is coming that the model cannot have anticipated.

Data exclusions are backward-looking. They tell Smart Bidding: 'For this specific past window, ignore the conversion data — it was not real.' This protects the model from learning the wrong lesson when something corrupted your conversion tracking. If a broken tag suppressed conversions for three days, the raw data makes it look like your campaigns suddenly stopped working; without an exclusion, Smart Bidding would 'learn' that and pull back bids. The exclusion quarantines that bad window.

The diagnostic flowchart that resolves almost every real case:

1. Is the event in the future? → consider a seasonality adjustment (if short and high-magnitude).
2. Is the event in the past and was it a tracking/site problem? → consider a data exclusion.
3. Is the event in the past and was it real (a sale that genuinely happened and converted)? → do nothing; that data is valuable, let the model keep it.
4. Is the future event recurring or gradual? → do nothing; the model anticipates it.

The fourth case traps the most people. A real, recorded sales spike from last quarter is good training data — excluding it would throw away a true signal. Data exclusions are exclusively for windows where the data lies, never for windows where performance was simply unusual but accurate.

When to use seasonality adjustments (and when not to)

The qualifying criteria are strict, and all three must hold simultaneously. Miss any one and you should not apply an adjustment.

Criterion 1 — Short duration (1-7 days). Google explicitly designs seasonality adjustments for brief events and recommends staying under 14 days. The reason is mechanical: over a long window, the model's own daily adaptation takes over and the manual adjustment starts fighting it. A two-day flash sale qualifies; a six-week holiday season does not.

Criterion 2 — High magnitude (roughly 20%+ conversion-rate change). Below this, the expected lift is within the noise band the model already handles, and applying an adjustment introduces more over-bidding risk than upside. The magnitude must come from your own historical data for that event type — not optimism. Over-stated magnitude is the number-one cause of seasonality-driven overspend.

Criterion 3 — Unpredictable from history. The whole value is closing the observation lag on something the model has not seen. A first-time product launch, an unusual one-off promotion, a sudden press or viral moment — these qualify. A recurring annual sale the account has run for two years does not, because the model already has that pattern.

Concrete cases where a seasonality adjustment IS appropriate:

• A first-ever flash sale where you historically (from a comparable event) see conversion rate jump 40%+ for 48 hours.
• A product launch with a hard go-live date and a known, large pre-order conversion spike the account has never recorded before.
• A one-off promotion (a partnership, a media feature) you know will lift conversion rate sharply for a few days.

Concrete cases where it is NOT appropriate (do nothing):

• Recurring holidays the account has 1+ years of data on — already modelled.
• Gradual seasonal ramps (the slow build into Q4) — daily adaptation handles it.
• Long sales periods over two weeks — let the model adapt.
• Routine weekend or end-of-month fluctuation — already priced in.
• Small promotions with modest (<20%) expected lift — noise.

The honest summary: the bar is high and most accounts clear it only a handful of times per year. If your team is applying seasonality adjustments monthly, that is a red flag that they are micromanaging rather than reserving the tool for genuine unpredictable spikes. For the recurring stuff, our Google Ads seasonality and budget guide covers the budget-side moves that actually matter across long seasons.

When to use data exclusions instead

Data exclusions are the under-used half of the pair, and arguably the more important one for protecting long-term performance. Their job is to stop Smart Bidding from learning false lessons when your conversion data was corrupted.

The canonical triggers:

• Conversion-tracking outage: a tag broke, GTM mis-fired, or a deployment removed the conversion snippet. Conversions happened but were not recorded. Raw data shows a cliff.
• Site or checkout downtime: the site went down, or the checkout/payment gateway failed. Real demand existed but could not convert. Conversion rate collapsed for non-market reasons.
• Payment processor failure: customers tried to buy but transactions failed at the gateway, suppressing recorded purchases.
• Analytics/import disruption: offline conversion imports or a CRM sync broke, so conversions landed late or not at all in the window.
• Accidental config changes: someone paused a critical conversion action or changed attribution settings, distorting the data for a period.

In every case the defining feature is that the conversion data does not reflect true market performance — it reflects a measurement or fulfilment failure. Left unaddressed, Smart Bidding interprets the artificial dip as a real drop in campaign effectiveness and reduces bids, compounding the damage well after the technical issue is fixed.

How a data exclusion protects you: by marking the window as excluded, you tell the model 'do not use this for learning conversion-rate patterns.' The model effectively bridges over the bad period rather than treating it as a genuine performance signal. This prevents a multi-day tracking bug from causing weeks of suppressed bidding afterward.

Critical boundaries on data exclusions:

• They do not edit your reports. The artificial dip still shows in reporting; the exclusion only affects the bidding model. Communicate this to stakeholders so nobody expects the chart to 'heal.'
• Match the window precisely. Exclude exactly the corrupted period — no wider. Over-excluding throws away real data on the edges.
• Never exclude real performance. A genuine slow week, a real demand drop, an actual bad campaign period — these are true signals the model should learn from. Excluding them blinds the algorithm to reality.
• Apply promptly but they work retroactively. You can apply an exclusion after discovering an outage; it will retroactively quarantine that window from the model's learning.

The decision rule is simple: exclude only when the data is false, never when it is merely disappointing. If you find yourself wanting to exclude a window because performance was bad, stop — that is exactly the data Smart Bidding needs to adapt correctly. For the tracking foundations that determine whether your conversion data is even trustworthy, see our conversion tracking guide.

Configuring a peak event: sales, launches, promotions

This is the practical heart of the article — how to actually configure a seasonality adjustment for the three event types that genuinely qualify.

Event type 1 — The flash sale. A flash sale is the textbook case: short, sharp, high conversion-rate lift. The configuration discipline:

• Pull last year's (or the closest comparable) conversion-rate lift during the exact sale hours.
• Enter that conversion-rate change as the adjustment — round down if uncertain.
• Set the window to the precise sale start and end datetime, not the announcement period.
• Raise daily budgets so the system is not constrained during the most efficient hours.
• Leave targets unchanged unless you are deliberately accepting worse efficiency for volume.

A common flash-sale mistake is setting the adjustment window to the full promotional calendar (including teaser days) rather than the hours conversion rate actually spikes. The teaser days do not see the lift; aggressive bidding there just wastes budget.

Event type 2 — The product launch. Launches are trickier because the conversion-rate behaviour is often unknown for a first-time launch. Guidance:

• If you have launched similar products, use that conversion-rate profile.
• If it is genuinely novel, be conservative — under-state rather than over-state the expected lift.
• Consider whether the spike is at launch hour or builds over the first day; set the window to match.
• Watch for the opposite risk: launches sometimes carry high traffic but lower conversion rate (curiosity clicks). If history suggests that, a negative adjustment may be more appropriate than a positive one.

Event type 3 — The one-off promotion. Partnership features, media coverage, influencer drops — short bursts of unusual demand. Guidance:

• These are the hardest to quantify because they are by definition unprecedented.
• Lean conservative; the cost of over-bidding on a misjudged promotion is immediate overspend.
• If you cannot estimate the conversion-rate change with any confidence, it is often better to do nothing and let the model react, accepting the small observation lag.

The unifying principle across all three: the seasonality adjustment communicates an expected conversion-rate change and nothing else. It is not a budget tool, not a target tool, and not a substitute for the campaign-level preparation (landing pages, promotion extensions, budget headroom) that actually makes a peak event succeed.

The manual-override risks that wreck Smart Bidding

The reason this guide repeatedly counsels restraint is that manual seasonality overrides have specific, well-documented failure modes. Knowing them is what separates surgical use from chronic interference.

Risk 1 — Over-stating the conversion-rate lift. The most common and most expensive failure. If you tell the system to expect a 50% lift and the real lift is 15%, the system over-bids for the entire window — paying inflated CPCs for clicks whose conversion rate never justified them. Because the adjustment runs for the full window, the overspend compounds hour by hour. The defence: base magnitude strictly on historical data and round down.

Risk 2 — Double-counting seasonality. Applying a seasonality adjustment to an event the model already anticipates (a recurring holiday) stacks your adjustment on top of the model's own adaptation. The result is erratic, over-aggressive bidding as two seasonality signals compound. The defence: only ever adjust for the genuinely unpredictable.

Risk 3 — Window mismatch. Setting the window wider than the actual conversion-rate change tells the system to bid aggressively during normal-demand hours at the edges. Setting it narrower misses part of the spike. The defence: match the window to when conversion rate actually moves, to the hour.

Risk 4 — Stacking target changes on top. Simultaneously changing Target CPA/ROAS and applying a seasonality adjustment makes it impossible to know afterward which lever did what — and a target change also triggers a learning re-evaluation that can introduce its own volatility. The defence: change one thing at a time, and prefer the seasonality adjustment for short events because it does not reset learning.

Risk 5 — Chronic micromanagement eroding data continuity. The subtlest harm. Smart Bidding performs best with stable, continuous data and minimal disruption. Teams that reflexively apply adjustments, exclusions, and target tweaks every few weeks deny the model the continuity it needs, and the cumulative effect is a perpetually-unsettled bidding system that never reaches its potential. The defence: a high bar for any intervention and a written policy that the default is to do nothing.

Risk 6 — Forgetting to let it expire. Extending an adjustment past the real event, or forgetting one is active, tells the model to keep over-bidding into normal demand. The defence: precise end-datetimes and an event log that tracks active adjustments.

The throughline is that every one of these risks comes from treating Smart Bidding like a manual-CPC system that needs constant steering. It is the opposite — a system that rewards being left alone and punishes interference. The seasonality tools are exceptions for genuine edge cases, not routine controls. The same restraint applies to bid strategy tuning generally; our Target ROAS vs Target CPA guide covers how target changes themselves should be handled sparingly.

Step-by-step setup in Google Ads

The HowTo schema above gives the full eight-step playbook. Here is the operational walkthrough inside the interface, with the decision logic at each gate.

Locating the tools. Both seasonality adjustments and data exclusions live under Tools in the Google Ads interface, in the Bid Strategies area (the exact menu path shifts with interface updates, so navigate via Tools → Shared library / Bid strategies → Advanced controls, and look for 'Seasonality adjustments' and 'Data exclusions'). They are account-level controls that you scope to specific campaigns or campaign types.

Setting up a seasonality adjustment:

1. Name it descriptively — include the event and dates (e.g. 'Spring-flash-sale-2026-Mar14-15') so your future self and teammates can audit it.
2. Set the date range — exact start and end datetime matched to the conversion-rate window.
3. Select the device(s) — if the lift is mobile-specific, scope accordingly; otherwise all devices.
4. Choose campaign types and campaigns — verify current support (Search and Display are supported; check Performance Max and Shopping coverage, which has historically been more limited).
5. Enter the conversion-rate adjustment — the expected percentage change, from historical data, rounded down if uncertain.
6. Save and verify — confirm the adjustment shows as scheduled with the correct window and scope.

Setting up a data exclusion:

1. Name it descriptively — include the issue and dates (e.g. 'Tracking-tag-outage-2026-Feb03-05').
2. Set the date range — match the corrupted window exactly.
3. Select device(s) and campaigns — scope to the affected surface.
4. Save — the exclusion retroactively quarantines that window from the bidding model.

Pre-launch checklist before any seasonality adjustment goes live:

• Magnitude derived from historical data, not a guess.
• Window matched to the real conversion-rate change to the hour.
• Scope limited to genuinely affected campaigns.
• Daily budgets raised ahead of the event.
• No simultaneous target change.
• Adjustment applied 1-2 days early so the system incorporates it.

During and after:

• Monitor for catastrophic anomalies only; do not edit mid-event.
• Let the adjustment expire on its end-datetime; do not extend.
• Log actual vs predicted conversion-rate lift for next cycle.

A note on Performance Max and Shopping: Google has progressively extended seasonality-adjustment support, but coverage has lagged Search and Display, and the controls behave somewhat differently in fully-automated campaign types. Always verify current support in the interface rather than assuming parity — applying an adjustment to a campaign type that does not honour it gives a false sense of control. For PMax specifically, the levers that matter most during peaks are asset group readiness and budget, covered in our Performance Max complete guide.

Measuring the impact and avoiding false attribution

The final discipline — and the one most teams skip — is honestly measuring whether your seasonality intervention helped, hurt, or did nothing. Without this, you cannot improve, and you risk repeating mistakes annually.

The core measurement problem: during a peak event, performance changes for many reasons at once — the sale itself drives conversions, your budget increase drives volume, broader market seasonality moves, and competitors run their own promotions. Attributing the outcome specifically to the seasonality adjustment requires careful isolation, which is why changing one variable at a time matters so much.

The metrics to capture for every adjusted event:

• Predicted vs actual conversion-rate change. Did the real lift match what you entered? This is the single most useful learning loop — over a few cycles it calibrates your magnitude estimates.
• CPC during the window vs baseline. A large CPC spike with no proportional conversion-rate lift signals over-bidding from an over-stated adjustment.
• CPA / ROAS during the window vs a matched prior period. The bottom-line efficiency question.
• Conversion volume vs a matched prior period. Whether the adjustment plus budget actually captured more of the spike.

Avoiding false attribution — the discipline:

1. Change one variable. If you applied a seasonality adjustment and changed targets and doubled budget, you learn nothing about the adjustment specifically. Reserve clean single-variable tests for at least some events.
2. Use a matched comparison period. Compare to the same event last year, or a comparable prior window — not to an arbitrary 'normal' week, which has different baseline dynamics.
3. Beware Smart Bidding's own reporting bias. The platform tends to credit its automation generously. Cross-check against GA4 and, where stakes are high, against actual booked revenue from your back-end, not just platform-reported conversions.
4. Consider a holdout for high-stakes recurring events. For a major annual sale, you can run the adjustment on most campaigns and hold out a comparable subset un-adjusted, then compare. This is the closest thing to a true read on incremental impact, and our incrementality testing guide covers the methodology.

Building the institutional memory. The highest-leverage habit is a simple event log: date, event type, predicted conversion-rate change, actual change, CPC/CPA/ROAS deltas, and a one-line lesson. After two or three cycles of a recurring event, this log turns guesswork into a calibrated benchmark — and it is the difference between a team that improves its seasonality handling year over year and one that re-makes the same over-bidding mistake every peak.

The honest closing assessment: for the large majority of accounts, the right amount of seasonality intervention is very little. Smart Bidding handles the predictable, and the predictable is most of what an account faces. Reserve seasonality adjustments for the handful of genuinely unpredictable, short, high-magnitude events per year, reserve data exclusions for the rare windows where your data lied, and otherwise protect the data continuity the algorithm depends on.

If you want an automated read on whether your account is over- or under-using seasonality controls — alongside structural bidding, budget, and tracking issues — SteerAds runs a free 14-day audit that surfaces exactly these manual-override risks across your campaigns.

Sources

Official and third-party sources consulted for this guide:

• support.google.com/google-ads — Google Ads Help (Smart Bidding, seasonality adjustments, data exclusions documentation)
• thinkwithgoogle.com — Think with Google automation and Smart Bidding best-practice guidance
• optmyzr.com/blog — Optmyzr analysis of Smart Bidding controls and seasonality handling
• searchengineland.com — Search Engine Land coverage of Google Ads bidding and seasonality features
• searchenginejournal.com — Search Engine Journal Smart Bidding and automation reporting

FAQ