What you will find in this article
- How Smart Bidding already models recurring seasonality on its own, and why most of the time you should not touch it
- The distinction between predictable seasonality, short conversion-rate spikes and abnormal data periods, three cases that require three different responses
- The complete decision matrix: which lever to use (nothing, seasonality adjustment, data exclusion) for each scenario
- What seasonality adjustments actually do to the bid and the documented 1–7 day window, official sources and inferences separated
- Behaviours observed on real campaigns during Black Friday and flash sales, clearly flagged as inferences
- The practical workflow for managing a seasonal event without resetting the learning phase
You run a flash sale over the weekend. The conversion rate jumps, but Smart Bidding seasonality handling lags: the algorithm is still pricing auctions against the last 30 days of "normal" data, so on day one it underbids and you leave volume on the table, while on day three it overbids on traffic that has already cooled. Same automated strategy, same account, opposite mistakes on consecutive days. The reason is not a flaw in the bidding model: it is a timing gap between when buyer intent changes and when the algorithm has enough fresh data to react.
Seasonality in Smart Bidding is not a single phenomenon. Some patterns recur every year and the system already anticipates them. Some are sharp, short spikes the system cannot see coming. And some are not real demand at all, but data artefacts that, if absorbed, distort future bidding. Treating all three the same way is the most common and most expensive mistake.
This article clearly separates what Google officially documents about how Smart Bidding handles seasonality from what emerges from managing real campaigns through Black Friday, product launches and promotional weekends.
How Smart Bidding already reads seasonality, and why it is not what many think
The most common misconception is that Smart Bidding is blind to seasonality and needs to be told about every peak. It is not. The opposite is closer to the truth: it models recurring patterns continuously.
Recurring seasonality, the weekday rhythm, the predictable end-of-month bump, the broad holiday lift, is something Smart Bidding learns from your historical data and projects forward. Manually intervening on these patterns usually does more harm than good, because you are overriding a signal the model already has.
So the practical question is not "how do I tell Smart Bidding about seasonality" but "which kind of seasonality am I facing, and does it fall outside what the algorithm already anticipates?" The documented answer is that only sharp, short, unusual deviations need a manual signal. Everything else is the algorithm's job.
The three types of seasonality: predictable, short spike and abnormal data
Before reaching for any lever it is necessary to classify what you are dealing with, because the three cases call for three completely different responses.
Decision matrix: which lever to pull for each seasonal scenario
This table summarises the recommended response for each scenario (state as of June 2026). Sources are indicated for documented behaviour; for what is inferred from campaign management this is explicitly stated.
| Scenario | Algorithm handles it | Seasonality adjustment | Data exclusion | Learning-phase risk | Source |
|---|---|---|---|---|---|
| Weekday / time-of-day cycle | Yes, fully | No, do not use | No | None | Official Google Ads Help |
| Broad holiday lift | Yes, mostly | Rarely needed | No | Low | Official Google Ads Help |
| Flash sale 1–3 days | Too slow to react | Yes, recommended | No | None | Official + campaign analysis ⚠️ |
| Promotional weekend | Partially | Yes | No | None | Official + campaign analysis ⚠️ |
| Product launch spike | No, unprecedented | Yes | No | None | Official + campaign analysis ⚠️ |
| Event longer than 14 days | Eventually adapts | Not recommended | No | Medium | Official Google Ads API |
| Tracking outage / site down | No, absorbs bad data | No, wrong tool | Yes, required | Medium | Campaign analysis ⚠️ |
| Post-event period | Reverts on its own | No negative adj. needed | No | None | Official Google Ads Help |
What a seasonality adjustment actually does to the bid
The adjustment does not set a bid directly. It tells Smart Bidding to expect a different conversion rate for the defined window, and the strategy raises or lowers bids to keep hitting your Target CPA or Target ROAS given that expectation. If you historically see a 50% conversion-rate lift during a sale, you signal roughly that, and the system bids more aggressively from the first hours instead of waiting for the data to confirm the spike.
The key operational advantage is the built-in expiry. When the end time is reached, the system reverts to its baseline data with no negative adjustment required afterwards. This is what makes the adjustment safer than editing the target mid-event: it is a temporary, self-closing instruction rather than a permanent change to the strategy.
Inferences from managing real campaigns through seasonal events
Black Friday: the algorithm partially anticipates it, but the adjustment still helps on day one. Accounts with several years of Black Friday history saw Smart Bidding lean in on its own, the model clearly recognised the period. But on the first hours of the sale, before fresh data accumulated, bids were conservative. Applying a modest conversion-rate adjustment closed that early gap without changing the eventual steady-state behaviour. The lift was concentrated in the opening window, not across the whole event.
Flash sales: this is where the adjustment earns its keep. For a 48-hour sale with no comparable history, Smart Bidding had nothing to anticipate. Without an adjustment, day one was visibly underbid and day two over-corrected. With an adjustment sized to the expected lift, bidding tracked intent from the start. The shorter and sharper the event, the larger the value of signalling it in advance.
Over-stating the modifier backfires. On one promotional weekend an aggressive conversion-rate modifier, set well above the realistic lift, produced inflated bids and a worse cost per acquisition than the no-adjustment baseline. The adjustment is a forecast, not a throttle: when the forecast is wrong, the bids are wrong. A conservative, evidence-based modifier consistently outperformed an optimistic one.
Predictable seasonality is best left untouched. On accounts where someone had layered manual seasonality adjustments onto ordinary weekend patterns the algorithm already handled, performance was noisier, not better. Removing those redundant adjustments and letting Smart Bidding model the recurring rhythm produced steadier results. The distinction between what the model anticipates and what it cannot is the whole game.
Practical workflow: how to manage a seasonal event without resetting learning
1. Classify the event before touching anything. Ask whether the pattern is predictable (recurring weekly or holiday rhythm), a short sharp spike (flash sale, launch, promo weekend of 1–7 days), or an abnormal data period (outage, broken tracking). Predictable patterns need no action. Short spikes are the seasonality-adjustment case. Abnormal data is the data-exclusion case. Misclassifying here is the root of most mistakes.
2. For a short spike, size the modifier from real history, not optimism. Base the conversion-rate modifier on the lift you actually observed in comparable past events. The API accepts a modifier between 0.1 and 10.0; a realistic figure such as a 30–50% lift translates to a conservative value, not the maximum. Set precise start and end date/times that match the promotion, and scope it to the affected campaigns or channel.
3. Let the built-in expiry do the cleanup. Do not create a negative adjustment after the event. Per Google's documentation the system reverts to baseline once the end time passes:
start: 2026-11-27 00:00 end: 2026-11-28 23:59 modifier: 1.4 A self-closing instruction is exactly
why this is safer than editing the target.
4. For an outage, exclude the data instead of adjusting it. A seasonality adjustment forecasts conversion-rate change; it does not erase misleading historical data. For a tracking outage or broken checkout, apply a data exclusion to the affected window so the model does not learn from an unrepresentative period. Use this sparingly and only when the data is genuinely not representative of real demand.