TL;DR
- Meta deduplicates a pixel event and a server event only when eventID matches event_id and the event names match, within 48 hours of the first event received.
- A Conversions API event_time can be up to seven days old; one older event in a request makes the whole request fail, and website events require event_source_url.
- Email, phone and name fields must be normalised and SHA-256 hashed; client IP, user agent, fbc and fbp must be sent unhashed. Phone numbers need the country code, e.g. 66 for Thailand.
- Event Match Quality scores server events out of 10 and is currently available for web events only.
- action_source values such as chat, phone_call and business_messaging let conversions confirmed in LINE, Messenger or by phone be reported back to Meta.
The Meta pixel and Conversions API are two ways of sending the same conversion events to Meta: the pixel sends them from the visitor's browser, and the Conversions API sends them from your server. Meta recommends running both together, with a shared event ID on each event so Meta can count it once, because a browser-only setup misses events that a server can still report.
This guide explains what each half does, why browser-only tracking loses events, what the Conversions API adds beyond filling that gap, how deduplication works in detail, and how to check the whole setup in Events Manager. It is written for advertisers and developers who already run Meta ads and want the measurement underneath them to be reliable.
What the Meta pixel does
The Meta pixel is a JavaScript snippet placed on every page of a website. When a page loads, the base code fires a PageView event. Additional code fires standard events when a visitor does something meaningful: ViewContent on a product page, AddToCart, InitiateCheckout, Purchase, Lead or CompleteRegistration, among others. Each event can carry parameters such as value, currency and content IDs.
The pixel also sets first-party cookies. The _fbp cookie holds a browser ID, and when someone arrives from a Meta ad with an fbclid parameter in the URL, the _fbc cookie stores the click ID. These identifiers, together with the IP address and user agent the browser sends, help Meta match the event to a person who saw or clicked an ad.
Meta uses those events for three jobs: reporting conversions in Ads Manager, optimising delivery toward people likely to take the event you chose, and building custom audiences such as recent visitors or cart abandoners. In Events Manager the pixel now sits inside a dataset, which is the container that can receive events from the browser, the server and other sources at once.
Why browser-only tracking loses events
A pixel can only report what happens in a browser that loads and runs its script. Several ordinary situations stop that from happening:
- Ad blockers and privacy extensions block requests to Meta's domains, so the event never leaves the browser.
- Browser tracking protections limit how long script-set cookies last and strip some click identifiers, so a purchase made days after the click may no longer be linked to it.
- Consent choices mean the pixel does not fire at all for visitors who decline tracking where a consent banner controls it.
- Page and network problems such as a visitor closing the tab before the thank-you page finishes loading, a slow mobile connection, or a payment gateway that never returns the buyer to your site.
- Conversions that happen off the website entirely, such as an order confirmed by phone, in a chat, or in a store, are invisible to the pixel by definition.
Every lost event costs twice. Reporting under-counts results, and the delivery system has fewer signals to learn from, so it optimises on a smaller and more biased sample of your customers.
What the Conversions API adds
The Conversions API (often shortened to CAPI) is a server-to-server connection. Your server, ecommerce platform or CRM sends the event directly to Meta, so ad blockers and browser cookie limits do not affect delivery of the event itself. Beyond recovering lost web events, it adds three capabilities the pixel cannot offer.
Events from outside the website
Every server event declares an action_source. Accepted values include website, app, phone_call, chat, physical_store, email, system_generated, business_messaging and other. That lets a business report a sale confirmed in a chat, or a lead that the sales team later marked as qualified, back to the campaign that produced it.
Better matching with customer information
Server events can include customer information parameters. Email, phone, first and last name, date of birth, gender, city, state, postal code and country must be normalised and hashed with SHA-256 before sending. Emails are trimmed and lowercased. Phone numbers lose symbols and leading zeros and always include the country code. Some parameters must not be hashed: client IP address, client user agent, the click ID (fbc) and the browser ID (fbp). External ID can be sent too, and hashing it is recommended.
Control over what is sent
Because the event is built on your server, you decide exactly which fields leave your systems. You can send a purchase only after payment is confirmed rather than when the thank-you page loads, and you can attach margin-adjusted values or a lead status the browser never knew about.
There are rules on timing. The event_time must be a Unix timestamp of when the event actually happened, and it can be up to seven days before the moment you send it; if any event in a request is older, the whole request fails. For website events, the event_source_url field is required. Meta also recommends sending events as soon as they occur, ideally within an hour, rather than in a daily dump.
Meta pixel vs Conversions API compared
| Question | Meta pixel (browser) | Conversions API (server) |
|---|---|---|
| Where the event is sent from | The visitor's browser | Your server, platform or CRM |
| Affected by ad blockers and cookie limits | Yes | The event itself is not, though match quality still depends on the identifiers you have |
| Can report offline, chat or phone conversions | No | Yes, through action_source |
| Needs developer or platform setup | Paste a snippet or use a tag manager | Partner integration, Meta's gateway option or custom code |
How event deduplication works
Meta recommends a redundant setup, meaning the same purchase is sent by both the pixel and the server. Without deduplication that purchase would be counted twice, so Meta needs a way to recognise the pair.
The recommended method uses two matching fields. The pixel's eventID must equal the server event's event_id, and the pixel's event name must equal the server's event_name. When both match, Meta keeps one and discards the other. The window matters: events are only deduplicated if they arrive within 48 hours of the first event Meta received with that event_id.
In practice that means generating one ID per event, typically the order number for a purchase or a random unique string for a lead, and passing the same value into both the pixel call and the server request. A common mistake is generating a fresh random ID separately in the browser and on the server, which guarantees the two never match.
There is an alternative method that matches on event_name plus fbp or external_id. It is weaker. It only works when the browser event arrives first and the server event second; a server event is not discarded if no matching browser event was received in the previous 48 hours, even if one turns up later. It also does nothing when only one source is in use. Treat it as a fallback, not the plan.
A hypothetical example
Imagine a shop where order 10452 is paid. The thank-you page fires the pixel with event Purchase and eventID 10452. The checkout system sends a server event with event_name Purchase and event_id 10452 a few seconds later. Meta receives both, sees the matching pair inside 48 hours, and counts one purchase. If the buyer's browser had an ad blocker, only the server event arrives, and the purchase is still counted once. The order number here is invented to illustrate the logic.
How to check your setup in Events Manager
- Open the dataset in Events Manager and look at the overview. Each event shows which connection methods it is received through. For a redundant setup, key events such as Purchase and Lead should show both browser and server.
- Use the Test Events tool. Meta describes it as the place to confirm that server events are set up correctly and received, and that deduplication is working. Trigger a test conversion on the site and watch both the browser and server versions arrive and be matched.
- Check Event Match Quality. Each server event gets a score out of 10 that shows how effective its customer information is likely to be for matching to a Meta account. It is currently available for web events only. A low score usually means few identifiers are being sent, for example no hashed email or phone and no fbc or fbp.
- Read the Diagnostics tab for warnings about missing parameters, duplicate events that are not being deduplicated, or values sent in the wrong format.
- Compare against your own records. Purchases reported in Events Manager over a week should sit close to the orders in your platform for the same week. Large gaps in either direction point to missing events or failed deduplication.
Ways to implement the Conversions API
Four routes are common. Ecommerce platforms such as Shopify and WooCommerce offer partner integrations that send server events with little code. Meta's Conversions API Gateway runs the server side in a cloud environment you control, for teams without developers. Server-side Google Tag Manager can forward events to Meta through a tag template, which suits sites that already use GTM. Custom code calling the API directly gives the most control and suits CRM and offline events. Whichever route you choose, check that it passes a shared event ID to the pixel, since some quick setups do not.
What this means for advertisers in Thailand
Thai commerce leans heavily on chat. Many orders are confirmed in LINE, Messenger or by phone after someone clicks a Meta ad, and none of those confirmations reach a pixel. The Conversions API's action_source values for chat, business messaging and phone calls let a business send those sales back to Meta so campaigns are optimised on real orders, not just on website form fills.
Phone numbers need care. Thai mobile numbers are usually written with a leading zero, but Meta's rules require removing leading zeros and including the country code before hashing. A number written as 081 234 5678 becomes 66812345678, then is hashed. Hashing the local format produces a value that will not match.
Thailand's Personal Data Protection Act also applies to customer data sent to advertising platforms. Confirm the legal basis and consent wording with your legal adviser before sending hashed personal data, and make sure your consent banner and server setup respect the same choices.
Meta measurement rarely lives alone. The same consent rules and event naming should line up with your analytics setup, which is why a GA4 tracking review is often done alongside a Conversions API project.
Frequently Asked Questions
Do I still need the Meta pixel if I use the Conversions API?
Yes, Meta recommends running the pixel and the Conversions API together in a redundant setup. The pixel captures browser signals such as fbp and fbc that improve matching, and the server fills the gaps the browser misses.
What is event deduplication in the Meta pixel and Conversions API?
Deduplication is how Meta counts an event once when it arrives from both the pixel and the server. It matches the pixel's eventID and event name to the server's event_id and event_name, within 48 hours of the first event received.
How old can a Conversions API event be?
A server event's event_time can be up to seven days before you send it. If any event in a request is older than that, the whole request fails.
Should customer data be hashed before sending it to the Conversions API?
Yes for fields such as email, phone, name, city and postal code, which must be normalised and hashed with SHA-256. Client IP address, user agent, fbc and fbp must be sent unhashed.
What is a good Event Match Quality score?
Event Match Quality is scored out of 10 for web server events, and a higher score means the customer information is more likely to match a Meta account. Meta does not publish a single pass mark, so the practical goal is to send every identifier you lawfully hold for each event.
Getting measurement right before scaling spend
A campaign can only optimise on the events it receives, so fixing the Meta pixel and Conversions API setup is often worth more than another round of creative tests. If you want help auditing your dataset, deduplication and match quality, the Facebook Ads team at Relevant Audience can review it with you. The same measurement also feeds Instagram ad campaigns and the cross-channel work in Relevant Social Ads.
