Most conversion tracking is quietly wrong.

Because the browser pixel is the least reliable path you own. Ad blockers remove it, iOS restricts the cookies it depends on, and a slow or failed third-party script simply drops the event. A server event leaves your infrastructure, so it arrives whether or not the visitor's browser cooperated. The point is not to replace the pixel. It is to stop treating the browser as the only witness to a conversion that your own backend already knows about.

It does if you wire it up naively, and that is the most common way this gets built wrong. Both events have to carry the same event ID and the same event name so the platform collapses the pair into one conversion. Get it wrong and your reported cost per result halves overnight, which looks like a win until you scale spend against a number that was never real. We generate the ID once, pass it to both paths, and verify the deduplication in the platform's own event tooling rather than assuming it worked.

No, because the tracking call is never in the critical path. We dispatch server events after the response has already been returned to the user, using the edge runtime's background execution. The lead is saved and the confirmation is rendered, then the event goes out. A tracking outage cannot add latency to your form and cannot turn a successfully saved lead into an error message on the user's screen.

Normalising contact details to the exact form the platform expects, then hashing them so the raw values never leave your system. That normalisation is where most implementations quietly fail. On an Arabic-language site we found that JavaScript treats Arabic-Indic digits as non-numeric, so every phone number entered in Arabic would have hashed to an empty string and matched nobody, silently, forever. We also return nothing rather than guessing when a number does not fit the expected country format, because a fabricated identifier still hashes, still transmits a real person's contact detail, and still matches zero people.

We audit the events you are firing today against the pages that fire them. On one launch we found a single conversion event firing from 35 different URLs, because every unknown path and every project slug in the sitemap rendered the homepage and the homepage fired it. Any audience built on that signal was mostly people who scrolled past a banner. That audit costs a day and routinely finds the reason a campaign underperformed.

No. The pixel, the dataset, the access token, and the ad account stay in your business manager under your ownership, and the code lives in your repository. We build and verify the integration, then it is yours. If you want us to keep operating it we can, but nothing about the setup requires it.

It gets decided before the first event fires, not after. Sending hashed contact details is a different promise from the one most lead forms make, and if your form says the data is only used to contact the visitor, that sentence has to change before the integration ships or the copy becomes false. We flag that in the audit and ship the corrected wording alongside the tracking, in every language the site serves.