GA4 Lead Tracking Audit: Find Broken Events Before Reporting

Checks before the next stage

Use these checks on real pages, accounts or workflows. Record pass, fail, not applicable and unknown separately; an unknown item is a research task, not an automatic failure.

• Event dictionary defines primary outcomes
• Test submissions reach the destination
• Success trigger fires once
• Validation errors do not count as leads
• UTM and landing context persist appropriately
• Consent behaviour is documented
• Personal data is excluded from analytics
• GA4 totals reconcile with received records
• CRM quality feedback is aggregated safely

Prioritise any failure that affects customer trust, access, measurement or a large group of pages. Cosmetic improvements can follow after the delivery system is safe and understandable.

Define what counts as a lead

Teams often label page views, button clicks, form starts and completed enquiries with the same commercial meaning. Look for the failure in the live journey rather than in a presentation. This is especially important for marketing teams whose dashboards show leads that sales cannot reconcile because the operating goal is to build a dependable chain from user action to received enquiry and commercial outcome.

Action to take

Create an event dictionary that separates diagnostics, completed actions, qualified leads and sales outcomes. Each event should have an owner, trigger, expected parameters and a reason it supports a decision. Do not mark every available event as a key event simply because the interface allows it. Write the decision, owner and evidence beside the work so a later review can distinguish a deliberate trade-off from an accidental omission.

Run deterministic form and call tests

Real traffic is difficult to debug when multiple sessions, devices and spam submissions overlap. Fix the cause closest to the customer before optimising a proxy. This is especially important for marketing teams whose dashboards show leads that sales cannot reconcile because the operating goal is to build a dependable chain from user action to received enquiry and commercial outcome.

Action to take

Use timestamped test cases for each form, phone route and thank-you state, then record expected versus observed results. Test success, validation failure, resubmission and blocked-script conditions on mobile and desktop. Avoid concluding that a tag works after seeing only one debug-mode event. Write the decision, owner and evidence beside the work so a later review can distinguish a deliberate trade-off from an accidental omission.

A practical implementation roadmap

Complete the sequence in order unless evidence shows a dependency should move. Each step should leave a usable record for the next person rather than relying on memory.

1. Inventory tags, forms, calls and destinations. Assign an owner, expected evidence and review date. At step 1, confirm that the previous decision still matches the live customer or operational context.
2. Define expected events and parameters. Assign an owner, expected evidence and review date. At step 2, confirm that the previous decision still matches the live customer or operational context.
3. Run timestamped test cases. Assign an owner, expected evidence and review date. At step 3, confirm that the previous decision still matches the live customer or operational context.
4. Remove duplicate or competing triggers. Assign an owner, expected evidence and review date. At step 4, confirm that the previous decision still matches the live customer or operational context.
5. Reconcile and document acceptable differences. Assign an owner, expected evidence and review date. At step 5, confirm that the previous decision still matches the live customer or operational context.

Pause expansion if the team cannot explain what changed or if accepted work is not reaching production. More activity will not repair a missing decision owner.

Find duplicate and missing attribution

Tags can fire twice through overlapping containers, history changes or both click and success triggers. Retest the complete path after the change. This is especially important for marketing teams whose dashboards show leads that sales cannot reconcile because the operating goal is to build a dependable chain from user action to received enquiry and commercial outcome.

Action to take

Inspect Tag Manager, site code and platform integrations for competing implementations and document the chosen source. Preserve landing-page and campaign context with the lead where privacy and consent permit. Never send personal form values into analytics event parameters. Write the decision, owner and evidence beside the work so a later review can distinguish a deliberate trade-off from an accidental omission.

A measurement table that supports decisions

Choose a small set of signals that expose both progress and quality. Read them together; no single metric proves commercial value or causes a ranking, sale or citation.

Set definitions and data sources before setting targets. Where volume is small, use qualitative evidence and longer review windows rather than presenting unstable percentages as certainty.

Reconcile marketing events with sales records

Analytics counts sessions and events, while the inbox or CRM records people and opportunities under different rules. Look for the failure in the live journey rather than in a presentation. This is especially important for marketing teams whose dashboards show leads that sales cannot reconcile because the operating goal is to build a dependable chain from user action to received enquiry and commercial outcome.

Action to take

Compare daily aggregates and a controlled sample, then explain expected differences such as consent, blockers and duplicate handling. Return qualified or disqualified outcomes at an appropriate privacy-safe level so optimisation reflects business quality. Do not force exact equality when the systems intentionally measure different populations. Write the decision, owner and evidence beside the work so a later review can distinguish a deliberate trade-off from an accidental omission.

Questions to resolve with the team

Send these questions before the review. Written answers make assumptions visible and reduce the chance that a persuasive meeting replaces an operating decision.

1. What exact user action creates a primary lead? Ask the person who owns inventory tags, forms, calls and destinations to provide the evidence.
2. Can every test event be found in the receiving system? Ask the person who owns define expected events and parameters to provide the evidence.
3. Which implementation is authoritative? Ask the person who owns run timestamped test cases to provide the evidence.
4. How will qualified outcomes return without personal data? Ask the person who owns remove duplicate or competing triggers to provide the evidence.

A responsible answer can include limitations and unresolved dependencies. “We do not know yet” is useful when it is followed by a test, owner and decision date.

Editorial sources and verification

This guide combines Searchar’s operating framework with the following primary guidance. Platform documentation can change, so verify implementation details against the current source before a material release.

• Google Analytics: events and key events ↗