Meta Conversions API setup from first event to clean deduplication

The Conversions API is a server to server connection between your systems (website backend, store platform, CRM or tag server) and Meta. Instead of relying only on JavaScript running in a visitor's browser, your server reports events such as Purchase, Lead, CompleteRegistration or AddToCart directly.

Server events are not affected by browser extensions or page unloads, and they can include events that never happen in a browser at all, such as a lead marked as qualified in your CRM or a phone order. Meta uses these events for attribution, reporting, audience building and, most importantly, delivery optimization.

Meta recommends a redundant setup: the Pixel keeps sending browser events, and CAPI sends the same events from the server. Each covers gaps in the other. The browser captures signals that are easy to collect on the page, such as the fbp and fbc cookie values. The server delivers events reliably and can attach customer information you hold securely.

Running both only works if Meta knows when two events describe the same action. Otherwise a single purchase would be counted twice.

Meta deduplicates a browser event and a server event when they share the same event name and the same event_id, sent within a matching time window. In practice:

• Generate one unique ID per action, for example the order number for a purchase or a random ID created when a form is submitted.
• Send that ID as eventID in the Pixel call and as event_id in the CAPI payload.
• Make sure the event_name matches exactly on both sides, including capitalization (Purchase on both sides, never purchase on one of them).
• Send the server event promptly after the action rather than in a delayed batch, so both arrive within the deduplication window.

If deduplication fails, Events Manager shows more events than actually happened, reported revenue inflates and the algorithm optimizes against distorted data. If events are deduplicated too aggressively, for example because every event reuses one static ID, real conversions disappear.

Meta needs to connect each server event to a person on its platforms. It does this with customer information parameters. Event Match Quality, shown in Events Manager on a scale up to ten, estimates how well your events can be matched.

Parameters that improve matching include:

• Email address (em) and phone number (ph), normalized and hashed with SHA-256.
• First name (fn), last name (ln), city (ct), state (st), zip code (zp) and country (country), each normalized and hashed.
• External ID (external_id), such as your customer ID, hashed.
• Client IP address and client user agent, sent unhashed.
• The fbp browser ID and the fbc click ID, read from cookies or from the fbclid URL parameter, sent unhashed.

Normalization matters as much as hashing. Lowercase and trim emails, strip symbols and add country codes to phone numbers, and use the formats Meta documents for each field. Send only data you collected lawfully and only for visitors whose consent allows it.

Many store platforms and CRMs offer a built-in Conversions API integration that you connect from Events Manager. This is the fastest route for standard ecommerce events. Check that the integration supports deduplication with the Pixel and passes enough customer information.

Meta offers a gateway you host in your own cloud environment. It mirrors Pixel events to the server side with little code. It suits teams that want server events quickly without building a custom integration.

A server container in Google Tag Manager receives events from your website and forwards them to Meta, Google Ads, GA4, TikTok and others from one place. This gives you control over what data goes where and works well for multi-channel advertisers.

Your developers call the Graph API endpoint for your dataset with an access token. This is the most flexible option and the right one for events from a CRM, a custom checkout or a backend workflow, such as sending a lead status change days after the form.

• Confirm which business events matter for optimization and agree on standard event names.
• Check that the Pixel is installed cleanly, firing once per action, with parameters such as value and currency on purchases.
• Choose the setup route that fits your stack and generate an access token for your dataset in Events Manager.
• Add event_id to every Pixel event you plan to send from the server, using the same ID logic on both sides.
• Build the server events with event_name, event_time, event_id, action_source, event_source_url and the customer information parameters you have.
• Hash personal fields with SHA-256 after normalization, and pass IP address, user agent, fbp and fbc unhashed.
• Respect consent: only send events and personal data that the visitor's choices permit, and keep the logic consistent with your consent banner or platform.
• Launch on a test event code first, then switch to live once the checks below pass.

• Use the Test Events tab with a test event code to watch browser and server events arrive in real time.
• Confirm each server event shows as received from the server, and that matching browser events show as deduplicated.
• Review Event Match Quality per event after live traffic flows, and add missing parameters where the score is low.
• Check the diagnostics tab for warnings about missing event_id, mismatched parameters or events sent with delay.
• Compare event counts with your store or CRM over a few days. Totals should be close to reality, not doubled.

• Pixel and CAPI events using different IDs, which doubles conversions.
• Hashing the IP address or user agent, which makes them unusable.
• Sending purchase events without value and currency, so value optimization has nothing to work with.
• Firing server events for every page load instead of meaningful actions.
• Ignoring consent signals on the server side.