GA4 saw a third
of the leads.

How I found it

I stopped reading GA4 on its own and compared it, day by day, with the lead sheet and the database copy of it. That one comparison found every problem below. Each fix was then re-checked the same way.

Three ways a hit died

• The redirect won the race. The event fired just before the browser moved to the thank-you page, and the browser could cancel it. Fix: send it as a beacon, which survives navigation.
• The phone killed the request. The event only fired after the server's answer came back. On mobile, a backgrounded tab or a dropped connection meant the answer never arrived, so the event never fired, even though the lead was saved. Fix: keepalive on the request.
• The browser never sent it. Ad blockers and Safari's tracking protection drop analytics hits outright. No client-side fix exists. Fix: send lead events from the server, the one place a lead is certain, through GA4's Measurement Protocol, still respecting the visitor's consent.

Making the next gap explainable

Two weeks later, two real leads had no event. Probably visitors who declined analytics, which the code skips by design, but I couldn't prove it from the data. So every lead now writes one log line with its ID: sent, skipped (no consent) or failed (status). The next missing event has an answer in the logs instead of an investigation.

Since then GA4 and the lead record match: 100% of office and terrace leads, 86% of conference leads. The one gap is most likely a visitor without consent.

What I'd do next

Asked “what if the sheet write and the analytics event both fail after the customer already saw success?”, I wrote down two real gaps instead of claiming the pipeline was solid: network failures on the sheet webhook were swallowed silently, and replaying a lead would create a duplicate row. The fix I'd build: write each lead first to a store the Worker controls, with a flag per destination, and let a retry job resend only what failed, with every destination checking the lead ID before writing.