Meta Pixel vs Conversions API: what each one sees, and what you need
Your developer says “the Pixel is installed”, yet Meta reports half the sales you made. Here is what the Pixel can see, what only the Conversions API can see, including M-Pesa payments, and how to run both without counting twice.
Key takeaways
- The Pixel reports from the visitor’s browser. The Conversions API reports from your server. Meta recommends running both and sending the same events through each.
- Anything the browser never sees can only be reported by the server, including an M-Pesa payment that Safaricom confirms to your system.
- Running both without a shared event ID counts every sale twice. With one, Meta keeps a single copy if both arrive within 48 hours.
- Meta scores each server event out of 10 for how well it matches a real person. Sending hashed email and phone raises it.
You asked your developer if the Facebook Pixel is installed. They said yes. Your ads run, Meta reports a handful of results, and you know you sold more than that last week, mostly through WhatsApp and M-Pesa. Or the opposite: Meta reports twice the sales you actually made, and the numbers feel too good to be true. Both are tracking problems, and both are why the Conversions API exists. This guide explains, without jargon, what each tool sees, what each one misses, and how to run them together properly.
The short answer
Meta Pixel
Code in your website that reports what visitors do from their browser: pages viewed, buttons tapped, forms sent.
Conversions API
The same reports sent from your server straight to Meta, including things that never happen in a browser.
What Meta recommends
Both. Its documentation says to implement the Conversions API alongside the Pixel and send the same events through each.
Why does it matter at all? Because Meta decides who sees your next ad from the people who acted on your last one. When those reports are missing, your ads optimise for people who click. When they are complete, your ads optimise for people who pay.
What each one sees, and what it misses
| What happens | Pixel (browser) | Conversions API (server) |
|---|---|---|
| Visitor views a product or service page | Yes | Yes, if your server reports it |
| Visitor taps your WhatsApp button | Yes, if the tap is set up as an event | Yes, and still arrives if the browser copy is blocked |
| Visitor uses an ad blocker or strict privacy settings | Often not | Yes |
| Customer pays by M-Pesa and never returns to the site | No | Yes — from Safaricom’s confirmation to your server |
| Sale closed later on the phone or in person | No | Yes, if your system records it and sends it |
Why the browser loses signals
The Pixel only works if the visitor’s browser runs it and keeps the small files (cookies) that link a visit to an ad click. Ad blockers stop the Pixel loading. Browsers also limit those files: Apple’s Safari, for example, shortens to 24 hours the life of cookies created by a page’s scripts when the visitor arrived from a site it classifies as a tracker through a tagged link, the way ad clicks arrive. None of this is a bug in your website. It is how modern browsers protect privacy, and it is why Meta built a server route.
The Kenyan case the Pixel cannot see at all: M-Pesa
Here is what happens when a customer pays by M-Pesa on a website: they tap “Pay”, a prompt appears on their phone, they enter their PIN, and Safaricom sends the confirmation to your server. Whether the customer’s browser ever loads a “thank you” page is up to the customer. Many close the tab, or the page loses its connection on mobile data. If that page never loads, the Pixel never reports the sale. Your server, though, always receives Safaricom’s confirmation, and it can send a Purchase event to Meta with the real amount. That one change is often the difference between ads that “bring nothing” and ads you can see paying for themselves. We explain how M-Pesa on a website works in how to accept M-Pesa payments on your website.
Running both without counting every sale twice
If the Pixel reports a sale and the server reports the same sale, Meta needs to know they are one sale. The method Meta recommends is simple:
- Give every event a unique ID when it happens: for example the order number.
- Send that ID with both copies: as
eventIDfrom the Pixel andevent_idfrom the server. - Use the same event name on both: “Purchase” and “Purchase”, not “Purchase” and “purchase_complete”.
- Send both promptly. Meta only matches copies received within 48 hours of each other, and generally keeps the one that arrives first.
The tell-tale sign of missing deduplication: Meta reports more purchases than your till or M-Pesa statement shows. If your ads look suspiciously good, compare one week of Meta’s numbers with your real sales before you raise your budget.
Event Match Quality: the score worth watching
Meta gives each server event a score out of 10 for how well it can match it to a real person on Facebook or Instagram. A high score means your ads learn from more of your real customers. Meta’s guidance on raising it:
- Send customer details Meta can match: email, phone, name and IP address. Meta says these may help increase the score.
- Hash contact details before they leave your server (Meta’s own software does this for you; otherwise you must).
- Always send the browser details (the “user agent”) for website events. Meta requires them.
- Pass Meta’s click and browser IDs (
fbcandfbp) and keep them fresh: they change over time.
Which events to send, by type of business
| Your business | Events that matter | The one to optimise ads for |
|---|---|---|
| Services (repairs, legal, clinics, agencies) | ViewContent, Contact (WhatsApp and call taps), Lead (forms) | Contact or Lead |
| Bookings (salons, hotels, restaurants) | ViewContent, Schedule, Purchase (deposit) | Schedule, or Purchase if a deposit is paid |
| Online shop | ViewContent, AddToCart, InitiateCheckout, Purchase | Purchase, with value and currency, which Meta requires |
| Event hire and quotes | ViewContent, Contact, Lead (quote request), Purchase (M-Pesa deposit) | Lead, moving to Purchase once deposits are tracked |
These are Meta’s standard event names. Use them rather than inventing your own: Meta’s ads understand standard events without any extra set-up.
How it gets set up
There are three common routes, and Meta notes they differ in effort, cost and features:
- A plugin for a platform such as Shopify or WooCommerce: quick, but it can only report what that platform records. Check whether your WhatsApp taps and M-Pesa payments are among them.
- A gateway product from Meta, which sends server events for you without custom code.
- A direct integration: your website’s own server sends events using a Pixel ID and an access token from Events Manager. This is the only route that can report M-Pesa confirmations and WhatsApp taps exactly as they happen, and it is what we build on the websites we make.
Whichever route you take, check it in Events Manager’s test tool: trigger each event yourself and watch the browser copy and the server copy arrive, matched. Then make one real enquiry and one real payment. If you would rather have it done and proven for you, that is our Meta Pixel and Conversions API set-up. And before you spend on the ads themselves, read how to pay for Facebook ads in Kenya, and see our Google and Meta ads service for the campaigns.
Questions people ask
Is the Conversions API replacing the Meta Pixel?
No. Meta’s own guidance is to use them together: the Pixel from the browser and the Conversions API from your server, sending the same events through both with a shared event ID so each one is counted once.
Do I need the Conversions API if I only get enquiries on WhatsApp?
It helps a lot. A tap on your WhatsApp button can be reported as a Contact event from the browser and from the server. If the browser copy is blocked, the server copy still reaches Meta, so your ads still learn which people message you.
Can the Meta Pixel track M-Pesa payments?
Only if the customer’s browser loads a “payment successful” page afterwards. Often it does not: the customer approves the payment on their phone and Safaricom confirms it to your server. The Conversions API can report that confirmation as a Purchase, with the real amount.
What is a good Event Match Quality score?
Meta scores server events out of 10 for how well they can be matched to a real person. Higher is better. You raise it by sending more of the customer details Meta asks for (hashed email and phone, IP address and browser details), not by sending more events.
Will the Conversions API share my customers’ data with Meta?
It sends the details you choose, and contact details such as email and phone should be hashed (scrambled one-way) before they leave your server. Your privacy notice should say that you share data with advertising partners. Send only what your ads need.
Was this guide useful?
Your answer tells us what to write next.
Thank you: that helps.
Tell us what was missing
