What you'll learn in this article
- What data exclusions smart bidding Google Ads actually removes from the algorithm, and what it deliberately leaves in your reporting
- Exactly how I exclude the days when conversion tracking broke, and how far back I go once I account for conversion delay
- The real difference between data exclusions and seasonality adjustments, told through what each one tells the bidder
- When I reach for one, when I reach for the other, and when I deliberately do nothing
- The mistakes I have made with google ads data exclusions smart bidding so you don't have to repeat them
Data exclusions smart bidding Google Ads is the tool I reach for the moment I discover that conversion tracking has been broken for a stretch of days, because a Smart Bidding strategy that learns from dirty data will keep making bad decisions long after the tag is fixed. Smart Bidding does not just report on conversions; it treats them as the signal it optimizes toward. Feed it a few days where the pixel silently stopped firing and it does not see a tracking outage. It sees a genuine collapse in demand, and it responds by pulling bids down exactly when it shouldn't. This article is what I actually do when that happens, how I decide the date range, and why I keep data exclusions and seasonality adjustments in two completely separate mental buckets.
What data exclusions actually do to Smart Bidding
The core idea is narrow on purpose. A data exclusion tells the bidder to ignore all conversion and conversion-value data from a date range you specify, because you know that data is wrong. It is not a bid modifier and it is not a targeting change. It is a way of saying to the algorithm: "these days lied to you, don't learn from them." Google's documentation on data exclusions is explicit that they only affect the data Smart Bidding uses, not what you see in reporting, and that distinction matters more than it first appears.
The reporting point is the one people miss. When I apply an exclusion, the conversions from those days still show up in my columns, my ROAS calculations, and my client dashboards. Nothing disappears from the record. What changes is invisible: the model quietly stops treating that window as evidence. So a data exclusion is never a way to "clean up" a bad-looking week for a report. It is purely a signal-hygiene tool for the algorithm, which is why the only question I ask before applying one is whether the conversion data in that window was actually broken, not whether the week looked bad.
One more thing that shapes how I use them: exclusions apply to clicks, not to the conversions directly. Because a conversion can be attributed to a click that happened days earlier, excluding a window of dirty conversions means excluding the clicks that would have carried those conversions. That single mechanical fact is what makes the date range the hard part of the whole job, and it feeds directly into the way I set one up. If you want the wider context on how the bidder consumes this data, my guide to how Smart Bidding works covers the signal loop that data exclusions protect.
How I exclude the days with broken tracking
My trigger is simple: any time I confirm a tagging issue, a site outage, or a failed conversion import, I assume Smart Bidding has already started reacting to it and I move fast. Speed matters because every day a dirty window stays inside the model's memory is another day it optimizes against phantom demand. I don't wait for a statistically clean picture; the moment I know the data is wrong, I exclude it.
Setting the date range around conversion delay
This is where most of the thinking goes. Because exclusions apply to clicks and conversions lag behind clicks, I never exclude only the days the tracking was down. I look up the account's average days-to-conversion first, then extend the exclusion backwards to cover the clicks that would have converted during the broken window. If tracking failed for three days and my typical conversion delay is five days, I am excluding closer to eight days of clicks, not three. Google's guidance is to exclude at least 90% of the clicks associated with the impacted conversions, and in practice that means erring wider rather than narrower.
Requirements I check before applying
Data exclusions only work with conversion or conversion-value based strategies, so on a Maximize Clicks or manual CPC campaign there is nothing to exclude from, because the bidder isn't learning from conversions in the first place. I also confirm the scope: an account-level exclusion touches Search, Display, Shopping, and Performance Max together, while a campaign-level one keeps the surgery contained. When only one tag on one campaign broke, I scope it to that campaign rather than nuking the whole account's signal. This is the same discipline I apply around the Smart Bidding learning period, since an ill-timed exclusion can knock a strategy back into learning.
What I do after it's live
Once the exclusion is active I expect fluctuation, not instant calm. Bids and spend often dip for a short period as the model reweights, so I set the budget near historical spend and, on tROAS or tCPA strategies, loosen the target slightly to let the bidder recover to optimal levels. And I do not undo it later. Removing an exclusion after it has been applied reintroduces the dirty data and causes more disruption than it fixes, so once it's on, it stays on.
Data exclusions vs seasonality adjustments
These two tools live in the same corner of the interface and get confused constantly, but they answer opposite questions. A data exclusion says "this past data is wrong, ignore it." A seasonality adjustment says "this data is real, but the near future will be unusual, so expect it." One is about corrupt history; the other is about a predictable, short spike or dip in genuine conversion rate. That single sentence is the whole distinction, and once it clicks, you stop reaching for the wrong one.
Seasonality adjustments are for events like a 48-hour flash sale or a product launch where you know the conversion rate will jump for a brief, defined window, and you want to warn the bidder in advance so it doesn't under-bid into the surge or over-correct after it. They work best on short events, a few days at most, and they tell the algorithm to anticipate a temporary change in conversion rate. Crucially, the conversion data during that window is accurate; you are adjusting for reality, not correcting a lie. My deeper walkthrough of seasonality adjustments in Smart Bidding gets into how far to push the expected conversion-rate change.
Data exclusions are the mirror image. You apply them after the fact, to a window where the numbers themselves are untrustworthy because of a technical fault. There is no "expected conversion rate" to enter, because you are not predicting anything; you are amputating bad evidence. So the mental test I run is fast: was the conversion data in that window true or false? If it was true but unusual, that's a seasonality question. If it was false, that's a data exclusion. Getting that one fork right is 90% of using either tool correctly.
When I use one, the other, or neither
The decision tree I run in my head is short. First: is the conversion data accurate? If a tag broke, an import failed, or the site went down, the data is not accurate, and that is a data exclusion, applied to the affected window plus the conversion-delay tail. I do not consider a seasonality adjustment here, because there is nothing seasonal about a broken pixel.
Second: is the data accurate but about to behave unusually for a short, known window? A weekend flash sale, a Black Friday spike, a limited launch, that is a seasonality adjustment, set proactively for the days I expect the conversion rate to shift. And I keep it short. Stretching a seasonality adjustment across weeks tells the model the "unusual" state is the new normal, which defeats the point.
Third, and this is the answer people forget: often the right move is neither. Smart Bidding is built to handle ordinary volatility and recurring seasonality it has already learned, like every-December retail lift, on its own. If I reach for a manual override on a normal fluctuation, I am injecting noise into a system that was handling it fine. Both tools are exception handlers, and Google is clear that overusing exclusions in particular degrades performance. I apply them rarely, for genuine one-off events, and the rest of the time I let the strategy learn. That restraint is part of the same philosophy behind hitting the minimum conversion volume Smart Bidding needs before intervening at all.
Mistakes I have learned to avoid
The first mistake I made early on was excluding only the outage days and ignoring conversion delay, which left a tail of dirty click data still feeding the model. The fix was to always extend the range backward by the average conversion lag. The second was using data exclusions to tidy up a bad-looking week for a client report; since exclusions don't touch reporting, that never even did what I imagined, and it wasted a tool meant for genuine faults. The third was overuse: applying exclusions for every minor wobble until the strategy had so many holes in its history that it couldn't learn a stable pattern.
The most important habit I hold now with google ads data exclusions smart bidding is restraint paired with speed. When tracking genuinely breaks, I act immediately and I size the window generously. When it doesn't, I leave the algorithm alone. The accounts where Smart Bidding performs best are not the ones where I intervene constantly; they are the ones where I protect the signal from real corruption and then trust the model to do the rest.