Meta Pixel setup: tracking and the Conversions API

Meta Pixel setup means installing Meta's browser pixel and the Conversions API together, then deduplicating them with one shared event ID so each conversion is counted once. The Meta Pixel is the script on your site that reports visits and actions from the browser. In 2026 that browser signal is incomplete on its own, because ad blockers, Safari, consent choices, and iOS tracking prompts stop a share of events before they leave the device.

Meta's documentation recommends sending the same events again from a server. The pixel still matters. It feeds website audiences and browser match keys. The Conversions API covers the conversions the browser never sent. A matching event ID keeps the overlap from being counted twice.

What is the Meta Pixel?

The Meta Pixel is Meta's browser tracker. It used to be called the Facebook Pixel. The name changed. The job did not. When someone views a page or completes an action, the pixel sends an event to Meta.

Those events are how Meta builds website audiences, estimates who is likely to convert, and ties an ad click to a later purchase or lead. If the event never arrives, delivery optimizes against a partial record of what happened on the site.

The pixel only sees what the browser allows it to send. The rest of this guide is about closing that gap without double-counting the events that do get through.

How does Meta Pixel setup work?

A working Meta Pixel setup has six parts. Miss one and Events Manager can look healthy while campaigns learn from the wrong conversions.

1. Create the pixel in Meta Events Manager. Meta now groups this under a dataset. You still get a pixel ID.
2. Put the base code on every page that matters, as early as it can load.
3. Fire a standard event when the action actually happens. PageView on load. ViewContent on a product, plan, or offer. Lead when a form is completed. Purchase when payment succeeds, with a value and a currency.
4. Confirm those events in Test Events before you trust the account.
5. Send the same events from your server with the Conversions API.
6. Put the same event ID on the browser event and the server event.

Meta calls the last two steps a redundant setup. That is the setup they recommend for ad performance. It is not reserved for large accounts.

Fire Purchase when the order exists, not when someone opens checkout. A refresh of the confirmation page should not create a second purchase. Using the order ID as the event ID is what stops that.

What should Meta Pixel tracking include?

Meta Pixel tracking is the list of events you send, not the snippet by itself. Send the events you will optimize for and build audiences from. Custom events you never use add noise.

For most sites the useful set is short:

• PageView, so Meta can see the visit.
• ViewContent, for the page that matters, such as a product, a plan, or an offer.
• Lead, or CompleteRegistration, when a form is actually finished.
• AddToCart and InitiateCheckout, if those steps are real on your site.
• Purchase, with value and currency, only after payment succeeds.

If you sell, get Purchase right first. If you generate leads, get Lead right first. Meta only lets you prioritize a short list of events for people on iOS who opted out of tracking, so the conversion you pay for should sit at the top of that list.

Names have to match. Purchase and purchase are not the same event. The browser call and the server call need the same standard name, or deduplication never sees them as a pair.

Why does Meta Pixel tracking miss conversions?

The pixel runs in the visitor's browser. Anything that stops that script, or the request it makes, removes the event.

Ad blockers drop it. Safari limits the cookies it depends on. iOS asks whether an app may track someone across other companies' apps and websites, and many people decline. A consent banner that never grants marketing storage means the pixel never fires. A checkout that never lands on a confirmation page means Purchase had nowhere to fire.

The Conversions API does not use that browser path. Your server tells Meta the conversion happened, so an ad blocker sitting in the visitor's browser is not in a position to delete it. A pixel-only account then trains on the conversions it managed to see, which are not the same set as the conversions that took place.

Keep the pixel. Meta uses the browser event for matching and for website custom audiences. Removing it after you add the Conversions API removes that signal. The durable setup is both.

Should you use the Meta Pixel and the Conversions API together?

Yes. Run the Meta Pixel and the Conversions API for the same events.

People often search for the Meta Pixel and Conversions API as if they were alternatives. They are two deliveries of one event. The pixel sends it from the browser at the moment it happens. The Conversions API sends it from a server, including visits the browser could not report. When both arrive, Meta should count one conversion. That happens only when the two copies can be deduplicated.

Three common setups fail in known ways:

• Pixel only. Blocked browsers never show up, so optimization learns from a smaller, skewed set of conversions.
• Conversions API only. You can record server-confirmed conversions, and you give up browser audiences plus the browser identifiers the pixel collects, including fbp and fbc.
• Both, with no shared ID. Meta often counts the conversion twice. Reported results look stronger than the business was, and budget follows the inflated number.

Meta's best-practice guidance is to send the Conversions API in addition to the Meta Pixel, for the same events, and to make the copies deduplicable. Include event_id. Where you have them, also send external_id and fbp. The full note is in Conversions API best practices.

