Tracking Check
A tag that exists is not yet a tag that fires.
Mateq checks your tracking where it actually happens: in a real browser. Click the elements, watch what fires, read the outbound requests — and give every event a plain verdict.
What is a tracking check?
A tracking check answers whether the signals Google Ads and Meta need for sound optimization decisions are actually present and working. It tests three layers — is the configuration there, does it fire on a real interaction, does a request leave the browser — plus, where server-side tracking is set up, whatever of that path is observable.
Why "looks configured" proves nothing
Inside Tag Manager a setup usually looks complete: tags are listed, triggers are attached, variables exist. Whether anything happens when someone clicks the button is not shown there. So the most common fault is not a missing tag but an existing tag that never fires — because a trigger points at a CSS class that disappeared in the last relaunch.
The second most common is the opposite: an event fires twice because a plugin reports the same thing as well. In reports that looks like strong performance — until conversion counts stop matching revenue.
And then there is the alarm that justifies the whole exercise: a campaign accumulating clicks with exactly zero conversions for days. That is more often a broken signal than a broken campaign — and expensive, because meanwhile the bidding strategy optimizes against garbage.
The layers being checked
Every configured event runs through the same chain. A layer only becomes meaningful once the one before it holds.
1. Configured
Does the expected configuration exist? Mateq reads the live published GTM container for this, not a draft.
2. Triggered
Does the event fire on a real interaction? Mateq actually clicks the elements in a browser — destructive labels like "Buy now" are excluded.
3. Observed
Does a request to GA4 or Meta leave the browser? That outbound request is the last layer provable from outside.
4. Server-side path
Where server-side tracking is set up, Mateq checks what is observable: DNS and SSL on your tracking subdomain, and the published server container.
Consent context
On sites with a consent banner, events legitimately do not fire before consent. Mateq knows the common CMPs and judges accordingly.
Health overview
Seven dimensions — GTM, GA4, Meta Pixel, server-side, consent status, configured events, account connections — with a clear status instead of a score.
What a verdict looks like
An extract from a check across one website's configured events:
- form_submit
- verified — dataLayer push and outbound GA4 request observed
- add_to_cart
- needs attention — GTM tag exists, did not fire on the interaction
- purchase
- could not test — sits behind login and payment
- newsletter_signup
- verified with a note — fires twice per interaction
The interesting one is "add_to_cart": the configuration is complete, but the trigger references a class that no longer exists after the relaunch.
The wording is deliberate: "observed" means the request left the browser — not that the platform booked it.
Where an honest check stops
From outside you can prove a request was sent toward GA4 or Meta. What happens inside the platform — processing, attribution, deduplication — is not visible. So Mateq says "observed", not "arrived". Anyone promising "confirmed in GA4" is promising more than an external check can deliver.
Second: a check is a snapshot. Tracking breaks on an ordinary Tuesday — through a release, a plugin update, or a container edit. So Mateq repeats the run weekly or daily depending on plan and raises critical findings as alerts.
Third, some events cannot be tested from outside at all: anything behind login, payment, or an order system. Those are reported as "could not test" rather than quietly passed.
From finding to fix
When the check finds gaps, it does not stop at a list: for the typical cases — missing or mis-wired tags, triggers, and variables — Mateq can apply the correction in the container and publish it, with your approval. For everything else the report names the affected place concretely enough to fix it directly.
The diagnostic run is deliberately read-only: it changes neither your website nor your container, it reads and observes.
Common questions about tracking checks
My campaign has clicks but zero conversions — why?
How do you check whether a GA4 event really fires?
What if the site has a consent banner?
How often should tracking be checked?
Find out whether your numbers hold
Connect the website, run the check, get a verdict per event — with a clear statement of what was observed.