The Conversions API in plain words: why send events from the server

A pixel is a piece of code on the page. When a visitor does something, for example sends a lead, the code in their browser tells the ad platform. From these messages the platform learns which ads work and looks for similar people.

The scheme is simple, but it has a weak spot: everything depends on the visitor's browser.

Why the pixel doesn't see everything

A message from the pixel may never arrive, for several reasons:

• the visitor has an ad blocker, and the pixel's script simply didn't load;
• the browser limits tracking on its own and deletes cookies quickly;
• the page is open in an app's built-in browser, which behaves in its own way;
• the visitor closed the tab before the request could leave.

For the platform, such a lead doesn't exist. The report shows fewer conversions, the cost per lead looks higher, and above all the algorithm learns from incomplete data.

What the Conversions API does

Meta's Conversions API and TikTok's Events API let you report an event from the server. The lead reached your server, and it, not the buyer's browser, sends the lead to the platform. Blockers and browser settings don't affect that.

Server-side sending doesn't replace the pixel, it works alongside it. The pixel in the browser sees what the server can't: a page view, scrolling, a press of a button. The server reliably reports what matters most: the lead and the purchase.

How not to count a lead twice

If a lead went from both the browser and the server, the platform receives two messages about one event. For it to understand they are the same, both must have the same event name and the same identifier: the event_id field.

The simplest way is to use the lead's id as the identifier. It's the same in the browser and on the server, and it never repeats.

If the identifiers differ or are missing, conversions in the report double. It's one of the most common mistakes in a do-it-yourself setup.

What to send with the event

To link an event to the person who clicked the ad, the platform needs hints:

• the click id: fbclid for Meta, ttclid for TikTok;
• the pixel's cookies, if there are any: _fbp and _fbc, and _ttp for TikTok;
• the visitor's IP address and browser;
• the phone as a hash, not in plain text.

The more of this data there is, the more often an event finds its click. In Meta's dashboard this is shown as event match quality.

A Purchase when payment is on delivery

In an ordinary online store the purchase happens on the site, and the Purchase event is straightforward. When a product is paid for on delivery, the site only has a lead. The real purchase happens a few days later, when the person picks up the parcel, and it's the CRM that learns about it, not the site.

That gives two approaches.

Teach the algorithm on leads. There are many events and they arrive at once. But the algorithm finds people who readily leave a lead, not people who buy out.

Send a Purchase by the status from the CRM. When the order is confirmed or bought out, the server sends a Purchase with the amount. The algorithm gets a signal about real buyers.

The second approach has a limit: an ad network links a purchase to a click only within its attribution window. If the parcel travels longer, the event arrives but isn't tied to the ad. That's why many send the Purchase already when the order is confirmed: it happens in the first hours after the lead and cuts off those who didn't pick up the phone or declined.

Whichever you choose, spam shouldn't go to the ad platform at all: neither as a lead nor as a purchase.

How to check that it all works

1. Send a test lead from your site.
2. In Meta Events Manager, open the pixel and find the Lead event. It should have two sources: browser and server.
3. Check that the event is marked as deduplicated rather than counted twice.
4. Look at the match quality: if it's low, the server lacks data about the visitor.

And keep an eye on the token. It can expire or lose access, and then server events stop being accepted while the site goes on working as if nothing happened. It's better to learn that from an alert than from a report at the end of the week.

In short

• The pixel loses some leads to blockers and browser limits.
• Server-side sending delivers leads and purchases reliably.
• The browser event and the server event need the same identifier.
• With payment on delivery, a Purchase is best sent by the status from the CRM.

In Tersby all of this is set up in one place: the pixel and Conversions API are connected by entering an identifier and a token, and the event id, the visitor's data and the Purchase by order status are sent for you.