B2B offline conversion imports: optimize to MQLs, SQLs or closed-won?

For B2B accounts with long sales cycles, the question is which event to optimize on once offline conversions are imported into Google Ads or LinkedIn. MQLs come in fast and give the algorithm plenty of data, but a lot of them are students, competitors, or people who grabbed a whitepaper and never planned to buy. Closed-won is what sales cares about, but if you only close 10 deals a quarter, Smart Bidding has almost nothing to learn from.

My instinct is to optimize to SQLs that a rep has accepted. That filters out most of the junk without starving the model. I'm curious whether anyone runs a value-based version weighted by deal size, or whether that just adds noise at small volumes.

Value-weighting at the SQL stage can work, but I'd use a fixed proxy value per segment instead of the rep's estimate of deal size. Reps tend to type in whatever number feels good that day, and the model ends up learning from noise. A simple version is to take your average closed-won value for each segment (mid-market vs. enterprise, or by product line) and send that number when a lead gets accepted as an SQL. You keep the volume that makes SQLs useful for bidding, and the value signal stays stable enough for Smart Bidding to use. After a few quarters of closed-won data, check whether the proxy actually predicts deal size and adjust it. The real deal value can go in later as a separate closed-won event, and if volume is too low for bidding, keep it for reporting only.

I'm not sure a segment average holds up as a stable value. At the volumes Rowan describes, maybe 10 closed-won deals a quarter, the mean for "mid-market" can hinge on one or two big deals. One outlier shifts the proxy, and then every SQL in that segment gets the new number. A flat value per segment also tells you nothing about which SQLs are better within a segment, so all it really does is tell the model which segment to chase. Before adding value, I'd look at the spread of closed-won deal sizes inside each segment. If it's wide, the average is a poor proxy, and SQL is probably the better event to optimize on for now.

Kai's point about outliers is fair, and the thing I'd add is that the proxy only holds if the segment averages are stable, which depends on how many closed-won deals sit behind each segment, not on the total. With 10 deals a quarter spread across three segments, you're averaging three or four deals each, so one big logo can flip the number. A rough test is to compare the median to the mean over the last four quarters. If they sit close together, the average is probably safe to send. If they don't, stick with SQL as the event and treat the wide spread as a sign that value isn't predictable yet.

Whether this works comes down to when the segment gets set. If company size comes from the form or an enrichment tool, using the segment average is a fair proxy, because the model sees the same firmographic data the average was built on. If the rep assigns the segment after discovery calls, you've just moved the rep's judgment one step upstream. At that point the median-vs-mean check won't save you, since the segment label itself is the noisy part.