Verify your first event

A healthy setup produces one event with two sources: the browser copy and the server copy, carrying the same event ID. This page walks you to that evidence. If you only ever read one Getting Started page, make it this one — every other check on this site is a proxy for what you are about to look at directly.

Before you look

Three things will make a working setup look broken:

1. You are logged in as an administrator. If “Don’t track administrators” is on, nothing fires for you at all. Use a private window, logged out.
2. Your page cache is serving old HTML. Purge it after installing or updating.
3. You are watching Test Events in a different browser session than the one you are browsing in. This one produces a very specific and very convincing false alarm — see below.

Step 1 — set a Test Event Code

Copy the code from the Test Events tab in Events Manager and paste it into PixelCapi. With a test code set, server events go to the Test Events tab instead of your live reporting, and the plugin sends synchronously so results appear immediately instead of waiting for the queue.

Step 2 — browse your own site, logged out, in the same browser

Open a private window, load a product page, add something to the cart. Keep the Events Manager Test Events tab open in the same browser profile.

This matters more than it sounds. Test Events only displays browser events from the session that has the tab open. Browse in incognito while watching in your normal profile and you will see exactly one row, sourced Server, which flips to “deduplicated” after a few seconds — and no browser source, ever. That looks like a broken browser pixel. It is not. It is the Test Events tab doing what it is designed to do.

Step 3 — read the result

The healthy picture is one event row showing Processed from 2 sources: the browser copy processed, the server copy deduplicated. That is Meta telling you it received both halves and collapsed them into a single conversion.

If you only see a server source, and the row says deduplicated, that is still evidence the browser event arrived — Meta cannot deduplicate against something it never received. See Processed vs Deduplicated.

Step 4 — get the actual proof

Events Manager tells you what Meta thinks. Dedup Doctor tells you what was sent, from both sides, with the IDs to compare. Open it and look for rows like this:

Purchase          fdf4dd5f-9c31-4e02-9a8d-1c7b2f0e0476  browser  sent
Purchase          fdf4dd5f-9c31-4e02-9a8d-1c7b2f0e0476  server   sent   fbtrace_id …
InitiateCheckout  0f2a91c4-77bd-4c19-9f0a-3b6d5e2c8e11  browser  sent
InitiateCheckout  0f2a91c4-77bd-4c19-9f0a-3b6d5e2c8e11  server   sent   fbtrace_id …

Two rows per event, identical event IDs, both sent, and a platform trace ID on the server row. That trace ID is Meta’s own receipt for that specific send. A matched pair with a trace ID beside it is the strongest evidence available from outside Meta’s systems.

A full healthy funnel looks like this all the way down: PageView, ViewContent, AddToCart, InitiateCheckout and Purchase, each with the same ID on both sides.

If the IDs do not match

That is a real deduplication problem, not a display artifact. Open your browser’s network tab, find the facebook.com/tr request, read its eid parameter, and compare it with the event ID recorded in the plugin’s logs for that same page load. If those two differ, the browser and server halves are not paired, and every event is being counted twice. Start at Duplicate events.

Next

• Events don’t show
• Dedup Doctor