Meta Pixel & Conversions API: The Signals Behind Smarter Measurement

Every week, ad platforms make thousands of small decisions on your behalf: who sees the ad, when, and how much to bid. They make those decisions from the conversion signals you send back. If those signals are late, duplicated or missing, the platform is steering with a foggy windscreen.

This guide explains the two ways a website usually reports conversions to Meta, the browser-side Meta Pixel and the server-side Conversions API (CAPI), and how they are meant to work together. It is not an installation manual. Implementations differ by platform, and Meta's documentation changes; the goal here is to help you ask better questions of whoever builds or audits your setup.

The signal problem, without the drama

You will read that browser tracking is “dead”. It isn't, but it is less complete than it used to be. Browsers limit cookies, people use blockers, pages fail to load fully, and some visitors decline consent. Each of these can mean a purchase or a lead that happened in the real world but never reached the ad platform as a signal.

That gap matters for two reasons. First, your reports undercount, so a campaign can look worse than it is. Second, and more important, the delivery system optimises towards the people who appear to convert. Fewer, noisier signals give it less to learn from.

What the Pixel sends from the browser

The Meta Pixel is a piece of JavaScript that runs in the visitor's browser. When something you care about happens, a page view, an added cart, a submitted form, a completed purchase, the Pixel sends an event to Meta with details such as the event name and, for a purchase, its value and currency.

A simple example: someone completes checkout on your thank-you page. The Pixel fires a Purchase event with value: 1250 and currency: "TRY". Because it runs in the browser, it knows things about that browsing session, but it depends on the page loading, the script running and the browser allowing it.

What the Conversions API can add from the server

The Conversions API lets your server, your e-commerce platform or your CRM send events to Meta directly. Meta describes it as a way to connect an advertiser's marketing data to Meta's systems, and says server events are linked to a dataset and processed like events sent with the Pixel.¹ It can carry website events, app events, offline conversions and business messaging events.¹

The practical difference is where the signal starts. A server knows an order was paid even if the thank-you page never loaded in the browser. A CRM knows a lead became a qualified opportunity a week later, something no browser script could see.

Server-side does not mean effortless. It has legitimate prerequisites:

• A reliable place where the event really happens (order system, booking system, CRM) and someone who maintains the connection.
• Customer information that is prepared correctly. Meta requires some fields, such as email, phone and first name, to be hashed before sending, while others, such as the client IP address, user agent and the fbp/fbc browser identifiers, must not be hashed.³
• A lawful basis and a clear purpose for sending that information at all (more on that below).

Many platforms offer a guided connection, and Meta notes that advertisers already using the Pixel can set up the Conversions API for website events from Events Manager without writing code.¹ Whether a one-click setup sends what you need is a separate question worth checking.

Browser + server: one event, counted once

Meta recommends using the Conversions API alongside the Pixel rather than instead of it.² That creates an obvious risk: the same purchase arriving twice, once from each side. Deduplication is how Meta recognises the pair and keeps one.

Meta documents two ways to deduplicate:

Event ID + event name (recommended)

The Pixel's eventID must match the server event's event_id, and the Pixel's event name must match the server's event_name. Duplicates sent to the same Pixel within 48 hours of the first event with that ID are discarded.²

fbp or external ID

Matching on the event name plus fbp and/or external_id. Meta notes this only works when the browser event arrives first.²

When the two copies don't meaningfully differ, Meta says it generally keeps the one received first.² And if you never send the same event through both channels, you don't need deduplication for that event at all.²

What to check in Events Manager

Interfaces change, so we won't prescribe click paths. Instead, these are the questions to answer with whoever has access to your Meta Business account and Events Manager:

• Which events arrive from the browser, which from the server, and which from both?
• For events sent from both, is deduplication working, or are purchases appearing roughly twice as often as your order system says?
• Do event names match exactly across both sources (spelling and case)?
• Are value and currency present on purchase events, and do they match your actual order values?
• Does Meta show any diagnostics or warnings for the dataset, and has anyone read them recently?

The most useful test is boring: compare a week of purchases or qualified leads in your own system with the events received. Differences in either direction are clues.

Consent and lawful collection: CAPI is not a bypass

Sending an event from a server instead of a browser does not change whether you are allowed to send it. If a visitor has not agreed to marketing measurement where agreement is required, routing their data through your server does not make it acceptable.

In Türkiye, the Personal Data Protection Law No. 6698 (KVKK) requires personal data to be processed lawfully and fairly, for specified, explicit and legitimate purposes, and in a way that is relevant, limited and proportionate to those purposes.⁴ It also obliges the data controller to inform people when their data is obtained, and it has specific rules for transferring personal data abroad.⁴ Sending customer information to an advertising platform raises all of these questions.

Practical principles that hold up in most cases:

• Send the minimum. If you don't need a field for matching or measurement, don't send it.
• Respect the visitor's consent choice on both channels, browser and server, with the same logic.
• Never send sensitive categories of data, and be careful with event names or URLs that reveal them.
• Document what you send, why, and where it goes.

Common mistakes

Duplicate conversions

Both channels send purchases, but without a shared event ID. Reports inflate, and optimisation learns from phantom customers.

Mismatched events

The browser sends Lead, the server sends lead_submitted. To Meta, those are different events and will not deduplicate.

Wrong value or currency

A purchase value sent in the wrong currency, or with tax and shipping handled differently on each side, quietly distorts value-based decisions.

Measuring the wrong thing

Optimising for a form view because it fires often, instead of a submitted form or a qualified lead, teaches the system to find people who look rather than people who buy.

Missing consent logic

The browser respects consent; the server sends everything anyway. That is a legal problem, not a technical detail.

A 10-point Pixel and Conversions API audit

Use this as a self-check before you spend more, or as an agenda for a conversation with your developer or agency.