The Meta Pixel is a snippet of JavaScript that records what visitors do on your website from their browser. The Conversions API (CAPI) sends the same kinds of events from your server to Meta. Used together, they give Meta a more complete picture of purchases, enquiries and other actions, which it uses for reporting and ad optimisation.
The Meta Pixel
According to Meta’s Pixel documentation, the Pixel loads a small set of functions that you call when a visitor completes an action you care about, such as a purchase or sign-up. Those actions are called events, and the ones you choose to measure are conversions. Meta says the Pixel lets you:
- see tracked conversions in Ads Manager to judge ad performance,
- build custom audiences for targeting,
- support Advantage+ catalog ads, and
- analyse where visitors drop out of conversion funnels.
The same page lists data the Pixel can collect, including HTTP header information such as IP address, browser details and referrer, Pixel-specific data such as the Pixel ID and Facebook cookie, button clicks, and any values you pass in custom data. It also says the Pixel can collect form field names (not the values entered) unless you use Advanced Matching or optional values. Knowing this matters for your privacy policy and consent approach.
The Conversions API
Meta describes the Conversions API as a way to connect an advertiser’s marketing data, from website, app, business messaging and offline sources, from the advertiser’s own server, website platform, app or CRM to Meta. Meta says the data is used to optimise ad targeting, lower cost per result and measure outcomes. Server events are linked to a dataset ID and handled like events sent with the Pixel, so they can be used for measurement, reporting and optimisation in similar ways. Meta also says advertisers who already have a Pixel can set up CAPI for website events in one click from Events Manager, with no code or setup fees.
Why use both
Think of two reporters watching the same sale. The browser sees it only if the page loads the Pixel and the browser lets the script run. The server sees it whenever your system records the order. A browser-only setup can miss events when scripts do not load or are blocked. A server-only setup loses some browser context. Sending from both, with matching rules, gives Meta the best chance of seeing each conversion once.
This is a concept-level explanation. How many events each route misses on your site varies, and Meta’s documentation does not give a single figure, so check Events Manager diagnostics for your own account.
The tracking architecture in simple terms
- A visitor takes an action on your site, such as submitting an enquiry form.
- The Pixel in their browser fires an event, for example a lead event, with an event ID.
- Your server records the same action and sends it to Meta through CAPI with the same event name and event ID.
- Meta matches the two and counts the action once.
- Meta uses the event for reporting and for learning which people tend to convert.
Deduplication: the part people get wrong
If both routes send the same event and Meta counts both, conversions double. Meta’s deduplication guide recommends the event ID and event name method. An event is deduplicated only when both keys match: the Pixel’s eventID must equal the server’s event_id, and the Pixel’s event must equal the server’s event_name. Deduplication applies only within 48 hours of when Meta first receives an event with a given event_id, and where the two events do not meaningfully differ Meta generally keeps whichever arrived first. A fallback method uses the event name plus fbp and/or external_id, but it mainly works when the browser event arrives first and it does not deduplicate two events from the same source.
Customer information and privacy
CAPI events can include customer information to help Meta match events to accounts. Meta’s customer information parameters page says contact details such as email and phone number must be hashed with SHA256 after normalisation, that some fields such as client IP address and user agent are not hashed, and that you must send at least one user data parameter in the correct format. It advises sending the same customer information on the browser and server sides, and including country codes in phone numbers.
Hashing is not a substitute for a lawful basis. Check your obligations under the Privacy Act and your consent practices before sending customer data, and take professional advice for your situation. This article is general information, not legal advice.
Setup checklist
- Decide which actions are real conversions (leads, bookings, purchases) and track only those as primary events.
- Install the Pixel, and set up CAPI through your platform’s integration or a direct server connection.
- Pass a shared event ID for each event from both routes.
- Test with Meta’s Events Manager tools and confirm events show as deduplicated and matched.
- Review the consent banner and privacy policy so they describe what you collect.
- Document who owns the setup so it survives staff and agency changes.
Limitations
Tracking improves the signal but does not prove what caused a sale. Attribution models, delays and cross-device behaviour still leave gaps. Combine platform reporting with your own sales data, as set out in How to Measure Creative Campaign Performance Beyond Views. Clean conversion data is only useful if the page converts, so also review Landing Pages That Turn Campaign Traffic Into Enquiries. For where paid tracking sits in a wider plan, see How to Build a Digital Marketing Strategy for a Growing Business.
Where Radiance Impact fits
Radiance Impact’s Growth team covers strategy, social and campaigns, and its Technology team builds websites and workflow automation. If you want help planning measurement for paid campaigns, see Growth and Marketing or contact us.
Sources
- Meta Pixel, Meta for Developers
- Conversions API, Meta for Developers
- Handling duplicate Pixel and Conversions API events, Meta for Developers
- Customer information parameters, Meta for Developers
