Meta Conversions API Setup: Deduplication, Hashing and EMQ Guide

What is the Meta Conversions API and how is it different from the Pixel?

The Conversions API (CAPI) sends events such as purchases, add-to-carts and leads from your server to Meta, rather than from the shopper's browser. The Pixel runs as JavaScript in the browser, so ad blockers, cookie restrictions or a page that closes before the script fires can lose the event. Server-to-server events are not affected by browser-side blockers.

The most common misunderstanding is treating CAPI as a replacement for the Pixel. Meta recommends a redundant setup: the same event arrives from both the browser and your server, and Meta matches the pair and counts it once. When the browser misses a purchase, the server event fills the gap; when the server event carries thin customer data, the Pixel's cookie values (fbp, fbc) help with matching.

If your Pixel and CAPI numbers still disagree with your store or GA4, our post on why Shopify, Meta and GA4 numbers never match covers the attribution side of the problem.

Which Conversions API setup method should you use?

If you run on Shopify, WooCommerce or another platform with a Meta integration, start with that native integration; custom-built sites should look at the Conversions API Gateway or a direct integration. The right choice depends on your technical resources and how much control you need over events and parameters.

A simple decision rule: if your platform has a Conversions API or access token field for Meta, use it first. If it doesn't and you have no developer, evaluate the Gateway. If you have a custom checkout, subscription renewals or offline sales that happen outside the browser, a direct integration will give you more accurate data in the long run.

How do you turn on the Conversions API in Shopify and WooCommerce?

In Shopify, CAPI is controlled by the data sharing level in the Facebook & Instagram app; in WooCommerce, the official Meta for WooCommerce extension (formerly Facebook for WooCommerce) handles Pixel and CAPI together. In both cases the job is to pick the right setting and then confirm the result in Test Events.

Shopify

In your Shopify admin, go to Sales channels > Facebook & Instagram > Settings > Data sharing settings and choose a level under customer data sharing. According to Shopify's help center, Standard uses only the Meta Pixel, which browser ad blockers can interrupt. Enhanced and Maximum add the Conversions API and share the customer's name, location, email and phone number for matching. Maximum also layers in Meta's latest advertising technology. If you want server events, pick Enhanced or Maximum, and update your privacy policy to match what you now share.

WooCommerce

Install and activate the Meta for WooCommerce plugin, then go to Marketing > Facebook > Get Started and follow the setup wizard to connect your business account, Page, ad account and Pixel. WooCommerce's documentation says the Conversions API is built in and switches on automatically once the extension is set up, and that Pixel and CAPI events are deduplicated with a unique event ID. If you also run a third-party tracking plugin such as PixelYourSite, decide which one owns Meta tracking and switch the other off.

Other platforms and tag managers

BigCommerce, Wix, Squarespace and server-side Google Tag Manager all offer Meta connections, but menu names change often. Whatever the platform, the logic is the same: the dataset (Pixel) ID and an access token generated in Events Manager go into the integration settings, and you validate with a test order afterwards.

How does deduplication between the Pixel and CAPI work?

Meta treats a browser and a server event as one when the Pixel's eventID matches the server's event_id and the event names (event and event_name) also match. Per Meta's documentation, duplicates are only removed if they arrive within 48 hours of the first event with that event_id, and Meta generally keeps the event it received first.

The most robust approach for purchases is an ID derived from the order number, because both sides already know it. For order 10482, the browser sends fbq('track', 'Purchase', {value: 84.00, currency: 'USD'}, {eventID: 'order_10482'}), and the server event includes "event_name": "Purchase" and "event_id": "order_10482". A random UUID generated separately on each side is unique, valid and matches nothing.

Here is why it matters (illustrative numbers): a store has 120 real orders in a week. The Pixel catches 95 of them and CAPI catches 118. Without working deduplication, Events Manager can show up to 213 purchases, so reported purchases and ROAS look about 1.8 times better than reality and the algorithm optimizes toward a false signal. With deduplication in place, the count stays close to 120.

Meta also supports a fallback method that relies on the same event name plus fbp and/or external_id. The documentation notes it only works when the browser event arrives before the server event, and it does nothing when you use a single event source. Treat event_id as the primary method and fbp or external_id as supporting signals.

