Meta Pixel or Conversions API? Why you need both

You need both: the Meta Pixel measures in the browser and misses what goes wrong there, while the Conversions API sends the same events from a server ^[1]. Meta itself recommends this redundant setup ^[2]. Deduplicate with a matching event_id and event name, and check the coverage in Events Manager ^[3].

Whether you manage your campaigns yourself or hand them to a Facebook Ads agency: what Meta doesn't see, it can't optimise. The technical work, such as server-side tagging, is explained by my colleague Cédric in server-side tracking explained. Here you read what you check as an advertiser.

Why the Pixel alone isn't enough

The Conversions API can pass on events the Pixel loses through network problems or loading errors ^[1]. On top of that comes the browser. Safari deletes cookies set via JavaScript after 7 days without interaction, and after 24 hours if someone arrived via a link that Safari recognises as tracking ^[7].

What Meta misses affects your advertising cost. Meta only uses events it can link to an account ^[1], and an ad set only exits the learning phase after about 50 results per week ^[8]. The auction also weighs how likely someone is to convert ^[9], so less signal means slower learning and a less accurate estimate.

An example without client data: a webshop spends €1,500 per week and gets 60 orders from Meta ads, so €25 per purchase. If Meta only sees 40 of them, Ads Manager reports €37.50, and you might lower the budget of a campaign that is profitable. What a purchase may cost is covered in what advertising on Facebook and Instagram costs.

Measure how much you miss yourself. Over a full month, put the purchases or leads in Events Manager next to the orders or requests in your webshop or CRM. The difference is never zero, because not everyone comes through an ad or gives consent.

How deduplication works

Meta recommends sending the same events along both routes, for example Purchase, InitiateCheckout and Contact ^[1]. To count them as one event, the following has to match ^[2]:

• the event_id of the server event equals the eventID in the Pixel;
• the event name is the same on both sides;
• both arrive within 48 hours of the first event with that event_id.

Meta then usually keeps the version it received first ^[2]. If you only send an event along one route, for example purchases only via the server, you don't need to deduplicate them ^[2].

The classic mistakes are a different event_id in browser and server, a server event without an event_id, or a different name for the same action. With the alternative method using fbp or external_id, two identical browser events also both remain ^[2]. If your thank-you page fires the Pixel twice, fix that in your website.

TikTok works with the same logic: events with the same name and event_id are merged if they arrive after 5 minutes and within 48 hours of the first one ^[10]. One event_id system can therefore serve both platforms; more on that in advertising on TikTok in Belgium.

What to check in Events Manager

You don't need to be a developer to see whether your measurement is right. Events Manager shows it per event ^[3]:

Event match quality is not a percentage but a score, per web event via the Conversions API, calculated over the past 48 hours ^[6]. It depends on the customer information you send along hashed: email address and click ID weigh the most, name, city and postcode the least ^[6]. According to Meta, a better score can lead to more reported conversions and lower cost per action ^[6].

For every server event, action_source is required, and for website events also the URL and the user agent ^[1]. For purchases, send value and currency along, as Meta's own sample code does ^[2]. Check everything with the Test events tool before a campaign steers on it ^[1].

Want someone to take a look with you? The free Meta Ads audit checks Pixel, Conversions API and events, together with structure, audiences and creatives.

Consent is still required

The Belgian Data Protection Authority is clear: cookies that aren't strictly necessary may only be placed after valid consent, and that also applies to pixels ^[11]. That is why you can pause the Meta Pixel until your visitor agrees ^[5].

The Conversions API doesn't change that. Meta's terms require that you have the legal right to share the data, that you hash contact details and that you don't send sensitive information ^[6]. Meta processes events from iOS devices via the server with the same restrictions as via the browser ^[12].

What the server does do: pass on events from visitors who gave consent more reliably, and send conversions the browser never sees. How to pass the cookie choice correctly to all your tags is covered in Consent Mode v2 in practice.

Which integration suits you?

If you work with leads, send the outcome from your CRM back with the Conversions API for CRM. Meta then optimises your lead ads for quality instead of volume ^[15]. Then ask your developer or partner five questions:

1. Which events go along both routes, with the same event_id and name ^[2]?
2. Which customer information do we send along hashed, and only for visitors who gave consent ^[6]?
3. How does the server follow the visitor's cookie choice?
4. Do events arrive in real time or in small batches, and not once a day ^[1]?
5. Who monitors coverage, deduplication and match quality after go-live ^[3]?