GA4 lead key event: fire on form submit click or on the thank-you page?

Our lead form's key event is generate_lead, which fires on the submit click. That inflates the count, because some clicks are validation failures or double submits. Moving the trigger to the thank-you page gives cleaner numbers, but it breaks when people close the tab before the redirect finishes, and a cached page can make it fire unpredictably.

I think the thank-you page is still the right source for anything you bid on or report to a client, since it only fires when the server accepted the lead. Submit-click is fine for diagnosing form UX, just don't mix the two in one report. How do others handle AJAX forms where there's no redirect at all?

Jun, for AJAX forms I'd fire the event in the success callback, once the server comes back with a 200 and a lead ID, not on click. That gives you the same meaning as a thank-you page view without the redirect race. And if you pass that lead ID through with the event, you can dedupe double submits too.

The success callback fixes the timing, but it won't fix duplicates on its own. GA4 counts every event it receives, so passing the lead ID doesn't stop two sends from becoming two key events. You need a guard in the browser, like a flag that gets set once the callback fires. The ID is more useful as a dedupe key in whatever imports the conversion. Which system is your source of truth for a lead right now, the form backend or the CRM?

It depends on whether Google Ads is bidding on this event. If it is, I wouldn't optimize toward a browser event no matter how well you guard it. Ad blockers, closed tabs and consent settings drop hits, and the drops aren't random. They skew toward mobile users and privacy-conscious people, who may be exactly the leads you want.

For bidding, I'd send the accepted lead from the backend to Google Ads as an offline conversion, keyed on the lead ID Elena mentioned. That way the dedupe happens once, on your side, and the conversion count matches what the CRM actually received. Browser events are still useful for form UX and for the funnel view in GA4.

If you only report on leads and don't bid on them, the success callback plus a flag is probably enough, and the offline import isn't worth the extra plumbing.

It depends on how many accepted leads get tossed after the server returns a 200. If your backend takes everything and spam or unqualified leads only get filtered out in the CRM later, a success-callback event will overcount, and the offline import is the only version that matches what sales actually works. If your form already rejects junk before it returns success, the callback is close enough and the extra plumbing doesn't buy you much. Look at the CRM rejection rate over a few weeks and you'll know which case you're in.

Kai's right on bidding, but the piece people miss is that an offline import only helps if your backend can tie each accepted lead back to a click. So when the form loads, grab the gclid from the URL, drop it in a hidden field or a first-party cookie, and store it next to the lead ID. Without that, a lead the CRM accepts three days later has nothing to match against, and you're stuck leaning on enhanced conversions, which only work if the email or phone is clean.

Depends on the gap between the form and the CRM. If it's a few minutes, the success callback works fine as a proxy. If sales takes two weeks to qualify, the offline upload is what keeps bidding honest, so store the lead ID from day one.

Mira, the gclid-only setup works only if every click comes from Google, and plenty of accounts also run Microsoft Advertising, where gclid does nothing. Microsoft's equivalent is msclkid, and their offline conversion import matches on it. So the hidden field or first-party cookie should capture both, written on the same page load.

If you only store gclid, Bing leads reach the CRM with no click to attach to. The Microsoft conversion count quietly drops toward zero while the Google side looks fine, which is easy to miss because one platform seems to be working.

Also make sure the cookie survives any redirect before submit, or the IDs are gone by the time the form posts.

Agree with Theo on msclkid. The lookback window is the part to plan for. Google Ads only accepts click-linked offline conversions up to 90 days after the click, so if sales takes longer than that to qualify a lead, the upload gets rejected and those conversions never reach bidding.

The timestamp is the other trap. It needs a timezone offset that matches the account's time zone, and if it doesn't, leads land on the wrong day. That shows up as a small count mismatch that's hard to trace.

Before anyone builds this, pick one conversion action for bidding and make sure the GA4 lead event isn't also imported into Google Ads as a primary conversion. If both are primary, every lead gets counted twice, so the bidding signal inflates while the CRM count stays flat. Make the offline upload the primary action, set the GA4-imported one to observation only, and compare the Google Ads count against the CRM after the first week.

Kai's 90-day number is right, but it's a different limit from the one that decides credit. The upload limit is 90 days from the click, while the conversion action has its own click-through window that defaults to 30 days. An upload outside that window can be accepted without any error and still get no credit. So if sales qualifies leads in week six, the upload can look fine and bidding still sees nothing. Set the window to match your real sales cycle before the first import, not after you notice the gap.

Kai, I'm not sure the mobile and privacy skew is a good enough reason to rule out browser-side bidding. It may be true for some audiences, but right now it's a guess, and the loss is something you can measure. Consent mode, Safari's tracking prevention and ad blockers each drop a different slice of hits, and how much they drop depends on who your buyers are. A B2B software lead on a work laptop and a patient booking a clinic from their phone won't look alike.

The test is simple. Over the same two weeks, count GA4 lead events against CRM-accepted leads, split by device and browser. If the gap is small and roughly even across segments, the browser event with a guard is probably good enough for bidding. If the missing hits cluster in one segment, that's when the offline import earns its plumbing. Measure the gap before you decide it's big.