Skip to content

Browse the documentation

Events don't show — the ordered checklist

Seven causes in the order they are worth checking. Most ‘nothing is tracking’ reports are the first two, and both take under a minute to rule out.

updated

Work down this list in order and stop at the first thing that is true. It is ordered by how often each cause is the real one, not by how interesting it is — the first two account for most reports and take about a minute between them. Every item here comes from an actual debugging session, not from a list of things that could theoretically go wrong.

1. You are logged in as an administrator

If “Don’t track administrators” is on — and it usually is — nothing fires for you at all. No browser event, no server event, no log row. The site looks completely untracked while working perfectly for every real visitor.

Open a private window, logged out, and try again. This is the single most common cause.

2. Your page cache is serving stale HTML

A page cache does not know you updated a plugin. It keeps serving the HTML it already has, which does not contain the new tracker.

Purge your page cache after every plugin update. If you use LiteSpeed Cache and your symptom is settings that will not save rather than events that will not fire, that is a different and equally specific problem — see LiteSpeed and REST caching.

3. Test Events is scoped to one browser session

Test Events only displays browser events from the session that has the tab open. If you browse in incognito while watching Test Events in your normal profile, you see exactly one row, sourced Server, which flips to “deduplicated” after a few seconds — and the browser source never appears.

That looks precisely like a dead browser pixel and it is not. Browse and watch in the same browser profile. If administrator exclusion is in your way, turn it off temporarily.

4. No Test Event Code is set

Without a test code, server events go to your live reporting, not to the Test Events tab. The tab stays empty and everything looks broken while the events are landing correctly one screen over.

Set the code from the Test Events tab in the plugin. As a bonus, a test code also switches sending to synchronous, so results appear immediately instead of waiting for the queue.

5. Queue latency

Server events are queued and drained, not sent inline — that is what keeps tracking from slowing down a checkout. Under normal conditions the queue drains immediately, but a site with a blocked cron can lag.

Open the plugin’s log and compare statuses: queued means it has not gone yet, sent means it has. If rows are stuck at queued, the problem is your site’s task scheduling, not the tracking. Failed sends retry after 1 minute, then 5, then 30, and are marked failed after that.

If the consent source is set to a mode that expects a banner and no banner exists, there is nothing to grant consent — and the plugin fails closed. It blocks everything, browser and server, which is the correct behaviour and looks identical to being broken.

Check which consent mode is selected. If you are not running a consent tool yet, the source should be off.

7. An ad blocker in your testing browser

An ad blocker kills the facebook.com/tr request from the browser. The server-side event still arrives, because it never touches the visitor’s browser.

That asymmetry is normal and is the whole point of server-side tracking. But it means a blocked test browser shows you a server-only picture that is an artifact of your own setup.

Still nothing?

If all seven are ruled out, get the evidence directly:

  1. In the network tab, find the facebook.com/tr request and read its eid parameter.
  2. Find the event ID in the plugin’s log for that same page load.
  3. Compare them.

Same ID means pairing works and you are looking at a display problem. Different IDs mean a real deduplication fault — go to Duplicate events.

Was this page helpful?