Auditing our own analytics: why our sites weren't tracking leads, and what we fixed in a day

How it started

We run a daily traffic report for ourselves on two of our sites — sending ourselves yesterday's traffic, sources, pages, and AI search visibility in Telegram. While preparing one of these reports, we noticed the numbers: one site gets 6–18 visitors a day, the other gets 0–6. Compared to the number of leads that actually reach the sales department, that's clearly too few. We decided not just to note the low traffic, but to check whether analytics was even seeing the leads that do come in.

We started with the simplest question: how many times did the lead event fire on our sites over the last 28 days. The answer was uncomfortable — most of the events considered "key events" in Google Analytics hadn't fired a single time during that period.

What the GA4 audit revealed

The first thing that stood out: the list of key events in Google Analytics was made up of old names — things like "form_filled," "phone_click," "telegram_click," and a couple more like them. None of them had fired in 28 days. The reason was simple: when the forms and buttons on the sites were updated, the event names changed, but the analytics settings were never updated to match.

Second, one of the sites had no form events or session recording at all, while the other one did already have them. Third, the event meant to signal "lead confirmed" existed in the code but wasn't marked as a key event in GA4, meaning it never showed up in any summary reports or conversions.

We also counted the raw data separately: on the site where form tracking was at least partly working, the form-start event fired 8 times over 28 days. No submit or confirmation events were recorded during that same period. In other words, even if people were filling out the form, analytics wasn't seeing it.

If your analytics report shows "few leads" — first check whether the events are even reaching the report at all, and only then draw conclusions about traffic or conversion.

What the CRM revealed

In parallel, we checked our CRM — where leads from both sites actually land. Over 30 days, it recorded 4 leads, all via messenger. We found no entries tied to the "website" source at all. This means that even leads coming through other channels show no connection to the website — it's impossible to tell which page or which campaign brought them in.

What went wrong

We identified several specific problems, each small on its own, but together they effectively "blinded" our reporting:

• Key event names in analytics weren't updated after the form code changed — events kept their old names while new ones used new names, and none of the old names fired anymore.
• Nobody marked the lead-confirmation event as a key event — it technically existed but wasn't counted in any standard conversion report.
• On the second site, tracking for contact clicks and forms wasn't set up at all — on the site with the least traffic to begin with, we couldn't even see the minimal activity that did occur.
• Half of the visits on both sites were marked as "direct" traffic — and there was no filter for internal office traffic, meaning some of those "direct" visits could have been our own.
• The phone number listed on the site wasn't included in the list of numbers linked to our IP-telephony account — meaning calls to that number were also missing from the report.
• The site wasn't verified in Bing Webmaster Tools — so while Google Search Console had data, some search traffic from other systems remained invisible.

None of these problems was critical on its own — "an event not marked as key" sounds like a minor detail. But together they created a picture where leads from the sites were effectively invisible in both analytics and CRM, making it impossible to draw any accurate conclusions about site or ad performance from this data.

What we fixed in a day

Some problems could be closed without additional access rights — and we did that right away, that same evening:

• On the site that already had tracking for client actions, we added separate events for clicks on phone, email, Telegram, and messenger links — so we could see not just form submissions but every way people reach out.
• On the second site, which had no tracking at all, we rolled out the same set of events across all pages: contact clicks plus a complete form funnel — fill start, submit, and confirmation or submission error.
• On that same site, we added user session recording (the same tool already used on the first site) — so we can see exactly how people interact with the pages.
• We added UTM tags to the internal link from one site to the other, so that traffic between our own resources wouldn't get lost as "direct" traffic.
• We submitted page URLs for indexing directly to the search engine (via a separate service request), so we wouldn't have to wait for natural crawling.
• We updated our daily site report — adding data on contact clicks and session recordings for both sites, so these numbers would be visible every day, not just during a dedicated audit.
• We documented UTM tagging rules in a separate file — so that campaigns and internal links are tagged consistently going forward.

We verified everything on the list through the code and event logic, but we haven't yet reviewed it live in real time in analytics — that requires a separate run-through with a browser directly on the site, which is still on our to-do list.

What we couldn't fix the same day

Several items from the audit required rights our analytics service account didn't have — it only had view access, and any attempt to change something was met with an access-denied error:

• Marking new events (the lead, contact clicks) as key events — without this, they still won't appear in standard conversion reports.
• Setting a longer data retention period for events — currently data is kept for only 2 months, which isn't enough to compare seasonality or quarters.
• Setting up an internal traffic filter by office IP address — this option can only be enabled manually through the interface; it can't be set via API.
• Verifying the site in Bing Webmaster Tools and transferring data there from Google Search Console.
• Adding the site's dedicated phone number to the IP-telephony account, so calls from the website are counted in overall lead statistics.

All of these items are waiting on logging into the relevant services with editor rights — technically simple, but organizationally they require someone with account-owner access to make a few clicks.

Takeaways worth applying to your own site

A few rules we took away from this audit — and that we'd recommend checking if you assume your analytics is "all set up":

• Once a quarter, check whether the events marked as key in your analytics are still firing at all — after any update to form code, event names can "disconnect" from the report settings, and nobody will notify you about it.
• Check not just whether the analytics tag is installed on the site, but specifically whether form and contact-click tracking is set up on each site individually — especially if you have several sites that evolved at different times.
• Cross-check your analytics data against CRM: if CRM has leads that aren't in analytics (or vice versa), that's a signal that source attribution is getting lost somewhere.
• An internal traffic filter isn't a luxury — it's basic hygiene: if half your visits are marked as "direct," some of them could easily be your own team.
• The phone number on your site must be linked to the same call-tracking system as all your other channels — otherwise, some inquiries simply disappear from any statistics.
• Grant analytics service accounts broader rights from the start (editor, not just viewer) — otherwise, every fix turns into yet another access request and another wait.

Results in numbers

How this differs from a standard "client" audit

We regularly run similar analytics audits for clients, but this time we checked our own sites — and that's exactly why we spotted a classic trap: when a company trusts its own reports, it rarely re-checks them with the same skepticism it would apply to someone else's. The resulting fix plan turned out to be typical for any site: verify that events actually fire, cross-check with CRM, verify service account access rights, and only then draw conclusions about traffic or ad performance.

Frequently asked questions

Why did the old event names in Google Analytics just stop working instead of throwing an error?

GA4 doesn't warn you when an event with a given name stops coming in — it just disappears from conversion reports, because the system can't tell the difference between 'the event was turned off' and 'the event was renamed in the code.' The only way to catch this is to compare the list of key events in your settings against the actual event names currently being recorded.

Can you trust traffic data if there are problems with lead events?

Yes — visitor counts and traffic sources are tracked by a separate mechanism and usually don't depend on how specific events are configured. The problem here was specifically with action events (leads, clicks, forms), not with basic visit counting.

Why do you need editor rights, not just viewer rights, to mark an event as key?

The list of key events, the data retention period, and traffic filters are account-level analytics settings, not site content. The service account that reads data for reports is usually deliberately restricted to view-only access, to prevent any accidental changes — so changing these settings still has to be done by someone with full access.

Is it worth auditing analytics if a site already has low traffic?

Low traffic is exactly the reason to check more carefully: when you don't have many visitors, every lead lost to incorrect tracking is more noticeable as a percentage, and an error is harder to spot by eye among a small number of events.

What should you do if CRM and analytics show different numbers of leads?

Start by checking whether the site's lead event is actually linked technically to the CRM entry at all — often these are two separate systems that nobody has cross-checked directly. Then compare the time period and sources: analytics might count by button click, while CRM only counts once a manager has confirmed the lead.