Website Tracking Audit: Is GA4 Counting Real Leads?

A website tracking audit checks whether analytics records the actions you actually care about, in the correct property, at the correct moment, without counting them twice. For a service business, that means following an inquiry from the website to its destination. A button click is a clue. A successfully delivered inquiry is a different thing.

I chose this topic because my own reporting raised an uncomfortable question: was I evaluating the website's performance, or evaluating the parts of its performance that happened to be recorded? Before commissioning more content or changing an offer, I want to know which of those questions the dashboard can answer.

What made me put tracking ahead of another traffic report?

In a Double Atari GA4 report for September 6 through October 3, 2026, the production hostname recorded 42 Organic Search sessions, 19 engaged sessions, and zero recorded key events. The organic landing-page report also contained 10 sessions with the landing page shown as “(not set).” These are first-party reporting observations, not results from a tracking repair.

That does not establish that the website generated zero inquiries. It establishes what this property recorded under those reporting definitions. Until I verify the inquiry events and their destination, I cannot turn a zero in that column into a reliable business conclusion.

The account also contains more than one property named Double Atari. One returned no rows for that period; the other returned activity from the live hostname and some preview-host traffic in other channels. That is a practical reason to verify property, stream, hostname, and filters before trusting a familiar name in a dropdown.

For this snapshot I used the reporting property ending in 8036, whose timezone is America/Los_Angeles, and checked the live hostname separately. Organic Search here is the channel reported by GA4, not a hand-matched total of Google clicks. I am not presenting these figures as a new conversion rate or claiming the underlying implementation has been fixed.

How is a website tracking audit different from an SEO audit?

An SEO audit asks whether people and search engines can find and use the right pages. A tracking audit asks whether the evidence used to evaluate those pages is trustworthy. They overlap, but they have different acceptance tests.

A page can load quickly, be indexed, and have good content while its form-success event never fires. Another site can record dozens of supposed conversions because it marks every contact-button click as a lead. Both deserve attention, but neither problem is solved by adding more keywords.

My broader technical SEO audit checklist helps assess the website itself. The workflow below focuses on the measurement chain: action, event, report, and real-world record.

What should count as a lead before you touch Google Tag Manager?

Write a plain-language definition first. For a contact form, I would usually start with “the application accepted a valid inquiry and created the expected record or delivery confirmation.” Then I would separately test whether the message reached the team responsible for responding.

Google's recommended generate_lead event measures a generated lead, such as a submitted request for information (GA4 recommended event reference). I would connect it to a verified success signal, not merely the user's attempt to submit.

This separation makes a report less flattering and more useful. A business owner can still see early signs of interest without being told that every tap is a sales opportunity.

What should you check in the property, stream, and page tags?

I would start with an inventory: the intended GA4 property, web stream and measurement ID, any Tag Manager container, direct Google tags, relevant CMS plugins, and the hostnames sending data. The goal is to identify the active implementation, not to install another tag because the report looks empty.

Then I would test representative templates, not just the homepage. Include a blog post, service page, contact page, confirmation state, and any external booking flow. Check whether the expected page view and inquiry events reach the intended destination.

Duplicate instrumentation is a hypothesis to test, not a conclusion to jump to. A hardcoded tag and a container may coexist intentionally, or they may send the same event twice. Watch the actual requests and event sequence. Do not remove either implementation until you understand what it does.

I would also document preview and internal traffic separately. If a test hostname appears in production reports, decide how future reporting should treat it. Do not silently filter history and then present the new total as if it were directly comparable with the old one.

How do you test a form without accepting a false positive?

Use a test inquiry that the receiving team recognizes, with permission to run the test. Start in an agreed testing environment where possible. The purpose is to inspect the full path, not to generate mystery leads for a client.

1. Submit invalid information. The form should show the appropriate validation state without recording a successful lead.
2. Submit a valid test inquiry. Confirm that the application accepts it, the record or message arrives, and one intended success event is sent.
3. Refresh the confirmation state. Check whether the implementation incorrectly records another inquiry without another submission.
4. Try the mobile experience. Follow the same path on a narrow screen and check any embedded form or booking step.
5. Inspect reporting. Confirm the event destination and parameters, then verify how it appears in reporting after processing.

