Key Takeaways
- A received enquiry and a recorded GA4 event are different pieces of evidence. Do not expect their totals to match automatically.
- Track a meaningful form-success signal, not merely a click on the submit button or a visit to an unprotected thank-you page.
- Check consent behaviour, the correct property, event names, browser requests and reporting filters before changing the dashboard.
- Keep customer names, email addresses, phone numbers and message content out of ordinary analytics events and URLs.
- Use a controlled test log to identify the missing stage. Never bypass a visitor's privacy choice just to make the numbers look complete.
Website enquiries can be missing from GA4 because the analytics event did not fire, the browser did not send it, the wrong property received it or the report is looking at a different definition of a lead. Consent choices, privacy controls and reporting delays can also explain some gaps.
Start by confirming the enquiry exists in the operational system: the form service, inbox or CRM. Then trace the measurement journey separately. A real email does not prove that analytics worked, and an analytics success event does not prove that an email arrived.
The aim is not to force every dashboard to display the same total. It is to understand what each number means, fix genuine faults and label the remaining limits honestly. That produces a more useful marketing conversation than arguing over an unexplained difference of one lead.
Define What Counts as an Enquiry
Before opening a tag manager, agree the business event you want to measure. A submit-button click is an attempt. A server accepting valid form data is a stronger signal. A qualified sales enquiry is a later judgement made by the team.
Give these stages different names in your measurement plan. If every stage is called a conversion, it becomes impossible to tell whether an increase means more interested people or simply more repeated clicks.
Google's recommended event documentation includes events intended for common business interactions. Use an appropriate event name and a clear internal definition. The implementation still needs to send it at the correct moment; choosing a recommended name does not create reliable tracking by itself.
A useful definition might be: “Count one website enquiry when the contact endpoint accepts a valid submission. Record later qualification in the CRM.” That is a proposed measurement rule, not a universal requirement. A business using phone calls, bookings or partner referrals will need additional definitions.
Draw the Journey Before Testing It
Write the route as a series of independent stages:
- A visitor completes the fields.
- The browser sends the form request.
- The receiving service validates and accepts it.
- The website displays a success state.
- An email or CRM record is created.
- An analytics event is sent, where the implementation and privacy choices allow it.
- GA4 processes the event into reports.
Your actual system may put these steps in a different order. Document that order rather than forcing the diagram to match an assumption. A form can accept data while an email provider fails later. A browser can close after the successful request but before a client-side event is transmitted.
For a broader reporting setup, our GA4 guide for business owners provides context. This checklist concentrates on the gap between an operational enquiry and its analytics record.
Build a Controlled Test Log
Use test details owned by your business, not a real customer's personal information. Tell the team which tests to expect and avoid triggering sales follow-ups, bookings or paid actions unintentionally.
Record a time, page, device, consent state and non-identifying test reference. Keep the log in an authorised internal location. It should help you compare systems without turning GA4 into a copy of the inbox.
| Test | Form accepted | Inbox or CRM received | Analytics request sent | Event visible |
|---|---|---|---|---|
| Valid form, expected consent state | Check | Check | Check | Check |
| Missing required field | Should not be accepted | Should not create a lead | No success event | No success event |
| Repeated submit click | Check duplicate handling | Check duplicate handling | Check event count | Check event count |
| Visitor declines relevant tracking | Form should remain usable | Check delivery | Behaviour follows policy | Record expected limitation |
This table is a testing template, not a claim about your current site. Fill it with observed results. A blank cell is an open check, not evidence that the stage passed.
Check the Property and the Event Name
Confirm that the deployed website sends data to the property you are viewing. Staging and production can easily use different measurement IDs, and an old tag may remain after a redesign.
Inspect the actual published configuration rather than a draft container. Note whether tags are installed directly, through a plugin, through a tag manager or through more than one route. Duplicate installations can produce the opposite problem: more events than enquiries.
Check spelling and capitalisation. Two similarly named events are not necessarily the same event. Also check whether the report uses total events, users or key events. Those measures answer different questions.
If the event exists but is absent from a particular report, investigate the report's conditions before rebuilding the tracking. Filters, date ranges, selected streams and the chosen metric may explain the difference.
Do Not Confuse Form Interaction with Accepted Data
Google's enhanced measurement documentation describes form-start and form-submit interactions. Those can be useful, but a recorded browser interaction should not automatically be treated as proof that your business accepted and received a valid enquiry.
Test your actual form technology. Some forms update without navigating to a new page. Others are embedded from another service. Some display a thank-you message before a downstream integration finishes. A general tracking rule may not match those behaviours.
Where possible, base the business-success event on an explicit accepted response from the form system. Check that invalid submissions do not fire it and that retrying a request does not count the same accepted enquiry repeatedly.
Avoid using a thank-you-page view as the sole proof if that page can be reopened, bookmarked or reached without submitting. If your setup uses such a page, document the limitations and consider a more reliable success signal with the developer.
Use Debugging Tools for the Question They Can Answer
Google Analytics DebugView helps inspect events from a debug-enabled device. It is useful for checking event names and parameters during controlled tests. Google also notes that privacy controls and consent settings can affect whether events appear there.
Use the browser's network tools or an appropriate tag-debugging view to check whether the request was attempted and what the response was. A missing request points you towards event logic, loading or consent behaviour. A sent request with the wrong destination points towards configuration.
Do not leave debugging enabled for every visitor unnecessarily. Keep the test bounded and record the configuration used. DebugView is not a full sales-attribution report, so use normal acquisition and outcome reporting for longer-term analysis.
If several systems are involved, a scoped analytics and reporting review should produce this evidence trail, not only a screenshot of a green tag indicator.
Respect Consent and Privacy Controls
A visitor may submit an enquiry while declining analytics tracking. The website still needs to process the enquiry appropriately, but that does not mean every analytics identifier or event should be collected regardless of their choice.
Check the consent-management configuration, the order in which tags load and the behaviour after a choice changes. Test the expected states separately. Do not disable the banner or route events through a server as a shortcut around privacy requirements.
For UK requirements, consult the current ICO guidance on cookies and similar technologies and assess the actual technology and purpose. Rules and guidance can change, and a generic analytics checklist is not legal advice.
Keep personal form content out of analytics payloads. Inspect page URLs, query parameters, event labels and error messages as well as obvious fields. A thank-you URL containing an email address can leak information even if the event itself has no email parameter.
Check Reporting Windows and Filters
Compare the same dates and time zones. A late-evening enquiry can fall on different calendar days in an inbox, server log and analytics property. Record the original timestamp and convert consistently before calling the event missing.
Distinguish immediate debugging from processed reports. Do not treat a normal report as a second-by-second delivery monitor. Recheck after the relevant processing period and document when the comparison was made.
Review internal-traffic and developer-traffic filters, hostname restrictions and any custom report conditions. A test performed from the agency's connection may be intentionally excluded. That can be correct behaviour, provided the test plan accounts for it.
Also separate event counts from people. One person can send several enquiries, and one enquiry can accidentally produce several events. Neither total becomes a trustworthy lead count until you understand the counting rule.
Reconcile Outcomes Without Inventing Attribution
Build a small comparison between accepted enquiries, delivered records, qualified leads and measured analytics events. Keep unknowns visible. If an enquiry has no reliable source, mark it unknown rather than assigning it to whichever campaign you hope worked.
Our guide to a content marketing dashboard explains how different reporting sources fit together. They should support one another without being presented as identical populations.
Where a tracking repair affects marketing decisions, involve the people responsible for conversion-rate optimisation and the website's form implementation. Otherwise, the reporting team may optimise against an event that the website team interprets differently.
Keep a short change log: what was wrong, what changed, which tests passed and from what date the measurement definition became reliable. Do not compare a newly corrected event count with an old broken count as if it proved a marketing improvement.
Finish with an Evidence-Based Diagnosis
The result should be a specific statement, such as “the accepted form response never triggered the event”, “the event was sent to the staging property” or “this test was excluded by the documented privacy configuration”. Each explanation should point to evidence.
If the cause is still uncertain, say so and name the next observation needed. Ask us to review the tracking journey with a redacted test log and the relevant page URL. You do not need to share customer messages to begin.
A reliable report is not the one with the biggest lead total. It is the one that tells the business what was measured, what happened operationally and which parts remain unknown.
Frequently Asked Questions
Should GA4 lead events exactly match the enquiries in my inbox?
Not automatically. The systems record different stages, and consent choices, filters, repeated submissions and technical failures can create differences. Define each measure and reconcile controlled examples before comparing totals.
Is a form-submit event proof that an enquiry was delivered?
No. It can describe a browser interaction without proving that the receiving system accepted the data or delivered an email. Test the form response and downstream record separately, and use a clearly defined success signal.
Why is my test event missing from DebugView?
Check debug mode, the measurement property, the event request and privacy settings. Consent or client-side controls can prevent an event appearing. Also check whether your test traffic is subject to filters in the report you are using.
Can I send customer email addresses to GA4 to match enquiries?
Do not send customer names, email addresses, phone numbers or message text in ordinary GA4 events or page URLs. Use a privacy-reviewed measurement design and keep operational customer records in the appropriate authorised system.
Will fixing the event show all the enquiries that were missed before?
Do not assume it will. A tracking fix normally improves collection from that point onwards. Keep historical operational totals separate, document the change date and avoid presenting reconstructed figures as events GA4 actually observed.
