What is Conversions API?

A conversions API is a server-to-server path for reporting events to an advertising platform. Instead of code in a visitor's browser sending a purchase event, the advertiser's own systems send it.

Meta's implementation gave the category its common name, and every major platform now offers an equivalent under its own.

The change of route is the whole of the idea, and it matters because the browser has become an unreliable messenger. Consent requirements, tracking prevention, content blockers and in-app browsing contexts all sit between a browser-side tag and the platform. None of them sits between the advertiser's order system and an authenticated server request.

Conversions the browser dropped. Sessions where the tag was blocked, where storage was unavailable, or where the browser closed before the event fired.

Events with no browser at all. Phone orders, in-store sales, subscription renewals, upgrades processed in a back office, contracts signed after a sales call.

Later outcomes. A lead that became a customer weeks after the form, an order that shipped, a purchase that was not refunded. These are the events that actually describe the business, and none of them exists at the moment a browser would have fired.

That last category is the one most accounts underuse. The common implementation sends the same purchase the pixel already sends, which improves coverage. Sending the downstream outcome instead — the qualified lead, the closed deal, the retained customer — changes what automated bidding pursues, and that is a larger improvement than the coverage.

The cost is engineering, and it is real but bounded.

A trigger in the right place. The event has to fire where the business records the outcome, which means inside the order system, the CRM or the billing system rather than on a page.

Identifiers. The platform needs enough information to match the event to a person: a hashed email address, a phone number, a click identifier captured when the visitor arrived, or several of these. Capturing and storing the click identifier at the point of arrival is the piece most often missed and it materially improves matching.

Consent handling. The server path has to respect the same consent state the browser path does. An implementation that sends events for visitors who declined has relocated a compliance problem rather than solved it, and the fact that the transmission is invisible to the visitor makes it worse rather than better.

Deduplication. Covered below, and the thing most likely to go wrong.

Monitoring. A server integration fails silently. Nothing on a page looks broken; events simply stop arriving.

Running both paths means the same purchase is reported twice — once by the browser, once by the server — and the platform has to discard one.

It does this with an event identifier that both sides send. When the platform sees the same identifier twice within its matching window, it keeps one.

The failure is an identifier that does not match between the two paths, and the symptom is a conversion count roughly double what it should be. That inflates every derived figure in a flattering direction: cost per acquisition halves, return on ad spend doubles, and the account looks as though something improved.

Because the error looks like good news, it survives for a long time. The only reliable detection is reconciliation against the business's own records, which is the argument for making that reconciliation a routine rather than a response to a suspicion.

It is still attribution. A conversion reported more reliably is still a conversion credited by a convention. Better coverage does not make the platform's claim about causation any stronger.

It does not improve matching on its own. An event sent with thin identifiers may not be matched to anybody, in which case it contributes nothing beyond an aggregate count.

It does not remove consent obligations. If anything it concentrates them, because the advertiser is now the party deciding what leaves their systems.

It does not replace the browser's context. Page sequences, on-site behaviour and the signals behavioural audiences are built from remain browser-side.

Start with the purchase or primary conversion, sent from the system that records it, with deduplication against the existing pixel.

Capture and store the click identifier at arrival, so later events can be matched to the advertising that produced them.

Reconcile for a month against the order table before trusting the figures or changing any bidding.

Then add the downstream events — qualified, closed, retained, refunded — which is where the real improvement to bidding lives.

Then monitor, with an alert on volume falling, because the failure is silent and the first symptom otherwise is a bidding strategy quietly losing its signal.

Two accounts can both send every conversion server-side and get very different results, and the difference is how well the events match to people.

The platform has to connect an incoming event to somebody it knows. It does that with whatever identifiers the event carries — a hashed email address, a hashed phone number, a click identifier captured at arrival, a device or app identifier, an address.

An event carrying one weak identifier may match rarely. An event carrying several matches far more often. The improvement from adding fields is usually larger than the improvement from any campaign change made in the same quarter, and it is invisible unless somebody looks at the match rate the platform reports.

The click identifier deserves particular attention because it is the strongest signal available and the easiest to lose. It arrives as a parameter on the landing URL, and it has to be captured and stored with the order at that moment. A business that does not capture it cannot add it later.

The implementations that change an account's performance are the ones that send outcomes rather than transactions.

In lead generation: the lead that was contactable, the lead that reached a sales conversation, the lead that closed, and the contract value when it did. Each is a stronger signal than a form submission and none of them exists in a browser.

In ecommerce: the order that shipped rather than the order that was placed, the purchase net of a refund, the customer's second order, the margin rather than the revenue.

In subscriptions: the trial that converted, the subscription that survived the first renewal, the plan that was upgraded.

Sending these turns automated bidding from a system that finds form fills into one that finds customers, which is the largest single improvement most accounts have available and requires no change to targeting, creative or budget.