Conversion tracking

Your reports are wrong,and the algorithmknows it.

When events go missing two things break at once. You make budget decisions on numbers that undercount reality, and Meta optimises on a thinner signal than it should. Server-side tracking closes both gaps.

Book a meeting See the reconciliation panel

Where events disappear

Four leaks. None of them visible in Ads Manager.

Leak 01

Blocked at the browser

Content blockers stop the pixel loading at all. The visit happens, the purchase happens, the event never exists. Nothing anywhere tells you it occurred.

Leak 02

Cookies expire early

Safari and Firefox cap the lifetime of the cookies connecting a click to a conversion. Longer consideration cycles fall outside the window and attribute to nothing.

Leak 03

Thin identifiers

Events arriving with only a browser ID match poorly to real people. Low Event Match Quality means weaker attribution and worse optimisation on identical spend.

Leak 04

Double counting

Server events added without a shared ID inflate conversions instead of recovering them. The numbers look better and the decisions get worse.

The build

What we actually install.

Step 1

Audit and baseline

Every tag catalogued: what fires, what duplicates, what is missing, match quality per event, consent behaviour. Written up with fixes ranked by what they are costing you. Yours to keep whether or not we work together.

Price: $490
Turnaround: 3–5 days

Step 2

Server-side container

A tagging server on your own subdomain, so requests are first-party rather than third-party. The browser talks to your domain; your server talks to Meta.

Step 3

Deduplicated event pairs

Each conversion fires twice carrying one shared event_id. Meta merges the pair, keeps whichever arrived, and counts it once. This is the difference between recovering data and inventing it.

Step 4

Match quality repair

Hashed email, phone, name and location added to the server payload alongside click and browser identifiers, so Meta can resolve events to real accounts.

Step 5

Offline and CRM conversions

For businesses closing on the phone or on site, the sale is uploaded back to Meta and joined to the ad that started it. The highest-leverage fix available to anyone with a sales call in the middle.

Step 6

TikTok, built the same way

TikTok has its own server-side route, the Events API, and it deduplicates on a shared event_id exactly as Meta does. If you run TikTok alongside Meta, the same event feeds both from one source, so neither platform double-counts and neither is left guessing.

Step 7

Verification and handover

Tested in Events Manager against live traffic, documented, and handed over inside your own accounts. No agency-owned containers holding your data hostage.

Screenshots, not claims

What a finished build actually looks like.

These are from ZenithCart, a demonstration store we built and instrumented end to end so this page would have something to show. Nobody commissioned it. It exists because a tracking agency that only describes its work is asking you to take a lot on trust.

Meta Events Manager showing browser and server events marked Deduplicated — **The one that matters**Events Manager, Test Events. Each conversion arrives twice — once from the browser, once from the server — carrying one shared `event_id`. Meta marks the second copy **Deduplicated** and counts one sale.

Events Manager showing Event Match Quality of 8.0 out of 10 across five events — **Event Match Quality 8.0 / 10**Across all five events, from Multiple integrations. This is the number that decides how well Meta can match an event to a real person, and most accounts we audit sit far below it.

Server container tag firing a Conversions API request returning POST 200 — **The server call, succeeding**The Conversions API tag firing from the server container: `POST 200` to `graph.facebook.com`. Not a tag that exists — a tag that returned.

Server container variables showing event_id and hashed customer identifiers — **What travels with the event**The shared `event_id`, the click and browser IDs, and hashed customer identifiers. Values blurred here; in production they are hashed before they leave the server.

Google Tag Manager web container listing Meta Pixel and GA4 tags — **The web container**Meta Pixel and GA4 on the same five e-commerce events, each on its own dataLayer trigger. No page-scraping, no guessing at clicks.

Tag Assistant showing every tag fired and none failed — **Every tag fired, none missed**Tag Assistant on a completed order. **Tags not fired: None.** That line is the whole job.

ZenithCart is a demonstration build, so the orders in it are test orders. What is real is the configuration — the same container structure, the same deduplication, the same identifier set we install on a live account.

Evidence

A full implementation, screenshot by screenshot.

Claims about tracking are cheap, so here is a build you can inspect. This is ZenithCart — a WooCommerce store we stood up ourselves to prove the stack end to end, because a client's dashboard is not ours to publish. Every screen below is from that build.

**01Web container, tagged event by event**Meta Pixel and GA4 side by side on a live WooCommerce store — five ecommerce events each, every one on its own dataLayer trigger rather than a blanket All Pages rule.

**02Every tag fired, none missed**Tag Assistant on the order-received page. Eleven tags fired across the session, and the "not fired" list is empty. That empty list is the part worth reading.

**03What the server actually sends**Inside the server container: the shared `event_id`, the click and browser IDs, and the hashed identity fields that let Meta match an event to a real account. Personal values blurred.

**04Conversions API returning 200**The CAPI tag firing on a purchase, with the outgoing request to `graph.facebook.com` and Meta’s response beside it. A tag that fires is not the same as a tag that lands.

**05Deduplicated, in Meta’s own words**Test Events showing the browser and server copies of the same PageView and Purchase, sharing one `event_id`, and Meta labelling the second copy deduplicated. This is the whole point of the build.

**06Event Match Quality 8.0 / 10**All five events active and scoring 8.0 across the board. Most accounts we audit sit in the fives before the identity fields are wired properly.

ZenithCart is our own store, not a client's. We built it so this page could exist. The same stack, wired the same way, is what goes onto your site — and you will get the same screenshots from your own dataset once it is running.

Check us first

Deduplicated events, running on this site right now.

Send the contact form. The browser fires a Lead event and our own server fires the same event to the Conversions API, both carrying one shared event_id. The panel on the home page prints both as they happen. Open Meta Pixel Helper, open your network tab, do whatever you like.

A brochure site has one conversion, and it already happens on the server, so we send it from there directly. A full tagging server on your own subdomain is what we build for stores and lead-gen sites, where page views, product views and checkouts all need to survive an ad blocker. We would rather say which of the two you are looking at than let the distinction blur.

A tracking agency that asks you to take its own tracking on trust is the wrong agency.

Book a meeting See the full rate card