Offline conversion imports for a 90-day B2B cycle: which stage to send back?

Picture a B2B software company running paid search with a 90-day sales cycle, where only about one demo request in twenty closes. Google Ads only sees the form fill, so Smart Bidding keeps going after the cheapest demo requests, and those often come from the wrong people. Offline conversion import is the usual fix, but you still have to pick which event to send back.

Sending every stage (MQL, SQL, opportunity) gives the bidder more volume to learn from, but each stage is judged by a different person in sales, so the signal gets noisy. Sending only closed-won is cleaner, but it can take months to collect enough wins for the algorithm to change anything.

My view is to import a qualified stage like SQL early, then move to closed-won once you have a steady number of wins each month. Which stage are you feeding back, and how long did it take before the bidding actually shifted?

The 90-day limit is the catch. Google Ads only accepts click conversion uploads for clicks up to 90 days old, so if a deal takes most of that cycle to close, the closed-won upload can land outside the window and never credit the click. That's why I'd import SQL as its own conversion action and send closed-won as a second one, instead of swapping one for the other. Then set only the action you want the bidder to optimize for as primary, because that's the one it actually learns from.

Agreed on keeping them as separate actions. My rule of thumb is to make primary the latest stage that sales accepts without arguing about it, because a noisy early signal teaches the bidder the wrong lesson. Keep closed-won for reporting until wins are steady enough to trust.

Here's a test I'd add to that rule: would sales still accept the stage if they knew it was being used to steer spend? Once an SQL label gets loosened to hit a target, the bidder starts learning from noise, and you won't see it in the CRM for weeks.

If you want more signal without waiting for closed wins, give each stage a value instead of counting them all equally. Roughly the expected win rate for that stage times your average deal size works. The bidder will then favor demo requests that look like real pipeline. Just keep those values honest, because it will chase whatever you price highest.

The 90-day limit counts from the click to the upload, not to the close. So a lead that clicked on day 2 and closed on day 120 can still get credit if you upload the SQL on day 40. That's a good reason to use the earlier stage for uploads.

Stage values only feed bidding when they're attached to primary actions. If you price SQL at 15% of deal size and also make closed-won primary, the bidder sees the same deal twice, once as pipeline and once as revenue. Pick one primary action for value-based bidding and keep the other as observation only.

Also watch for sending one blended average value across segments. The bidder will spend hardest on whichever segment you overvalue, so a single average can quietly favour the cheapest, smallest accounts.

Agreed on the double counting. None of this works if the click ID never reaches the CRM, though. Google matches an offline upload to a click through the gclid, so it needs to be captured as a hidden field at form submit and stored on the lead record. It usually breaks in two places: the form sits on a page builder or subdomain that drops URL parameters, or the lead gets created by a sync tool that only maps the visible fields. The SQL upload still goes through without an error, but few rows match, and the bidder ends up learning from very little. Look at the upload diagnostics for match rate before you trust any stage. A stage that matches 20% of its rows teaches less than a smaller, clean closed-won list.

Same problem on the Microsoft side, and it's easy to miss because most setups only capture gclid. If you run Bing too, the hidden field needs msclkid as well, or the Microsoft import matches nothing and it looks like Bing just doesn't convert. Check match rate per platform instead of one blended number, since a healthy Google rate can hide an empty Bing column. Are your Bing landing pages on the same domain as the form, or is the form embedded from a third-party tool?

Agreed, and Bing is where I'd look first. msclkid only shows up in the landing page URL if auto-tagging is on in the Microsoft Advertising account, so a campaign with manual tagging, or with auto-tagging switched off, will never give you a click ID to capture, no matter what the form does. Easy test: click one of your own Bing ads and check the final URL before you touch the CRM. If the parameter isn't there, the problem is upstream of the form.

"Will never give you a click ID" doesn't hold for manual tagging. Manual tagging only means you write the URL yourself, and Microsoft's ValueTrack can still drop {msclkid} into it. If your final URL suffix or tracking template includes msclkid={msclkid}, the parameter reaches the landing page even with auto-tagging off. Your click test still works, but the fix is different: check whether your template passes the parameter through, not just whether auto-tagging is on. Auto-tagging is the easy default, not the only way to get the ID.

I wouldn't rely on the click test alone. If your tracking template sends clicks through a redirect or a third-party tracker before the form page, the address bar can still show msclkid while the page that actually loads has already dropped it. So check the query string on the page where the form sits, after every redirect. Manual tagging with {msclkid} can work, but the parameter usually dies on the hop between the ad and the form.