GA4 DebugView displays collected events and parameters in real time when debug mode is enabled; Google also notes that privacy controls or denied Analytics-cookie consent can prevent events from appearing there (Google's DebugView documentation). Test consent states respectfully rather than treating missing data as permission to bypass a visitor's choice.

Marking an event as a key event is a separate configuration step, and Google says the change does not retroactively change historical data (Google's key-event setup guidance). A valid event that is not configured as intended can leave the reporting question unresolved even when the underlying action is collected.

What does “(not set)” tell you about landing pages?

It is a missing-value signal, not a secret landing page and not a diagnosis by itself. Google says “(not set)” can appear for the landing-page dimension when a session has no page_view event (Google's explanation of “(not set)”).

For my site, the 10 organic sessions in that bucket are a reason to inspect collection, not a reason to redistribute them among popular pages. I would compare the relevant events, templates, consent behavior, and session context. Until the cause is verified, the honest label is “unresolved landing-page attribution.”

The same restraint applies to the gap between Search Console clicks and GA4 sessions. I would check source scope, date boundaries, consent and collection behavior before expecting agreement. Google-only search activity and an Organic Search channel report are not interchangeable measures.

How should you handle visits from AI assistants?

I would add a separate observation layer rather than relabel every ambiguous visit as AI traffic. Where a recognizable assistant referral is present, preserve the original source information, document the grouping rule, and test whether a later inquiry can be connected at the reporting level available.

A missing referrer is not evidence of an AI visit. Nor does a visit prove that an assistant repeatedly recommends the business. My AI visibility tracking guide treats visibility as its own question; a tracking audit checks what the website can observe after arrival.

For a low-traffic site, the most useful improvement may be mundane: one correctly measured inquiry path, an understandable source report, and a note about what remains unobservable. That is a stronger foundation than a custom dashboard built on untested events.

What should the audit deliver?

I would expect an event map, a list of tested paths, evidence of pass or fail, a prioritized repair list, and a repeatable verification procedure. Each finding needs a consequence: double-counted inquiries, missing success events, mixed test traffic, or an unresolved source boundary.

For every proposed repair, specify an owner and an acceptance test. “Fix conversions” is not enough. “One accepted inquiry creates one intended event; invalid submissions and confirmation-page refreshes do not” is something a developer and business owner can evaluate together.

After implementation, annotate the change date and avoid treating the new measurement baseline as business growth. More recorded leads may mean better collection, better performance, or both. My reporting framework keeps those interpretations separate.

If your dashboard cannot answer whether the website is generating real inquiries, analytics and reporting consulting can start there. You do not need a prettier chart before you need a number you can trust.

Frequently asked questions

What is a website tracking audit?

A website tracking audit checks whether analytics records the intended actions in the right property and at the right moment. It reviews tags, events, forms, consent behavior, source reporting, and the connection between a recorded event and a real inquiry. The deliverable should include tested evidence and a prioritized repair plan.

Does zero GA4 key events mean my website generated no leads?

Not necessarily. It means the report recorded no key events under the selected property, dates, filters, and configuration. Before treating that as a business result, verify the inquiry event, its key-event setting, consent behavior, and the real records where inquiries arrive. Missing or incomplete measurement can produce a misleading zero.

Should I count a contact-button click as a lead?

I would report it as an expression of interest, not as a successfully generated lead. A click does not establish that a form was accepted or a message arrived. Keep contact clicks, accepted inquiries, qualified inquiries, and customers separate so the report does not overstate results.

What should I receive from a GA4 tracking audit?

Ask for a property and tag inventory, an event map, tested inquiry paths, pass-or-fail evidence, and prioritized findings with owners and acceptance tests. The audit should explain which business questions the current data can answer and which remain unresolved. Implementation and post-fix verification should have clearly defined scope.

Will fixing GA4 tracking repair the old numbers?

Do not assume it will. Document when each measurement change takes effect and preserve the distinction between the old and new baselines. A rise in recorded inquiries after a repair may reflect better collection rather than an immediate improvement in website performance. Reconcile historical business records separately where they are available.