Clarvivo

Free tool by Clarvivo · no login

See the GA4 events your page is actually sending

Paste a page URL. We load it in a real browser, decode its GA4 requests, and show which events fired, which parameters they carried, and whether a tag is counting the same event twice.

Page to inspect

Paste the page where an event should fire. We load it in a real browser and translate the GA4 requests into the events, parameters and duplicate tags that affect your reports.

This tool answers: Which GA4 events fire on this page, and are any firing twice?

Enable JavaScript to run the check — the diagnosis itself is free and needs no account.

Why this happens

GA4 can look configured while the event that matters never reaches it. A trigger can be scoped to the wrong page, consent can hold it back, a JavaScript error can stop it, or an old hard-coded tag can keep firing beside your current Tag Manager setup. The browser does not show any of that to a visitor.

Network requests do show it, but they are a poor debugging surface. GA4 compresses event names and parameters into a request that is difficult to read, and automatic events such as page_view and user_engagement make a short list of intentional events hard to spot.

The expensive failure is duplication. Two GA4 tags can make every pageview, lead or purchase look twice as large while leaving the site visually perfect. This check turns that request stream into a short, named list you can compare with the events you intended to send.

Next checks

These answer the questions this one tends to raise.

How this check works

So you can trust the result — and your developer can verify it.

  1. We read the requests GA4 receives

    The browser captures /g/collect requests as the page loads and, when GA4 batches events, separates every event in the batch. We report the measurement ID and the event name rather than asking you to decode protocol parameters.

  2. Automatic and configured events stay separate

    page_view, session_start, scroll and user_engagement are useful signals, but they are not proof that your configured conversion event worked. We group those automatic events so the events you deliberately added are easy to see.

  3. We compare like-for-like events on the same load

    A repeated page_view or purchase in one page load is not normal navigation. We flag it with the timing and measurement endpoint so you can trace whether a theme snippet, a GTM container or a trigger is responsible.

Common causes and fixes

A theme tag and Google Tag Manager both fire
This often happens during a migration: the new GTM container is installed correctly, but the original gtag snippet remains in the theme. Every event reaches one or two properties depending on the configuration, so totals are misleading without an obvious site error.
The event trigger does not match the page state
Single-page apps can change a route without a page reload. A trigger that relies on a traditional page load may never see the state where the form succeeds, while another trigger may fire once on load and again on the history change.
Consent or a page error blocks analytics
If GA4 is absent entirely, that does not prove it is uninstalled. A consent manager may be waiting for a choice, or an earlier browser error may have stopped the script. The result includes observed page errors and the tracking stack to help separate those cases.

Frequently asked questions

Why does the inspector show automatic events I did not create?
GA4 sends several events through enhanced measurement and session handling by default, including page_view and user_engagement. They are normal. We list them separately so they do not get mistaken for a configured conversion event.
Can this test a form submission or purchase?
Not by itself. The scan loads the page and follows one safe internal link; it never submits a form, logs in or buys anything. Use the URL where the event fires, such as a thank-you page, and use the event list to verify that page's tag behaviour.
Does seeing a purchase event prove revenue is correct in GA4?
No. It proves that the browser sent an event. Revenue can still be wrong when value, currency or transaction_id are missing, or when server-side events differ. Compare your totals with Shopify using the Revenue Gap Analyzer for that second part.
What does more than one measurement ID mean?
It means the page sent events to multiple GA4 properties. That may be an intentional roll-up setup, but it is commonly an abandoned tag left beside the current one. Check that every listed property is intentional before comparing reports.

An event firing is only the start of the revenue trail.

Clarvivo connects page activity to payments, so you can see which events became revenue instead of treating every browser event as a successful conversion.

Trace events through to revenue

What this tool reads, and what it keeps