The Meta Conversions API explained in plain English

The Meta Conversions API lets you send events such as leads, registrations and purchases to Meta from your own server, alongside the Meta Pixel that runs in the visitor's browser. Meta recommends running both, with the same event ID on each copy of an event so Meta counts it once. For coaches, course creators and agencies, the most useful thing it does is report purchases that happen away from your website, such as a payment after a sales call, so Meta's ad delivery learns who actually buys.

What the Conversions API is

Meta needs to know what happens after someone clicks your ad. Did they register? Book a call? Pay? Those results are called events, and they are how Meta measures your campaigns and decides who to show your ads to next.

There are two ways to send events:

• The Meta Pixel is a piece of code on your website. It runs in the visitor's browser and sends an event when something happens on the page, such as a form submission or a checkout.
• The Conversions API sends events from a server, meaning your own system or a tool you use, directly to Meta.

The pixel only sees what happens in the browser while your page is open. It can be blocked by ad blockers or browser privacy settings, and it misses anything that happens elsewhere. The Conversions API does not depend on the browser, so it can report events the pixel never saw.

Why use both

Meta's recommended setup is to keep the pixel and add the Conversions API. Each covers gaps in the other.

The pixel picks up browser details that help Meta connect the event to a person, and it fires the instant something happens on the page. The server sends events the browser missed, plus events that never happen in a browser at all.

That second group matters a lot for the businesses that read this blog. A high ticket coaching client often pays through an invoice, a payment link sent after a call, or a payment plan that charges each month. None of those payments happen on a page with your pixel on it. If you only use the pixel, Meta never hears about your real buyers.

Deduplication with a shared event ID

If the pixel and the server both report the same registration, Meta could count it twice. Deduplication prevents that.

The rule is simple. When the browser and the server send the same event, both copies carry the same event name (for example Lead) and the same event ID, a unique value you generate once for that action. When Meta receives two copies with a matching name and ID, it keeps one.

In practice:

1. When someone submits your form, generate a unique ID for that submission.
2. Send it with the pixel event from the page.
3. Send the same ID with the server event for the same submission.

The usual mistakes are generating a new ID on the server instead of reusing the browser's, or naming the event differently in the two places. Either one leads to double counting, and your reports show more leads than you got.

Events that only the server sends, such as a purchase after a call, need an event ID too, so a resend never counts as a second purchase.

What to send with each event

Each server event tells Meta what happened, when, and who it was, so Meta can match it to a person who saw or clicked your ad. The main fields:

• Event name: a standard event such as Lead, CompleteRegistration, Schedule or Purchase.
• Event time: when it happened. Send events promptly, since Meta limits how old an event can be when it arrives.
• Action source: where the conversion happened, such as your website or a system of your own.
• Customer information: email and phone, hashed with SHA-256 before sending, plus details like the browser ID and click ID that Meta's own cookies set, and the visitor's IP address and browser type where you have them.
• Value and currency: required for purchases.

The more of the customer information you send, the more often Meta can match the event to the right person. Meta's Events Manager shows an Event Match Quality score for each event, which tells you whether you are sending enough.

Why send qualified purchases, not just leads

Meta optimizes for the event you give it. If your campaign optimizes for leads and leads are all you report, Meta looks for people who fill in forms. Some of them buy. Many are collecting free guides and never will.

Take a coach selling a $2,000 program. A lead ad brings in a lot of cheap leads, but almost none of them book a call. When the coach starts sending purchase events with the real amount paid, Meta can see which leads became buyers and look for more people like them. The cost per lead may go up while the cost per buyer goes down, and the cost per buyer is the one that pays the bills.

Sending purchases helps even before you have enough of them to optimize for directly. They show in your reporting, so you can see which campaigns and ads produce buyers instead of only leads.

Which purchases to report

Some teams send every purchase and let Meta work out which ones its ads influenced. A stricter approach reports a purchase to Meta only when the buyer's first tracked touch was a Meta ad. That way a sale from a podcast guest spot, a referral or your own organic posts never looks like a Meta result, and Meta is not taught to chase people who were never going to come from its ads.

Whichever rule you choose, send the amount actually collected. Meta has no way to edit an event once it has arrived, so a wrong value or a duplicate purchase stays in your data.

Setting it up, step by step

1. In Meta Events Manager, confirm your pixel is installed and firing the events you care about.
2. Choose how to send server events: through a tool or platform that already has a Meta integration, Meta's own Conversions API Gateway, or a direct connection built by a developer using an access token from Events Manager.
3. Decide which events to send from the server. At minimum: leads or registrations from your forms, and purchases from your payment processor.
4. Add a shared event ID to every event the browser and the server both send.
5. Hash email and phone before sending, and include the browser and click IDs where you have them.
6. Use the Test Events tool in Events Manager to confirm events arrive and deduplicate before you switch to live.
7. Check Event Match Quality after a few days and add missing customer information if it is low.
8. Once purchases arrive reliably, compare cost per buyer across campaigns and consider optimizing for purchases.

Common mistakes

• Different event IDs, or none, on the browser and server copies of the same event.
• Test events sent to the live dataset, or live events left in test mode.
• Purchases sent with a value of zero, the wrong currency, or the checkout total before refunds.
• Organic sales reported as if they came from ads.
• Server events with no customer information, which Meta cannot match to anyone.
• Purchases sent days late, after Meta's limit on how old an event can be.

How Niche Engine handles it

Niche Engine attribution traces each buyer to their first tracked touch and reports qualified purchases back to Meta (Facebook and Instagram), Google, TikTok and OpenAI ads. A buyer is reported only if their first touch was one of those platforms and they paid on or after it, and only to the platform they came from. Organic sales are never reported as paid conversions, though their revenue still shows on the Revenue page.

Revenue comes from Stripe after refunds. Before anything goes out, a preview lists every amount, only the unreported part is sent, and sending twice sends nothing extra. Each contact record shows what was reported to ad platforms for that person.