Web analytics audit: what should you check?
Collecting numbers is not enough. Check whether conversions, events, consent, and reports can genuinely support a decision.
AT A GLANCE
A web analytics audit checks whether measurement gives reliable answers to the business questions that matter. Test important journeys end to end, compare browser actions with received events, verify consent behaviour, and identify missing, duplicated, or ambiguous data. The useful output is a prioritised repair list and a short measurement plan the team understands.
- Start with a business question, not an analytics menu.
- Test important journeys from beginning to end.
- Pair the findings with an event dictionary and a verification method.
1. Define the decision measurement must support
Choose three to five real questions before the audit. For example: which page precedes an enquiry, where does the contact journey fail, or how many submissions become validated leads? A metric without a decision or owner often adds reporting work without improving the business.
For each question, define the expected action, the success condition, and the period over which it makes sense. “More engagement” is too vague. “A contact request accepted by the server and followed by a visible confirmation” is a conversion you can verify.
2. Test important journeys end to end
Open a clean browser session and complete the same task you expect from a visitor. Record the pages, button or form, confirmation state, and event received by the measurement system. Repeat on mobile, with analytics consent denied and granted, and with an invalid submission.
If you use Google Analytics 4, Realtime and DebugView can help you observe test events. This does not prove long-term data quality, but it quickly reveals an event that never arrives, fires twice, or carries the wrong parameter.
3. Verify consent and data boundaries
Check what happens on the first page load, after acceptance, after refusal, and when a visitor later changes the setting. The choice should remain consistent on subsequent pages. Inspect network requests in browser developer tools instead of inferring behaviour from a cookie list alone.
Do not place form text, email addresses, search terms, or unnecessary identifiers in event data. Legal assessment depends on the actual processing and providers in use; a technical audit cannot replace that assessment.
4. Look for missing and misleading data
Compare a small set of manually verified actions with the report. Check whether refreshes, back navigation, repeated clicks, or failed submissions create false conversions. Review internal traffic, returns from payment or other external domains, and consistent handling of campaign parameters.
A mismatch does not explain its own cause. Record the time, browser, consent state, and test steps. A developer can then reproduce the fault, and the same scenario can verify the repair.
5. End with a repair order
Prioritise findings by impact and confidence. Start with faults that could support a wrong business decision, such as duplicated enquiries or an event containing personal information. Missing parameters and improvements to report clarity can follow.
Keep the handover practical: finding, evidence, affected page or event, proposed repair, owner, and verification step. Add an event dictionary so future reports do not depend on people guessing whether a conversion still means the same thing.
A PRACTICAL TEMPLATE
Web analytics audit worksheet
For each important journey, record the expected conversion, test steps, consent state, observed result, and verification of the repair.
- Business question and conversion
- Test steps and consent state
- Evidence and impact
- Owner and verification
Sources and further reading
- Monitor events in DebugViewGoogle Analytics Help · Checked: 2026-11-02
- Set up consent mode on websitesGoogle for Developers · Checked: 2026-11-02
Kristóf Borbély
The developer behind Kriside, writing practical guides about web systems, automation, and AI solutions.