Inside VERA: checking GA4 events are wired before you trust the report

Short answer: every revenue decision built on GA4 assumes the events fire where you think they do. VERA checks the first link in that chain. For each event name you care about, it looks in each page's source for evidence that the name is wired as a tracking call, not just mentioned. It returns FOUND, WEAK, NOT_FOUND or a fetch error, with a snippet of the evidence.

Usage is in VERA: how it works. This is the scanner.

What you paste in

Two lists:

• Events: one per line, as name, key flag, notes. The flag counts as a key event if it's Y, yes, true or key. For example: generate_lead, Y, contact form submit.
• URLs: one per line.

VERA takes up to 30 unique events and 20 unique URLs, and checks every event against every URL.

The scanner, under the hood

For each page, VERA fetches the HTML (up to 400 KB) and runs two passes per event:

1. Quoted match. It looks for the event name in single quotes, double quotes or backticks, case-insensitive. If it's found, VERA reads 300 characters either side. If that window contains dataLayer.push, gtag(, googletagmanager, GTM-, a quoted event, or an event: key, the verdict is FOUND. If not, it's WEAK: the name is in a string, but not clearly as a tracking call.
2. Loose match. It looks for the name as a whole word anywhere. That's WEAK, because it could easily be page copy.

If neither pass matches, it's NOT_FOUND, and the advice depends on whether the page has any tagging at all: dataLayer, gtag, the GTM loader, a GTM- ID or a G- measurement ID.

• Tagging present: "Add the push". If it's a key event, treat it as P0.
• No tagging: check the container is installed on this template first.

What VERA can't see, by design

This is the most important part. Read it before you file a NOT_FOUND as a bug:

• Events set up inside Google Tag Manager (a click trigger, a form trigger) live in the container, not the page source. They can fire perfectly and still read as NOT_FOUND here.
• External JavaScript files aren't scanned. Only the HTML the server sends is read.
• Events added after the page loads, by a single-page app or a consent tool, may not be in the source at all.

So FOUND is strong evidence. NOT_FOUND on a page with tagging means "prove it in GA4 DebugView". It doesn't mean "it's broken".

Edge cases

• Common words as event names. An event called purchase or signup will match page copy. That's why a loose match is only ever WEAK.
• Case. Matching ignores case. GA4 doesn't: Generate_Lead and generate_lead are different events in reports. If the snippet shows a different case, that's a finding.
• Duplicates in either list are removed (events case-insensitively) before the run.

Worked example

Events:
  generate_lead, Y, quote form submit
  download_brochure, N, pdf click
URLs:
  https://samplebrand.test/quote
  https://samplebrand.test/brochure

/quote source: ...dataLayer.push({ event: 'generate_lead', form: 'quote' })...
/brochure source: GTM-SMPL123 loader, no 'download_brochure' anywhere

The key event is wired on the quote page, so confirm the payload in DebugView. The brochure event isn't in the source, but the container is. That's either a GTM trigger (fine, go and prove it) or a missing push. Either way, nobody should judge the brochure page's conversion rate until it's settled.

Run it: open VERA

The money angle

A key event that doesn't fire makes a good page look like a failure. Then the page gets redesigned, the budget moves, and the real winner is switched off. Checking the wiring takes minutes, and acting on a broken number can cost a quarter.

That's why VERA runs before LAND and DROP verdicts are trusted, and why tracking evidence is part of any traffic drop audit where revenue fell further than traffic.