Do you need the Meta Conversions API as well as the pixel?
If you spend very little on Meta, or your shop’s own Meta connection has already switched this on, you can probably stop reading here and go and do something more useful.
For anyone else who relies on Facebook or Instagram ads to find customers, the answer is usually yes. The Meta pixel reports sales from the visitor’s browser, the Conversions API reports them from your own systems, and Meta recommends sending the same events through both so that each can cover for the other, with deduplication stopping a sale from being counted twice.
Meta calls that arrangement a “redundant setup”, which is a fair description. You’re effectively paying for a spare.
What’s the difference between the pixel and the Conversions API?
The pixel is a small piece of code on your website that runs in the visitor’s browser and tells Meta what they did. It’s easy to put in place and it depends entirely on that browser. If the page doesn’t finish loading, the connection drops or something blocks it, the message never arrives.
The Conversions API sends the same sort of message from your own systems instead. An API is simply a way for one system to pass data to another, and Meta says the data can come from a server, a website platform, a mobile app or a CRM (the software holding your customer records). Because it doesn’t rely on the customer’s browser, it can also report things a browser never sees, such as an order confirmed by phone or a lead your sales team has qualified.
When isn’t it worth the effort?
Meta’s recommendation is a general one and your circumstances may not suit it. We’d leave it alone in any of these situations.
- Meta is a small part of your marketing. If your ads there are occasional, or you’re not asking Meta to find you conversions, extra data gives it little to work with.
- Your website platform already does it. Meta lists Shopify, WooCommerce, Wix and BigCommerce as partners where setting this up takes a few clicks at no additional cost. Turn that on before you pay anybody.
- Your leads come through Meta’s own forms. Those are filled in inside Facebook or Instagram, so a website connection adds very little. Sending the sales outcome back is a separate question.
- Your pixel is reporting the wrong things. Fix that first, because a server connection built on the wrong events will simply report the same mistakes with more confidence.
- Consent isn’t sorted. A second route for sending customer data makes an unresolved consent problem bigger.
We also won’t put a number on what you’d gain from it, because we can’t stand behind one.
When does it earn its place?
It’s a sensible addition if one or more of these describes your business.
- Meta is a meaningful channel, and you’re making budget decisions based on what it reports.
- The real result happens away from the website, such as a confirmed order in your ERP (the system that holds your orders) or a qualified lead in your CRM. Meta says offline events can be used for measurement and for building audiences.
- Your website journey has a step the browser can miss, such as a payment taken on another site, where the customer may never come back to your thank-you page.
- You’re sending the same quality of data to more than one ad platform, so that your channels can be compared on the same real outcomes.
How does event deduplication work?
Think of it as both messages quoting the same reference number. When one sale arrives from the browser and again from your server, Meta needs to know it’s one sale and not two. It works that out by comparing the event name (such as “Purchase”) and an event ID, a reference you give each individual event. When both match, Meta discards the repeat.
These are the steps, and your developer will want the technical names given below.
- Create one reference per event. An order number works well for a purchase. Meta says it should be a unique value.
- Send it with the browser event. The pixel calls this
eventID. - Send the same reference with the server event. The Conversions API calls it
event_id. - Use identical event names on both. The pixel’s event and the server’s
event_namehave to match. - Send the server event promptly. Meta only discards matches that arrive within a limited period, and it recommends sending events in real time or as close to it as you can.
- Check it in Events Manager. That’s Meta’s own reporting area, and its Event Deduplication tab shows whether repeats are being caught and warns you when the rate is too low.
Meta also describes a second method that compares browser and customer identifiers, and says it generally only works when the browser event arrives first, so we’d stick with the event ID. If you don’t send the same event through both routes, you don’t need deduplication for that event at all.
Google Ads has its own version of this problem, and our guide to duplicate conversions shows how the same sale ends up counted twice there.
What are the ways of setting it up?
| Route | What it involves | Suits | The catch |
|---|---|---|---|
| Meta’s one-click option in Events Manager | Meta says website events can be set up with no code, configuration or set-up fees if you already have a pixel | Simple websites | You may have less say over exactly what gets sent |
| Your website platform’s connection | A built-in link on Shopify, WooCommerce, Wix or BigCommerce | Online shops | Check what it actually sends and which data-sharing setting is on |
| Conversions API Gateway | Meta’s self-service option, installed on a cloud server | Teams happy to look after a server | Somebody has to look after that server |
| Google Tag Manager or a similar partner tool | Set up through a tool that already holds your tags | Businesses already using one | Needs someone comfortable working in it |
| A custom connection to your server, CRM or ERP | Code written around your own data | Offline sales, qualified leads and several systems | The most work up front, and it needs maintaining |
Start at the top of that table and only move down when the simpler route can’t do what you need. A one-click connection that sends the right events beats a custom build you didn’t need, and a custom build tends to be justified by offline outcomes more than by website sales.
Does the Conversions API get around cookie consent?
No, whatever you may have been told. A server connection doesn’t know what your cookie banner said unless it’s been built to check, so a sale sent from a server can ignore a visitor’s “reject” without anybody noticing.
Meta’s terms require appropriate notice to your users and their consent for sharing event data. UK data protection rules still apply when you pass customer details to an ad platform, so take advice on your own position, as we’re developers and this isn’t legal advice. If you also run Google Ads, our Consent Mode guide for UK advertisers covers how those choices reach Google’s tags.
How do you know it’s working?
Events Manager has most of what you need, and these are the places to look.
- Events arriving through both routes. The overview shows what has been received and through which connection.
- Events discarded. It also shows anything thrown out for consent or policy reasons, which is useful if the numbers look light.
- The deduplication tab. A low rate usually means references that aren’t unique, or that only one route is sending them.
- Event Match Quality. A score from 1 to 10 for how well your server events can be matched to people’s accounts. Meta suggests aiming for 6.0 or higher where possible, and a low score usually means you’re sending too little customer information with each event.
We connect Meta, LinkedIn and Microsoft Ads as an optional add-on to your Google tracking setup, built in your own accounts and quoted alongside it, as described on our other ad platforms page. If you’re not sure which route you need, ask us and we’ll tell you if the one-click option will do the job.