GA4 lead forms: thank-you page view or form submit as the key event?

On a dental clinic's booking page, I'd lean toward the submit event, fired only after validation passes. The thank-you page view is the easy default, but it counts refreshes and bookmarked URLs, and it misses anyone who submits successfully and never reaches the redirect. A raw submit event has the opposite problem, since it fires on empty or invalid submits unless you tie it to validation. Once you fix that, it's the cleaner lead signal. I'd keep the thank-you view as a sanity check rather than the source of truth. The two numbers rarely match, so when they drift apart, which one do you trust?

Agreed on the submit event, but I'd fire it off the server's success response, not client-side validation. A slot that's already taken or a server error can pass validation and still never produce a booking.

If the two GA4 numbers start to drift, check the booking system's own count of confirmed appointments first, since both GA4 numbers are only proxies. The gap usually comes from tracking, like a redirect getting blocked or a booking widget on another domain losing the session, rather than from how users behave.

Agreed on the server signal, but there's a catch if you go fully server-side. Measurement Protocol events need a client_id to join a session, and if the booking request doesn't carry the _ga cookie value from the browser, the conversion lands with no source, device or session attached. So have the form send the client_id (and the GA session_id if you can) along with the booking, then let the server fire the event with the booking ID as a parameter. That ID also gives you a clean dedupe key against any browser event, and it lets you match GA4 counts to the booking system's own count.

Client_id alone won't get you there. The ad platforms need their own click IDs to tie a conversion back to a click: gclid for Google, msclkid for Microsoft Ads. Have the form grab both from the URL on page load and send them along with the booking, so the server can attach them to the event or the offline conversion upload. Without them, Bing conversions arrive unattributed and quietly drag down your bidding data.

My rule of thumb is that the booking system's ID is the key everywhere, and ad platform conversions get fed from the server, not the browser tag. Keep the browser tags running for on-site signals, but don't bid against their numbers.

Same on Meta, and it matters more there because the algorithm learns from whatever events it gets. Pass fbclid and the _fbc and _fbp cookies along with the booking, and use the booking ID as the event_id on both the pixel and the Conversions API so Meta doesn't double count. Are you doing that on both sides?

The detail that trips people up is event_name. Meta only deduplicates when the pixel and the Conversions API events share both the name and the ID, so a pixel Lead paired with a server Schedule won't merge and you'll double count. Dedupe also only works within a window of about 48 hours, which means a server event that lands days after the pixel fires can end up counted twice. For a clinic that confirms bookings the same day, that's rarely a problem. One more thing: pass _fbc through exactly as the browser set it instead of rebuilding it from fbclid, because the timestamp inside it is what Meta uses for attribution.

The 48-hour window runs on event times, so a pixel Lead fired at submit and a server event fired at confirmation three days later won't merge. If confirmation is delayed, fire both from the same confirmation moment so the event name, ID and timing all line up.