Send the platforms data they can act on.

It is the server-to-server route for sending conversions to an ad platform, instead of relying on a browser tag that can be blocked, cleared or simply never fire. Meta's documentation describes it as connecting your server, website platform, app or CRM data to the systems that optimise delivery and decrease cost per result. The setup matters because the API rewards precision: the right events, the maximum lawful match parameters, correct deduplication with the pixel, and consent handled properly. Done well it is one of the highest-return pieces of engineering in a paid account; done casually it feeds the bidding system double-counted noise.

We prefer published numbers to promises. Meta reports that advertisers running the pixel who added the Conversions API saw on average 13% lower cost per action, and its April 2026 figures — reported by PPC Land — put accounts with a web CAPI setup at 17.8% lower cost per result than accounts without one. On the Google side, enhanced conversions is credited with 8% incremental ROAS on Search for value bidders across 99 lift studies. Your own gain depends on how much signal you are currently losing, which is exactly what the audit measures before we quote the work.

It is a reasonable floor and a poor ceiling, and we will happily tell you when it is all you need. Automatic integrations typically send a thin set of events with a handful of match parameters, name events inconsistently with your pixel, and leave deduplication to chance — which is how reported conversions end up inflated. They also know nothing about what happened after the form: the qualified lead, the closed deal, the refund. The work worth paying for is the part a plugin cannot do, so we usually keep the simple integration running while we build the proper one, then switch cleanly with deduplication verified.

It is Meta's 1-10 rating of how well your server events can be matched to real accounts, and its best-practice guidance is explicit that the score reflects how effective your customer information is at matching. Below about 6 the platform is guessing; above 8 it has what it needs. Improving it is mechanical rather than mysterious: send every identifier you lawfully hold, normalise formats, hash to spec, and pass the click and browser identifiers through correctly. Meta also exposes Additional Conversions Reported, so the benefit of the integration can be read as a number rather than debated.

No, and we would not build it that way. Server-side delivery changes where an event is sent from, not whether you were allowed to send it. Our setups respect consent signals on the server as well as in the browser, exclude restricted and sensitive categories by design, and configure data processing options where regional rules require them. Raw customer data stays in your systems; only hashed identifiers leave. We document the whole flow so your legal or privacy team can review exactly what is sent and on what basis, which is a much better position than discovering it during an audit.

Not when it is engineered correctly, and this is the most common failure we are called in to fix. The intended architecture is redundant on purpose: the browser and the server both send the conversion, and the platform keeps one because both carry the same stable event ID and event name. We verify deduplication on live traffic rather than trusting the setup, then reconcile a full week of platform totals against your orders or CRM so any remaining difference is a known, explained quantity. Refunds and cancellations are fed back too, so cancelled revenue does not keep teaching the bidding system.

Yes, and for lead-generation accounts it is usually the single highest-value part of the project. Sending the qualified lead, the booked appointment or the closed deal back to the platform lets bidding optimise toward customers instead of cheap form fills, which is a different account within a month or two. We map the stages that genuinely predict revenue, assign values to them, and automate the feed from your CRM rather than relying on manual uploads. Where the reporting side also needs rebuilding, our analytics team handles that in the same engagement.

One event layer, many destinations. We define the conversions once, with one set of definitions and values, then feed Meta's Conversions API, Google enhanced conversions and offline imports, TikTok's Events API, LinkedIn, Microsoft and whichever others you buy — plus GA4 for analysis. That is how you avoid the common mess of four platforms counting four different numbers with no shared definition. It also means adding a new channel later is a configuration task rather than another integration project.

You find out from an alert rather than from a bad month. Integrations do degrade: platforms deprecate API versions, a checkout release drops a parameter, a plugin update renames an event. We monitor event volume, error rate and scores continuously and alert on meaningful drops, keep the integration on a supported API version, and review it whenever your site or CRM changes materially. Because everything is documented and conventional, your own developers can also diagnose it — we build so that you are never dependent on us to keep measuring.

Less than most teams expect, and we keep the list short on purpose. Partner access to the ad account and the Facebook Business Manager or Google Ads account; the dataset or pixel we will be sending to, plus permission to create an access token for it; access to your tag manager container; and a short session with whoever owns the website, app or CRM so we can agree how events will be sent. If you already run a server-side container we will use it. We create the tokens inside your own business settings rather than ours, so nothing we build depends on a Web Tonic account, and we send a written access checklist before the first call so nobody has to hunt for it live.

Yes, for a straightforward setup, and we are happy to help you get there — a lot of our work is training an in-house team rather than replacing it. The broad steps are: open Events Manager, create or select the dataset, generate an access token, decide which events to send and with which parameters, add the server integration, set a stable event ID so the browser and server copies deduplicate, then verify in the test tools before trusting anything. Meta's own best-practice documentation is a good reference for that path. Where teams typically want help is the harder half: identifier coverage, CRM feedback, consent handling and reconciliation against real orders.

We can, and the loop closes faster when the team reading the signal is the team spending the budget — our paid social and paid search teams work from the same event definitions. It is equally fine to buy the measurement engineering on its own while another agency buys your media; we hand over the documentation, brief their team, and report honestly on the performance the cleaner signal produces. Good measurement should be useful to whoever is running the account.