Meta Conversion API Send the sale from your own server.

Meta charges nothing for it. What you are paying for is the connection: agreeing which sales the server reports, giving each one a shared reference so it merges with the browser copy, attaching real values, scrambling the matching details, carrying consent through both halves, and proving it with live orders. A single site with one enquiry form is a much smaller job than a store with a checkout and a booking system. For clients we run Meta advertising for it is part of the engagement; standalone it is a fixed price after a free audit.

The build usually runs two to three weeks, most of which is testing rather than connecting. You will see reported conversions move within the first fortnight, and it is worth being blunt about what that means: you are not selling more, you are counting more of what you already sold. The genuine difference — Meta bidding from a fuller picture — shows up over the following month or two, and how much it moves depends on how much the browser was losing for you in the first place.

No long-term lock-in. The connection can be a one-off project, and you keep the setup, the event definitions and the documentation whether or not we work together again. Where it sits inside an ongoing Meta engagement we ask for enough runway to be fair to the work, because an account judged in its first fortnight is being judged while the reported numbers are still resettling. The terms are put in front of you in plain English before anything is signed.

You do. It runs from your own systems into your own Meta business account, and we are added with access rather than as the owner. The event definitions, the values and the documentation are yours, and if we part ways the connection keeps working. Measurement assets are yours outright — deliberately different to how an advertising build itself is handled, and it means leaving never costs you your measurement.

We keep going until the difference is explainable. A gap between Meta and your books is not automatically a fault — a customer who clicked in March and paid in May will sit in different columns — but an unexplained gap is. We check the references first, then the values, then the consent path, then the system the events are coming from. Where the honest conclusion is that the connection is not the thing holding your account back, we will say so rather than keep charging to tune it.

A fixed rhythm, good news or bad, in the language you use about your own business. Each report covers what was spent, what it produced, what we changed and why, and what happens next. Meta's numbers are set beside what actually happened in your business, and where the two disagree the gap is named and explained rather than smoothed over. You also get live access to see spend and performance for yourself at any time.

It is a second road for the same information. Normally your website's browser tells Meta that somebody enquired or bought. The Conversion API has your own system tell Meta directly instead — after the sale, from your server, with no browser in the middle. Nothing about the customer's experience changes. What changes is that the report arrives whether or not the visitor's browser was willing or able to send it.

Three things happened at once. Phone operating systems gave people a clear choice about being tracked, and many took it. Ad blockers became normal on desktop, and they block advertising scripts by design. And browsers began withdrawing the third-party cookies that browser-side measurement leaned on. The share of events lost is commonly put at around a third, but that is somebody else's average — the number worth acting on is the one measured on your own traffic, which is the first thing we do.

Not when it is built properly. Every sale is given one shared reference that travels with both copies. When the browser report and the server report arrive by their different roads, the platform sees the same reference on both and treats them as one event, keeping whichever copy is more complete. If the browser was blocked, the server copy stands alone. Getting that reference wrong is the classic way this goes bad, which is why nothing here goes live until a real order has arrived as one event.

Not in the form you are picturing. Where an email or phone number helps Meta match a sale to a profile, it is scrambled into a one-way value on your side before it leaves — Meta receives something it can compare, never the actual address or number, and the conversion cannot be run backwards. Consent is carried through the server as well as the page, so a visitor who declines is not reported by either road. And the promise we make everywhere else holds here: our learnings, never your data.

This is the part of your measurement that keeps working. The server side does not use third-party cookies at all — it reports from information your own business already holds, given to you directly by the customer, with their consent. That is why we build it alongside the pixel rather than as an upgrade to buy later. The businesses that will feel the cookie withdrawal hardest are the ones whose entire measurement lives in somebody else's browser.

Yes, and they are better together than either is alone. The browser half sees things the server cannot — pages viewed, how far somebody read, the behaviour that builds your follow-up audiences. The server half is what makes the sale itself arrive, whatever the browser was allowed to do. Run together with a shared reference, you get the full picture without double-counting. We build them as one job for that reason, and the Meta Pixel page covers the browser half in detail.