Meta Pixel and Conversions API: Setup, Events and Deduplication

How the Pixel works

Meta's developer guide Get started with the Meta Pixel describes it as "a snippet of JavaScript code that loads a small library of functions you can use to track Facebook ad-driven visitor activity on your website." It "relies on Facebook cookies" to match visitors to their accounts. By default it tracks "URLs visited, domains visited, and the devices your visitors use."

You find the base code in Events Manager. Meta recommends adding it "between the opening and closing <head> tags on every page where you will be tracking website visitor actions", because this "reduces the chances of browsers or third-party code blocking the Pixel's execution." The base code sends a PageView each time a page loads. Meta also says the Pixel "will work in most tag management and tag container solutions"; our Google Tag Manager basics guide explains how a container works. To confirm the install, load a page and look for the new PageView in Events Manager.

Where the Pixel sits in an ad account, and Meta's rules on prohibited information, are covered in our Meta Ads basics guide. This guide goes into the setup.

Standard and custom events

Beyond page views, you tell the Pixel when something important happens with fbq('track', ...). Meta's Meta Pixel API reference lists standard events. Those most useful for a service business are:

• Lead: "When a sign up is completed", such as an enquiry form;
• Contact: "When a person initiates contact with your business via telephone, SMS, email, chat, etc.";
• Schedule: "When a person books an appointment to visit one of your locations.";
• CompleteRegistration: "When a registration form is completed.";
• Purchase: "When a purchase is made or checkout flow is completed." For this event, currency and value are required.

Standard events can carry parameters such as value and currency. You can also define custom events for actions the standard list does not cover. Fire the event on the confirmed result, such as the thank-you page after a form is sent, not on the button click. That way a failed submission is not counted.

What the Conversions API adds

The Pixel runs in the browser, so it can miss events. Meta's Conversions API best practices say the API lets you "share website events that the Pixel may lose due to network connectivity issues or page loading errors", plus events "that occur offline or at a later time that the Pixel cannot capture". Examples include a phone sale or a lead that becomes a customer weeks later.

The Conversions API overview describes a connection from "an advertiser's server, website platform, mobile app, or CRM to Meta systems". It also notes: "If you have a Meta Pixel on your website, you can also set up Conversions API with Meta for website events in one click from Meta Events Manager, with no code, configuration, or setup fees." A direct integration from your own server gives the most control, but needs a developer.

Meta recommends running both. It calls this a redundant setup: "Use the Conversions API in addition to the Meta Pixel, and share the same events using both tools."

What a server event contains

Meta's page on server event parameters sets out the fields. The main ones are:

• event_name: a standard or custom event name, such as Lead;
• event_time: when the event happened, as a Unix timestamp. Meta says it "can be up to 7 days before you send an event", and older events cause the whole request to fail;
• action_source: where the conversion happened, such as website, phone_call, chat or physical_store;
• event_source_url: the page URL, which Meta says "is required for website events";
• user_data: customer information used for matching (next section);
• event_id: an identifier used for deduplication.

Meta asks you to confirm that the source is right: "By using the Conversions API, you agree that the action_source parameter is accurate to the best of your knowledge." The best practices page also asks you to "Share events closer to real time", either straight away or in batches close to real time.

Customer information and hashing

Meta matches server events to people using the customer information parameters, such as email (em), phone (ph), name, IP address, user agent and the fbp and fbc cookie values. Contact details must be normalised and hashed with SHA-256 first. Meta says its systems "are designed to not accept customer information that is unhashed Contact Information", with stated exceptions. For email, it asks you to trim spaces and convert to lowercase before hashing. Meta's Business SDK can do the hashing for you.

For website events, Meta's best practices list client_user_agent as required, and recommend including external_id and event_id for all events. They explain why more data can help: "You can use only matched events for ads attribution and ad delivery optimization." Events Manager shows an Event Match Quality score, which Meta says "is currently available only for web events." The fbp and fbc values "are subject to change", so read them fresh from the cookies rather than storing them.