How do you stop the same conversion being counted twice?

Deduplication uses two fields that must match, plus the event name.

On the browser pixel the field is eventID. On the Conversions API the same value is event_id. The names differ by format. The value must not. The event name has to match as well: a pixel event of Purchase and a server event_name of Purchase.

If Meta sees that pair on the same pixel ID within 48 hours, it drops the later copy. When the browser event and the server event arrive within about five minutes of each other, Meta keeps the browser event. Both rules come from Meta's server event parameters and its deduplication guide.

Use these rules when you choose the ID:

• Purchase. Use the order ID. Two orders need two IDs, or the second sale disappears.
• Lead. Use the submission ID if you have one. Otherwise create one ID in the browser and pass that same string to the server. Do not create a second ID on the server.
• Retries. Do not mint a new ID when a request fails and you send it again. A new ID looks like a new conversion.
• Source. Set the server action_source to website for events that happened on the site.
• Destination. Send both copies to the same pixel ID.

A browser purchase with an order ID looks like this: fbq('track', 'Purchase', { value: 10, currency: 'USD' }, { eventID: 'order_123' }). The matching server event uses event_name Purchase and event_id order_123. Different capitalization, a different ID, or a missing ID, and deduplication does not run.

How do you know Meta Pixel tracking is working?

Check three views in Events Manager, in this order.

Test Events. Browse the site and confirm PageView, plus the conversion you care about, arrive from the browser. Then complete a test conversion and confirm the server event arrives too. You want both sources, not a green browser event and silence from the server.

Event deduplication. Open the event and its deduplication tab. You want a high share of overlapping events marked as deduplicated. A warning means the IDs are missing or do not match. Meta documents where to look in its setup verification guide.

Event Match Quality. For web events this score runs from 1 to 10. It measures how useful the customer information on a server event is for matching a Meta account. Meta recommends aiming for 6.0 or higher where you can. Unmatched events can still be used for basic measurement. They are not used for attribution or for optimizing ad delivery. Hashed email or phone, plus the browser IDs fbp and fbc, are the usual ways to raise the score. Send only customer data you have a right to send.

If reporting shows one purchase as two conversions, look at the event ID before you touch budgets or creative.

What usually breaks a Meta Pixel setup?

Most broken accounts already have a pixel. They send the wrong event, they send it twice, or the conversion never fires.

• The base code is on the marketing site and missing on checkout, or the other way around.
• Purchase fires on the button click, before payment, so failed payments count as sales.
• The confirmation page renders in the browser after the pixel event was supposed to run, so Purchase never sends.
• A tag manager and a hardcoded pixel both fire Purchase.
• The Conversions API integration generates its own ID, and the pixel uses a different one.
• Consent blocks the pixel, and the server event goes out with no fbp or fbc, so match quality stays low.

Fix the event and the shared ID before you add another tag. Another pixel on the same action usually makes the duplicate worse.

How do you set up the Meta Pixel and Conversions API without hosting the server?

The slow part is rarely the click path inside Events Manager. It is running a server that receives the browser event, accepts the same event from your site, and forwards one deduplicated stream to Meta.

Tyton provides that server. A free audit checks the pixel, the Conversions API, missing events such as Purchase or Lead, and purchases that fire twice. The audit does not need an account. When you want the fix installed, Tyton supplies the gateway, and an AI agent installs the browser pixel and the server events with one shared event ID. The agent can walk the next Meta screen. It does not sign in to Meta for you.

Start at usetyton.com. Tyton MCP is listed on mcp.so, and Tyton is listed on Product Hunt.

Is the Facebook Pixel the same as the Meta Pixel?

Yes. Facebook Pixel was renamed Meta Pixel. The events, the pixel ID, and the Conversions API are the same system under the current name. Guides that still say Facebook Pixel are describing this setup.

Do you still need the Meta Pixel if you use the Conversions API?

Yes. Meta recommends both. The pixel supplies browser events, website audiences, and match keys such as fbp and fbc. The Conversions API covers conversions the browser never sent. Either one alone leaves a hole the other one was built to fill.

What event ID should a Meta Pixel purchase use?

The order ID. The browser eventID and the server event_id must be that same string, both events must be named Purchase, and both must go to the same pixel ID. A random ID is fine for events that have no order number, as long as the browser and the server share it.

What Event Match Quality score should you aim for?

For web events, Meta recommends 6.0 or higher where you can. The score is out of 10. Only matched events are used to attribute ads and to optimize delivery. A low score is a customer-information problem, not a reason to turn the pixel off.