How to Test Whether Your Website Tracking Is Working

What “working” actually means

A tracking setup is working when the numbers it reports correspond to things that really happened, no more and no less. For any important action on your site, that breaks down into five checks:

1. It fires. When the action happens, the event is recorded.
2. It fires once. Not twice because the tag is installed twice, and not again when the visitor refreshes the thank-you page.
3. It fires only on success. A form that fails validation, or a booking that is abandoned, records nothing.
4. It carries the right data. Form name, location, language, value and source are present and correct.
5. It respects consent. Tags behave as configured when the visitor accepts, declines or never answers.

Everything below is a set of scenarios for checking those five things. If you are planning a launch, these tests belong in the conversion tracking plan as acceptance criteria. If you are auditing an existing site, they sit alongside the configuration review in our GA4 setup and audit checklist.

The tools, and how to set up a clean test

You need no special software. The standard kit:

• Your tag manager’s preview or debug mode, which shows which tags fired on each action and why.
• GA4’s debugging view, which shows events arriving in near real time with their parameters.
• The browser’s developer tools, specifically the network panel, where you can filter for requests to Google, Meta, LinkedIn and others and see exactly what was sent. This is the ground truth when the other tools disagree.
• The ad platforms’ own test or diagnostic views, where they exist, to confirm events are received and deduplicated.
• Access to the form tool, inbox and CRM, to confirm the other end of every test.

Work through the scenarios on a staging copy of the site first if one exists, then repeat the important ones on the live site, because the two rarely behave identically: different domains, different consent settings and sometimes different versions of the tag container.

Test in a private or incognito window so old cookies and stored consent choices do not hide problems. Use a recognizable test name and email address so test records can be found and removed. And agree beforehand how test traffic is kept out of the reports, either by filtering it or by doing the testing in debug mode, which most properties exclude from standard reporting.

Form scenarios

Forms are where most tracking breaks and where it matters most. For each primary form, run:

• The happy path. Fill it in correctly and submit. One event, with the right name and parameters, at the moment success is confirmed.
• A validation error. Leave a required field empty and submit. Nothing should fire. If something does, the tag is firing on click rather than on success, and your counts include every frustrated visitor.
• Error, then success. Trigger the error, fix it, submit. Exactly one event, not two.
• The double click. Click submit twice quickly. Still one event.
• The refresh. Reload the thank-you page. If it fires again, a page-view trigger is counting reloads and bookmarks as leads.
• Mobile. Repeat on a real phone. Mobile layouts sometimes use different form components or modals.
• Each language. On a bilingual site, test the French form separately. It is often a different form, built later, by someone else, without tracking.
• Every placement. If the same form appears in a footer, a pop-up and a landing page, test each one.
• Embedded and third-party forms. Forms loaded from another service inside your page often do not report success in a way tags can see. Confirm what you are actually detecting.

Consent scenarios

Consent testing is the step most often skipped, and the one most likely to reveal a setup doing something nobody intended. Clear cookies before each scenario.

• No choice made. Load the site and do not touch the banner. Check the network panel: which tags send requests, and what do they send? This should match what your organization decided tags may do before consent.
• Decline all. Advertising pixels should not fire tracking requests. Analytics should behave as configured, which may mean nothing, or only limited signals if your organization has chosen that approach with its counsel.
• Accept all. Everything fires as specified.
• Partial choices. Accept analytics, decline advertising. GA4 should work; the Meta and LinkedIn tags should not track.
• Change of mind. Accept, then reopen the preferences and withdraw. Tags should stop on the next page.
• Returning visitor. Close the browser, come back. The previous choice should be remembered and respected.

A common finding is a banner that records a choice beautifully and controls nothing, because the tags were installed directly in the site rather than through the tool the banner talks to. Our article on privacy-conscious measurement in Canada covers why that matters beyond the numbers.

Pixels, bookings and handoffs

• Ad pixels. Each platform’s conversion fires once, on the same success moment as GA4. If you also send conversions server-side, confirm both browser and server events share an identifier so the platform counts one, not two. The tradeoffs are covered in client-side vs server-side conversion tracking.
• Duplicate installs. Look for the same tag loading twice, once hard-coded and once through a tag manager or plugin. In the network panel it shows as two identical requests.
• Cross-domain journeys. Click from your site to the booking engine, store or payment page, complete a test transaction if you can, and return. Confirm the session continues and the conversion is credited to the original source, not to the payment processor.
• Phone and email links. Tap them on a phone. Confirm the secondary event fires, and that it is not marked as a primary conversion by accident.
• Campaign parameters. Visit the site through a link tagged with test UTM values, browse a few pages, then submit a form. The values should survive to the form and into the CRM.

Test the whole chain, not just the tag

A tag that fires correctly is half the job. The other half is confirming that the lead arrives where the business uses it. For each test submission, check:

• The form tool recorded it.
• The notification reached the right inbox or person.
• The CRM created or updated the right record, with source, medium, campaign and landing page filled in.
• Any automation that should follow, such as an assignment or a confirmation email, happened.

Then, a few weeks after any significant change, compare totals across GA4, the form tool and the CRM for the same period. They will not match exactly, for reasons covered in why GA4 and your CRM report different lead numbers, but the gap should be explainable and stable.

Keep a test log, and know when to retest

Write down each test: the scenario, the date, who ran it, what was expected and what happened. A simple shared document is enough. It turns “I think the tracking works” into evidence, and it tells the next person what working looked like.

Tracking rarely breaks on its own. It breaks when something near it changes. Rerun the relevant scenarios after:

• Any website release that touches forms, templates or navigation.
• A plugin, theme or CMS update.
• A change to the consent banner or its settings.
• A new tag manager version being published.
• A new campaign platform, booking engine or CRM integration.

If conversions fall suddenly, measurement is the first suspect, as our guide to diagnosing a drop in website conversions explains.

A ten-minute check for a non-technical owner

You do not need to read network requests to get a useful signal. Once a quarter, an owner or executive can:

1. Open the site in a private window on a phone and decline the cookie banner. Then accept it on a laptop.
2. Submit the main inquiry form once from each, with “TEST” in the name.
3. Ask the team to show both submissions in the CRM, with their source, and the accepted one in GA4.
4. Ask when the tracking was last tested, and to see the log.

If anyone hesitates on step three or four, that is your answer. If both records appear with a sensible source, and only the accepted one appears in GA4, the basics are in good shape, and the detailed scenarios above are being run by someone.

When we take on analytics and measurement work, these scenarios are run before any report is built, because a dashboard on top of untested tracking is just a more attractive way to be wrong.