Send only what you need for matching, and make sure your privacy notice explains it.

Deduplication: counting each event once

With a redundant setup, the same enquiry arrives twice: once from the browser and once from the server. Meta's page on handling duplicate Pixel and Conversions API events describes two methods.

Event ID and event name (recommended). "In corresponding events, a Meta Pixel's eventID must match the Conversion API's event_id", and the event names must match too. In the Pixel, the ID goes in the fourth argument of the track call, for example fbq('track', 'Lead', {}, {eventID: 'EVENT_ID'});. If Meta finds matching pairs "sent to the same Pixel ID within 48 hours, we discard the subsequent events." For a purchase, the server event parameters page suggests "An order number or transaction ID" as the ID. For a form, generate one random ID per submission and use it in both events.

fbp or external ID. The second method matches on event name plus fbp and/or external_id. It has limits: it "only works for deduplicating events sent first from the browser and then through the server", and it does not remove duplicates sent from only one source.

If you send an event from only one source, no deduplication is needed. Meta says advertisers "who do not send the same event twice via both the Conversions API and Meta Pixel do not need to set up deduplication for those events."

Testing in Events Manager

Meta's best practices recommend the Test Events tool to "Verify that you've set up your server events correctly and Meta has received them", to check "which events were processed and deduplicated", and to "Debug any unusual activity." Meta notes that developers should usually test with their own details, "because these events may get discarded if they don't match a Facebook or Meta account." A good test is to send one real enquiry through the live form and confirm it shows once, not twice.

Name your campaigns and links consistently so that Meta's results and your own analytics can be compared; our guide to UTM tracking links covers the naming.

Consent and Limited Data Use

The Pixel sets cookies and sends data from the visitor's browser, so it falls under the same cookie and consent rules as other marketing tags. Meta's Pixel guide notes that, depending on where you do business, "you may have to comply with General Data Protection Regulation." Sending events from your server does not change what the visitor agreed to. Your server should respect the same choice the visitor made in your banner. Our cookie consent banners guide explains how that choice should work.

For US state privacy laws, Meta offers Limited Data Use, which "gives you more control over how your data is used in Meta's systems". You "must proactively enable" it. In the Pixel, that is a dataProcessingOptions call. In the Conversions API, it is the data_processing_options field on each event. Meta's page lists which states and products it covers.

A checklist

• Pixel base code in the head of every page, or one tag manager setup.
• Standard events (Lead, Contact, Schedule, Purchase) fired on confirmed results.
• Conversions API connected through Events Manager, your platform or your server.
• action_source, event_source_url and client_user_agent sent for website events.
• Contact details normalised and hashed with SHA-256.
• The same event_id and event name in browser and server events.
• Test Events checked after launch and after every change.
• Pixel and server events both following the visitor's consent choice.

FAQ

Do I need both the Meta Pixel and the Conversions API?

Meta recommends both. Its best practices call this a redundant setup: share the same events with the Pixel and the Conversions API, so the server can fill gaps when the browser loses events, and deduplicate them.

How does Meta stop the same event being counted twice?

The recommended method is to send the same event name and the same event ID from the browser and the server. If Meta finds matching pairs for the same Pixel ID within 48 hours, it discards the later ones.

Can I send customer emails to Meta in plain text?

No. Meta asks for contact information such as email and phone to be normalised and hashed with SHA-256 before it is sent, and says its systems are designed not to accept unhashed contact information, with stated exceptions.

How far back can a Conversions API event be?

Meta's server event parameters say event_time can be up to 7 days before you send the event. If any event in a request is older than 7 days, the whole request returns an error.

Does the Conversions API avoid the need for cookie consent?

No. Sending events from a server does not change what the visitor agreed to. Your server should follow the same consent choice the visitor made in your cookie banner, and the Pixel still sets cookies in the browser.

Want your website forms and Meta ads connected so you can see which ads bring in customers? See our website development service and all our services, or email [email protected].