Bid simulators and the data-thinness problem
How to read Google's bid and budget simulators, why thin-data products break Smart Bidding's predictions, and how pooling lets you reason about products that don't have enough conversions of their own.
Bid and budget simulators estimate what would happen if you changed your target or budget, whether that's more spend, more conversions or more value. They're useful, but they rest on having enough data to model, and most catalogues are full of products that don't. This is the data-thinness problem: below a certain conversion count, per-product predictions are noise. Pooling similar products together is how you get a usable signal anyway.
What simulators are for
Bid and budget simulators answer a "what if". A bid (or tROAS) simulator estimates how spend, clicks, conversions and conversion value would move if you changed your target. A budget simulator estimates the same for a change in daily budget. Both are built by modelling recent auction data, replaying what would likely have happened at a different setting.
Used well, they stop you flying blind. Before nudging a target, the simulator shows you roughly where the curve bends: the point past which raising the target sheds a lot of volume for little efficiency gain, or where a budget increase stops buying meaningful extra conversions. That shape is the useful part.
Read the curve, not the decimal points. A simulator that says "at 450% target you'd get 1,240 conversions" is not making a promise, it's sketching a trend from a model. Use it to judge direction and steepness ("raising the target from here loses a lot of volume fast"), not to bank exact figures.
The data-thinness problem
Simulators, and Smart Bidding itself, rest on one assumption: there's enough data to model. For a large chunk of a real catalogue, there isn't.
Conversions in Shopping are power-law distributed. A small set of hero products earns most of the conversions; the long tail earns a handful each or none. For those tail products:
- Per-product predictions are noise. With four conversions, a product's "ROAS" is a coincidence, not a measurement. One more order doubles it; one refund halves it.
- Simulators extrapolate. The product hasn't been in enough auctions to model, so its curve is mostly guesswork dressed up as a chart.
- tROAS misbehaves. A target set on thin data whipsaws, starving the product one week and overfeeding it the next, because the signal it's chasing is mostly randomness.
This is why "set a per-product target on everything" fails. The heroes have the data; the tail doesn't, and forcing a target onto no-data products is how you starve them. The strategy question this creates, which products belong on tROAS at all, is covered in tROAS vs Maximise Clicks vs Manual.
Deep dive Pooling, getting a usable signal from thin data
You can't manufacture conversions a product doesn't have, but you can borrow a pattern from products that behave like it. That's pooling, and it's the standard way to reason about thin data without pretending each product's four conversions mean something.
The idea: a product with thin data inherits a prior from its siblings (other products in the same category, price band and margin band) until it has enough of its own history to speak for itself. A £40 mid-margin accessory with six conversions borrows the conversion-rate and value pattern of the well-measured £40 mid-margin accessories around it, then gradually shifts to its own data as that data accumulates. Early on it's mostly the pool's signal; later it's mostly its own.
Why this is the right trade:
- Stability over false precision. A pooled estimate moves smoothly as data arrives, instead of lurching every time a single order lands. For bidding, a stable-but-approximate target beats a precise-but-random one every time.
- It degrades gracefully. The more real conversions a product earns, the less it leans on the pool, so pooling never overrides a product that genuinely has its own signal.
- It only works with clean grouping. Pooling is only as good as the siblings you pool with. Grouping by category, price band and margin band, the same dimensions you'd carry in custom labels, is what makes the borrowed pattern relevant rather than misleading.
Product-level tROAS analysis in BidSmart uses exactly this approach: thin products lean on their pool for a prior, well-measured products stand on their own history, and every recommended target is worked back from that blended signal. And because BidSmart is approval-first, those product-level targets and any move a thin product makes, such as graduating out of the incubator, are staged for your sign-off, never executed automatically. The per-product view is covered in tROAS by product.
Practical rules
- Don't trust a simulator on a product with thin data. Below roughly 15 conversions, the curve is extrapolation. Use it as a rough hint at best.
- Judge simulators on shape, not exact numbers. They tell you where curves bend; they don't bank you specific conversion counts.
- Pool thin products; don't target them individually. A per-product target on a four-conversion product is noise-chasing. Borrow a prior until the product earns its own signal.
- Move thin products into an incubator instead of tROAS. The cleanest fix for no-data products isn't a clever simulator reading: it's ramping them in a Maximise Clicks incubator until they have data worth modelling.
Frequently asked questions
What does a bid simulator actually tell me?
It estimates the outcome of a different setting, for tROAS roughly how spend, conversions and conversion value would change if you moved your target. It's a model built from recent auction data, not a promise. Treat the shape of the curve as guidance, not the exact numbers as fact.
Why can't I trust the simulator on a low-volume product?
The simulator models from observed auctions. A product with a handful of conversions hasn't been in enough auctions to model reliably, so its curve is mostly extrapolation. The fewer conversions, the more the simulator is guessing.
What is pooling and why does it help?
Pooling groups a thin product with statistically similar siblings (same category, price band, margin) and borrows their pattern until the product has its own. It trades a little precision for a lot of stability, which is exactly the right trade when a product's own data is too thin to trust.