A conversion report is only useful if the events behind it fire correctly. A site release, a cookie banner change, or a renamed form can silently break a GA4 event, and the first sign is usually a number that looks too low during a monthly review. By then weeks of data are unusable. A short QA checklist after every change keeps GA4 conversions trustworthy without a full tracking audit.
Confirm which events are key events
GA4 marks important actions as key events, and those are the ones reported as conversions. Start by listing the key events your business depends on: form submits, demo requests, trial signups, purchases, and any offline import you rely on. For each, write the exact event name and the page or flow where it fires.
Then confirm in the GA4 admin that each event is actually marked as a key event. A perfectly firing event that is not marked will not appear as a conversion. Conversely, a leftover test event marked as key inflates the count. Keep the list short and current.
Use DebugView to watch events fire in real time
GA4's DebugView lets you watch events as they happen. Open it, then perform each tracked action on the site yourself, on both desktop and mobile. Watch for the expected event name, its parameters, and whether it fires once or multiple times. A form that fires the submit event twice, or on every keystroke, is a common bug.
DebugView requires a debug mode enabled through your tag setup or an extension. The GA4 documentation at support.google.com/analytics covers the current ways to enable debug mode and read DebugView; check it for your specific tag manager setup because the steps differ by implementation.
Verify the parameters that matter
An event is only as useful as its parameters. For each key event, confirm the parameters your reports use are present and populated: form name, value, currency, item identifiers, or lead source. A purchase event without a value cannot report revenue. A form event without a form name cannot be split by form.
Run through one real submission for each event and check the values in DebugView against what you expect. Pay attention to data types; a value arriving as a string instead of a number can break revenue calculations.
Check for duplication and missing events
Duplication is subtle. A tag firing from both a page-level and a form-level trigger can double every conversion, making performance look better than reality. Compare the DebugView event count for one submission against the number of times you submitted. If it does not match, find the extra trigger.
Missing events are the opposite problem. Confirm the event fires on the actual production URL, not just a preview, and that redirects in the flow do not cut it off. A form that redirects to a thank-you page before the event sends will lose the conversion.
Test after every site or tag change
Make the QA a required step after any change that touches pages, forms, cookies, or tags. The trigger is not a calendar date; it is the change itself. A release that renames a CSS class used by a form trigger, or that moves the thank-you page, can break tracking without touching the tag configuration.
Run the same checklist each time: list the key events, fire each one in DebugView, confirm parameters, confirm the count, and confirm the event is marked as a key event. It takes a few minutes and prevents a month of bad data.
Check consent and data collection settings
If your site uses a consent banner, confirm that analytics and advertising storage behave as intended for consenting and non-consenting visitors. Test both paths, because a change to the banner can inadvertently block events for everyone or send data before consent. Record what the expected behavior is so the test has a pass condition.
Also confirm that internal traffic and developer traffic are excluded so test sessions do not pollute conversion data. GA4 supports filters for this; a quiet test that reaches production without exclusion can distort small-sample reports.
Document the event schema so QA is repeatable
Write a short event schema: the event name, where it fires, the parameters it should carry, and whether it is a key event. Store it with the QA checklist so anyone can run the test without reverse-engineering the tag setup. A schema makes a rename or a removal visible and turns a vague "is tracking working" question into a specific pass or fail.
Version the schema with a date. When it changes, the QA log should say so, because a changed event name is one of the most common causes of a sudden drop in reported conversions.
Compare GA4 against a second source
Where possible, cross-check a key conversion against a second system, such as the CRM or the email platform that receives form submissions. If GA4 reports 40 leads and the CRM received 55, investigate before trusting either. A persistent gap usually points to a tracking gap, a spam filter, or a step that does not reach GA4.
Keep a short QA log with the date, the change that triggered the test, the events checked, and any issue found. When a number looks wrong later, the log shows whether tracking is the likely cause. The operator runs the checklist and reports exceptions; the owner approves any change to tracking configuration or consent behavior. To have this QA run for you, review how we run marketing analytics, or request a consultation with your current GA4 setup.
