The symptom

The monthly report shows one number of form conversions. The client opens their CRM and counts a different number of leads. Nobody has done anything wrong, and the call goes in circles.

The version that does real damage is the one where the gap moves. One month the report is higher, the next month the CRM is, and a difference that changes direction costs you trust in the whole report.

The first instinct is that tracking is broken. Sometimes it is. More often both numbers are accurate counts of two different things, which is also why every tool in the stack reports a different number.

Why it happens

The two systems count different objects

Analytics counts events. In GA4, per Google Analytics Help, the enhanced measurement event form_submit occurs "when the user submits a form". That is a browser event, and the count rises once per occurrence.

A CRM counts records its own rules allow to exist. HubSpot's documentation is explicit: it "will look for a matching value in the Email property", and on a form submission, "if a contact already exists in your account with the same email address, the new contact information will be added to the existing contact". One person filling in three forms with the same address is three events and one contact. Whether a given CRM does this depends on its configuration.

The filters run in opposite directions

GA4 removes traffic you never see. Google states that "traffic from known bots and spiders is automatically excluded", identified with "a combination of Google research and the International Spiders and Bots List, maintained by the Interactive Advertising Bureau", and adds the part that matters most here: "you cannot disable known bot traffic exclusion or see how much known bot traffic was excluded", per Google Analytics Help.

A CRM has no such list. Spam sits there as records until someone removes it, and disqualified leads stay too. One number is filtered by Google's judgement, the other by the client's sales process.

The tag needs permission, the form does not

A form posts to a server. A measurement tag runs in the browser, and only if it is allowed to. That asymmetry is the single largest cause here.

In Google's own description of consent mode, the basic implementation means "you prevent Google tags from loading until a user interacts with a consent banner", and until then "no data is transferred to Google at all". The advanced implementation loads tags with consent defaulted to denied, and "consent state and measurements without cookies are sent", which feeds modelling rather than a measured event. Either way, a visitor who declines still submits the form, and that lead still lands in the CRM.

Ad blockers do the same from the other end, stripping 30-40% of events before they leave the browser, and on a standard browser-side setup 15-30% of conversions are consistently never captured. The browser-side count is structurally lower, and what goes missing is not a random sample of what arrives. The mechanics of that loss are worth the detour.

The measurement sits in the wrong place

Two common setups fail in opposite directions, which is why the gap changes sign.

Counting the submit records an attempt. If the backend then rejects it, a validation error or a required field the form let through, the event was already sent and no lead exists. A thank-you page records an arrival instead, so it misses anyone who closes the tab during the redirect and counts anyone who reloads or shares that URL.

When a form or booking widget is embedded from another domain, the surrounding page cannot observe it at all. It has, in MDN's words, "very limited access" to it, and communication between documents from different origins has to go through window.postMessage. A submit listener on the parent page never sees it unless the embedding tool publishes an event, and some do not.

The two reports are not looking at the same days

A reporting day is a setting. Google notes that "the beginning and end of each day is calculated based on Los Angeles Time, even if the hit comes from New York, London, or Moscow", and that changing it "only affects data going forward, and is not applied retroactively", per Google Analytics Help. Two systems on two time zones disagree at every month boundary, and fixing the setting does not repair the history you reported.

The second date problem depends on the stack: a CRM report may be keyed on when the record was created, which for an integrated form can be when the sync ran rather than when the visitor submitted. Confirm which one it uses.

Some of those leads never touched a form

Phone calls, email replies, live chat, an imported list, a record a salesperson typed up after a meeting. All leads in the CRM, none of them form submissions. Before calling the difference data loss, subtract what was never going to appear in a form report.

What good looks like

Drop the goal first. The two numbers will not become identical, and a setup that promises otherwise is selling something that does not exist. What good produces is a difference that is small, steady, and explainable. Four things make that possible.

One system owns the lead count. For the client report that is almost always the CRM: it sits closest to revenue, and it is where a lead is judged good or bad. Analytics and the ad platforms own a different job, optimisation. Two owners of one number is an operational problem, not a tracking one.

Count the lead the server accepted, not the click on the button. Move the measurement point behind the submission and send the event from a server rather than the browser, out of reach of most of what was dropping it. That is the job Archon Signal does, and it recovers 15-40% more conversions than a browser-side setup. Read that as a gain against today's baseline, not a finish line. Consent refusals, blockers and network failure keep roughly 95% of events a ceiling nobody reaches, so a residual difference is by design.

Keep one identifier on both sides. Reconciliation only works if a lead in the CRM and an event in the report can be matched. Google Ads' offline conversion import is built on exactly that, telling you to "save these IDs along with whatever lead information you collect from the person who clicked your ad", per Google Ads Help. Without a shared key you are comparing two totals, which is arithmetic, not diagnosis.

Reconcile on a schedule, against one written definition. Same date range, same time zone, one agreed answer to what counts as a lead: before or after deduplication, before or after spam removal, with or without the channels that never touch a form. One page, once a month.

And the honest limit. If the form is native to the client's own domain, consent rates are high, and the difference is already small and steady, you have most of what this work would buy. It pays off when the gap is large, when it moves, or when budget decisions are being made on the lower number.

FAQ

Which number should we put in the client report?

The CRM number, with the analytics number beside it and the difference labelled. The CRM sits closest to revenue, so it is the number the client already believes. One line explaining the difference stops the discussion restarting every month.

GA4 shows more form submissions than the CRM has leads. Is GA4 wrong?

Not necessarily, and this direction is common. The usual causes are repeat submissions collapsing into one CRM contact, submissions the backend rejected after the event had fired, a thank-you page counted more than once, and the same conversion sent twice by two setups built at different times.

Can we push the CRM leads into the reporting and be done with it?

You can send CRM outcomes back into the ad platforms, and for optimisation that is usually right. It does not repair browser-side collection though: it changes what you report, not what was collected, and it needs the shared identifier plus a consent basis that permits it. What may leave a client's CRM is a question for their legal counsel.

How close should the two numbers be?

There is no benchmark worth quoting, and anyone who hands you one is guessing. It depends on the consent rate, whether the form is embedded from another domain, whether the CRM deduplicates, and how much of the lead flow arrives by phone or email. A specific setup has a defensible expected difference. The category does not.

If you want to know how much of a client's gap is counting, how much is consent, and how much is genuinely missing, a free tracking audit answers that.