Event Tracking QA Checklist: How to Validate Before Launch

Why QA Is the Most Skipped Step in Analytics

Teams skip QA for three reasons: deadline pressure, “it worked in preview mode,” and the assumption that GA4’s real-time reports are validation enough. All three are wrong.

Preview mode isn’t production. GTM Preview runs in a debug container that behaves differently from live tags. I’ve seen events fire perfectly in preview and fail silently in production because of consent mode interactions, ad blockers, or CSP headers.

Real-time reports hide problems. GA4 real-time shows that events are arriving, but it doesn’t tell you if parameter values are correct, if events are duplicating, or if consent mode is properly blocking pre-consent events.

A proper QA process catches bugs before they corrupt your data. Fix a tracking bug on day 1 and you lose nothing. Find it 3 months later and you’ve lost a quarter of reliable data.

Step 1 — Verify Data Layer Output

Open your browser console and type dataLayer after performing each key action. Check:

• Event name — matches your naming convention exactly (see GA4 Naming Conventions)
• Parameters — all required parameters present, no typos in keys
• Values — correct data types (numbers are numbers, not strings)
• Timing — event fires at the right moment, not too early or too late

// Check: is value a number, not a string?
// ❌ Bad: { "value": "149.99" }
// ✓ Good: { "value": 149.99 }

// Quick validation in console:
dataLayer.filter(e => e.event === "purchase").forEach(e => {
  console.log("Value type:", typeof e.value);
  console.log("Currency:", e.currency);
  console.log("Items count:", e.items?.length);
});

The most common bug I find at this layer: value sent as a string instead of a number. GA4 silently accepts it but your revenue reports show zero.

Step 3 — Test Consent Mode Behavior

If you’re in Europe (and you should care about this everywhere), test four consent scenarios:

1. No interaction with banner: Only cookieless pings should fire
2. Deny all: No analytics cookies set, events fire in denied mode
3. Accept analytics only: Analytics cookies set, ad cookies blocked
4. Accept all: Full tracking active

For each scenario, check:

• Chrome DevTools → Application → Cookies — correct cookies present/absent
• Network tab filtered to google-analytics.com — gcs parameter matches expected state
• No events fire before the consent banner loads

This step catches the most dangerous bugs — silent data collection without consent. See the Consent Mode v2 guide for the full validation workflow.

Step 5 — Automated Monitoring After Launch

Manual QA catches launch-day bugs. Automated monitoring catches regressions weeks later when a developer changes a button class name and breaks your click tracking.

Option 1: E2E tests with Cypress/Playwright. Write automated tests that simulate user flows and assert dataLayer pushes:

// Cypress test: verify purchase event
it('fires purchase event with correct data', () => {
  cy.visit('/product/widget-pro');
  cy.get('[data-action="add-to-cart"]').click();
  cy.get('[data-action="checkout"]').click();
  // ... complete checkout
  cy.window().then(win => {
    const purchase = win.dataLayer.find(
      e => e.event === 'purchase'
    );
    expect(purchase.value).to.be.a('number');
    expect(purchase.currency).to.equal('EUR');
    expect(purchase.items.length).to.be.above(0);
  });
});

Option 2: Volume-based alerts. Set up a daily check (via BigQuery or a simple script) that alerts when event counts drop below expected thresholds. If purchase events drop by more than 30% day-over-day, something broke.

FAQ

How often should I QA my event tracking?

Run a full QA check before every release that touches the frontend or data layer. Set up automated monitoring for critical events like purchases and signups that runs daily. A quarterly full audit catches configuration drift.

What are the most common event tracking bugs?

Missing events on specific browsers or devices, incorrect parameter values (especially currency and revenue), duplicate event firing, consent mode not blocking events properly, and wrong event names after code refactoring.

How do I test consent mode behavior?

Use Chrome DevTools Network tab filtered to google-analytics.com. Deny all consent and verify no measurement hits fire. Then grant consent and confirm events resume. Check that the gcs parameter reflects the correct consent state.

Can I automate event tracking QA?

Yes. Use Cypress or Playwright to simulate user flows and assert that specific dataLayer.push calls occur. Combine with a monitoring service that alerts when event volume drops below thresholds.