How to Set Up the Meta Pixel and Conversions API Together

The Meta Pixel and the Conversions API both send your website's conversions to Meta. The Pixel sends them from the visitor's browser. The Conversions API sends them from your server. Run them together and give each action one shared event ID, so Meta can match the two copies and count the conversion once. This guide is part of our paid advertising guide.

You'll need access to Meta Events Manager, your pixel ID, and your site's code or tag manager. Server events need a developer, a platform integration or a partner tool.

How the Pixel and the Conversions API differ

Both tools feed the same pixel in Events Manager, and Meta processes their events in the same way for reporting and delivery. The difference is where each event starts and what can stop it.

Neither is complete on its own. A browser event can be blocked or lost when a page closes early. A server event can lack the browser details that help match it to a person. That's why the two are set up as a pair, with a way to recognise duplicates.

Steps

1. 01
   List the actions you want to measure.

   Write down each action that matters, such as a lead form, a booked call or a purchase, and map it to one of Meta's standard event names, such as Lead, Contact, Schedule or Purchase. Use a custom event only when no standard event fits. Keep this list as your tracking plan, so the browser and the server always use the same names.

2. 02
   Install the Pixel base code on every page.

   Add the base code from Events Manager to your site's header, through your site code, a tag manager or your platform's Meta connection. Use one method only. Two installs of the same pixel, such as a plugin plus hand-added code, will send every event twice before the Conversions API is even involved.

3. 03
   Fire each browser event when the action completes.

   Trigger the Lead event on the confirmation step, such as the thank-you page or the form's success message, not on the button click. A click only shows someone tried. Firing on the confirmation means the browser and server events describe the same finished action.

4. 04
   Create one event ID for each action.

   Generate a unique ID at the moment the action happens, such as the lead or order number from your system. Pass it to the Pixel as eventID and to your server as event_id. Meta's specification says the two must match, along with the event name, for Meta to treat the events as duplicates.

5. 05
   Send the same event from your server.

   When your server records the action, send it to the Conversions API with the same event name and event ID. Meta's specification requires the event name, event time, customer information and action source. Set action_source to website for site conversions, and include the page URL where the event happened.

6. 06
   Add customer information, hashed.

   Send the details your form collected, such as email and phone, normalised and hashed with SHA-256: trimmed, lower case, then hashed. Also pass the browser ID and click ID cookies (fbp and fbc), the IP address and the user agent, which are not hashed. Only send data your privacy policy and consent choices allow.

7. 07
   Test with a test event code.

   Open Test Events in Events Manager, copy the test event code, and add it to your server requests while you test. Submit a real test lead on the site. You should see the browser event and the server event arrive for the same action. Remove the test code before you go live.

8. 08
   Confirm that pairs are deduplicated.

   In Events Manager, check that the event shows as received from both the browser and the server, and that Meta reports them as deduplicated. Meta's published specification says it keeps the first of two matching events received within 48 hours, and favours the browser event when both arrive within about five minutes.

9. 09
   Choose the optimization event and keep watching.

   Once events arrive reliably, set your campaigns to optimize for the event that matches the result you want, as described in our guide to Meta ads campaign structure. Send server events promptly: the specification rejects events whose event time is more than seven days old. Check Events Manager after any site change.

If you'd rather have the Pixel, server events and campaigns set up and checked for you, our in-house ads team runs Meta campaigns alongside the creative.

What a matched pair looks like

This browser call sends a Lead event with an event ID. The ID here is a placeholder; in practice it comes from your form or order system:

fbq('track', 'Lead', {}, { eventID: 'lead-20261018-0042' });

The server sends the same action with the same name and ID. This trimmed example shows the fields that matter for matching, with placeholder values:

{
  "data": [{
    "event_name": "Lead",
    "event_time": 1792300000,
    "event_id": "lead-20261018-0042",
    "action_source": "website",
    "event_source_url": "https://www.example.com/thank-you",
    "user_data": {
      "em": ["<sha256 of the lowercased email>"],
      "fbp": "<value of the _fbp cookie>",
      "client_ip_address": "<visitor IP>",
      "client_user_agent": "<visitor user agent>"
    }
  }]
}

The event name and event ID are identical in both. That's what lets Meta recognise them as one lead. The browser adds its own cookies and page details, and the server adds the hashed email, so the matched event carries more information than either copy would alone.

Once each lead is counted once, you can connect it to revenue. We cover that in how to track paid media ROI.

Privacy and consent

Server-side tracking moves customer data through your own systems, so it comes with responsibilities. Send only what you need for matching and measurement. Hash personal details before they leave your server, and keep names, emails and phone numbers out of event names, page URLs and custom fields, where they would travel unhashed.

If your site asks visitors for consent, apply the same choice on the server. A visitor who declines tracking in the browser shouldn't reach Meta through your server instead. Describe the data you share with ad platforms in your privacy policy. Rules differ by country and state, and some industries have extra limits, so check what applies to your business. This section is general information, not legal advice.

Troubleshooting

Every conversion is counted twice

Cause: the browser and server events don't share an event ID, or the IDs are created separately on each side, so they never match. Event names that differ, such as Lead in the browser and lead on the server, also break matching. A pixel installed twice, through a plugin and in the site code, produces the same symptom before the server is involved at all.

Fix: generate the event ID once, when the action happens, and pass that value to both the Pixel and the server, as in step 4. Use exactly the same event name on both sides, including capital letters. Then check the site for a second Pixel install and remove it. Submit a fresh test lead and confirm in Events Manager that the pair now shows as deduplicated.

Server events don't show up in Events Manager

Cause: the request is reaching Meta with an error, or not reaching it at all. Common reasons are an expired or wrong access token, the wrong pixel ID, a missing required field such as action source, or an event time in the wrong format. Meta's published specification rejects events whose event time is more than seven days old, which can catch delayed batch uploads.

Fix: log the response your server gets back from each request, because Meta's error message usually names the problem field. Confirm the pixel ID and token in Events Manager, then send one event with a test event code, as in step 7, and watch Test Events. Send event time as a Unix timestamp in seconds, and send events soon after they happen.

Some conversions only arrive from the server

Cause: some visitors block the Pixel, decline consent, or leave the confirmation page before the browser event fires. Their actions only reach Meta from the server. This is expected, and it's part of why the Conversions API exists. It becomes a problem only when the browser share drops suddenly, which usually points to a broken Pixel after a site change.

Fix: compare browser and server counts for the same event week by week. A steady gap is normal; a sudden drop means checking the Pixel on the confirmation page, the tag manager trigger and any consent banner changes. Make sure server events still include the fbp and fbc cookie values where available, so they can be matched as well as possible.