How should customer data be normalized and hashed?

Fields like email, phone, first and last name, city and zip code must be cleaned according to Meta's formatting rules and then hashed with SHA-256, while IP address, user agent, fbc and fbp are sent unhashed. If the cleanup before hashing is wrong, the hash is wrong too, and that field contributes nothing to matching.

Why do phone numbers break matching so often?

Stores capture phones in every format imaginable: (650) 555-1212, +1 650-555-1212 or just 6505551212. Meta's rule is to strip symbols and leading zeros and add the country code, so all three must become 16505551212 before hashing. The UK is where leading zeros bite: 07700 900123 must become 447700900123, not 4407700900123. A number that keeps a plus sign, keeps a trunk zero or lacks the country code produces a different hash and adds nothing to your match rate. If your checkout collects the country code in a separate field, check that you don't prepend it twice.

• SHA-256 is applied to the normalized value, not the raw input
• Phones are digits only and start with the country code
• Emails are lowercased and trimmed
• client_ip_address and client_user_agent are sent raw
• fbc and fbp cookies are attached to server events too
• Logged-in customers get a stable external_id

What is Event Match Quality and how do you improve it?

Event Match Quality (EMQ) is a score out of 10 that estimates how well the customer information you send can match events to a Meta account. You can see it per event by opening your dataset in Events Manager. Meta's Dataset Quality API returns the same data through composite_score, plus match_key_feedback, which shows what share of events include each identifier.

Improving EMQ is usually about filling gaps, not buying new tools. On a purchase you almost always have the email and phone; if those aren't being sent, fix that first. Then add fbc (the ad click ID), fbp, IP address and user agent. Upper-funnel events like PageView rarely carry personal data, so a low score there is normal. Focus on Purchase, InitiateCheckout and Lead.

1. Measure Note the EMQ score for Purchase and any missing-parameter recommendations in Events Manager.
2. Find the gaps Check which identifiers arrive on a low share of events (often phone or fbc).
3. Fix Correct the normalization in code or in your platform settings.
4. Verify Inspect the parameters on fresh events in Test Events.
5. Wait and compare Give the score a few days to update and log the date of the change.

The Dataset Quality API also reports deduplication health. The event_coverage metric is the 7-day average share of Pixel events that are also covered by the Conversions API with shared deduplication keys. A low figure means your server is not sending some events at all.

How do you test a Conversions API setup with Test Events?

Open your dataset in Events Manager, go to the Test events tab, send the provided code as test_event_code on your server events, and confirm that each event shows up from both Browser and Server with one of them deduplicated. A real test order is the most reliable check.

1. Get the test code Copy it from the server events section of the Test events tab.
2. Trigger events View a product, add it to cart and place a test order.
3. Compare sources Check the browser and server rows for Purchase and compare their event_id values.
4. Inspect parameters Confirm the server event carries hashed em/ph plus fbc, fbp, IP and user agent.
5. Remove the test code Take test_event_code out of live traffic once you are done.

What should you monitor after setup?

For the first two weeks, compare Meta's Purchase count with your store's orders and check EMQ and Events Manager diagnostics weekly. The goal of CAPI is not a bigger number but a truer one; if Meta reports clearly more purchases than you have orders, revisit deduplication.

Don't skip the consent side. Server events bypass browser blockers, but you still need to disclose what customer data you share and why, and respect consent choices under laws like GDPR and US state privacy acts. We cover how consent and measurement fit together in our Consent Mode v2 and privacy guide.

Putting Meta, Google Ads and GA4 conversions side by side is the fastest way to spot drift between platforms. Marpany's conversion analysis view lines those sources up against your store data, so after switching on CAPI you can see whether reported purchases actually move closer to real orders. For which metrics to watch, see the ad performance KPI guide, and for the on-site side of the equation, e-commerce conversion optimization.

Next steps

• Pick your method: platform integration, Gateway or direct API
• Remove duplicate Pixel code from your theme and tag manager
• Use a shared event_id derived from the order number for Purchase
• Normalize phones to digits with the country code, then hash
• Validate browser and server events with a test order in Test Events
• Re-check EMQ and diagnostics weekly after launch; menu names in this guide are as of September 2026 and can change