Tracking breaks silently. A page that fails to load triggers immediate complaints; a conversion event that stops firing can go unnoticed for weeks, until someone spots a drop in the reports and discovers that a whole month of data is unusable. That is why checking measurement should be treated like any other quality check: with a procedure, before every release.
Why it breaks
The most frequent causes are mundane:
- a rewritten component that no longer publishes the event;
- a form that moves from a classic submission to an asynchronous call, so the event tied to the page change no longer fires;
- a changed URL, while a rule was looking for the old address;
- a new cookie banner that also blocks scripts the site needs to work;
- a property renamed in one place but not in the others.
None of these is a rare mistake: they happen in the normal evolution of a website.
Separate environments
The first requirement is not to pollute real data while testing. The test environment must send events to a destination other than production, or tag them so they can be excluded. That way you can test a purchase ten times without inflating recorded revenue.
A list of test cases
For each important event in the measurement plan, write a test case with the action, the expected result and the properties to check. An example:
| Action | Expected event | Properties to verify |
|---|---|---|
| Open a service page | page_view | page_type = service, correct language |
| Submit a valid contact form | form_submit | form_id, no personal data |
| Submit the form with an invalid field | no form_submit | error event, if planned |
| Download the price list | file_download | file name |
| Click the phone number | contact_click | method = phone |
The third case matters as much as the others: checking that an event does not fire when it shouldn't prevents false conversions.
Browser tools
For manual checks, the browser's developer tools are enough:
- in the network tab, filter by the collection tool's address and watch every request sent;
- check the request parameters: event name, properties, values;
- in the console, inspect the contents of the data layer after each action;
- repeat with an empty cache and in a private window, to simulate a new visitor.
Many analytics tools also offer a debug mode that shows events in real time. It is useful, but it does not replace the network tab: what counts is what actually leaves the browser.
Consent
The check should be repeated in at least two conditions: with consent given and with consent refused. In particular, verify that without consent the tools that require it send nothing and set no cookies. It is a check on measurement correctness, but also on respecting visitors' choices.
Devices and browsers
An event that works on desktop may not work on mobile, for instance because the menu uses a different component. You don't need to test every combination: the two or three browsers and devices most used by your audience are enough, and you can find them in the same analytics.
Automate the core
Manual checks are valuable but easily skipped when in a hurry. The main conversion events deserve an automated test: a script with an automated browser performs the action, intercepts network requests and verifies that the expected event fired with the right properties. Placed in the release pipeline, it blocks the deploy when something is missing.
After the release
Even with every check in place, something can slip through. In the days after a release:
- compare key event volumes with the same weekday of the previous week;
- check that recorded conversions reconcile with internal sources, such as emails received or orders in the management system;
- set automatic alerts if an important event drops to zero or below a reasonable threshold.
In my work, the «zero conversions in the last twenty-four hours» alert is the one that has saved the most data: simple, almost never wrong, and immediate.
Annotate
Every release that touches tracking should be annotated with a date and description. If three months from now a chart shows a step, the annotation immediately explains whether it is a real change or a measurement effect.
In short
- Tracking breaks silently: verify it before every release.
- Use a test environment that does not pollute production data.
- Write test cases for every event, including those that must not fire.
- Check network requests, with and without consent, on the main devices.
- Automate conversion tests and set alerts for drops after release.
