Meta Pixel setup for lead generation, step by step

Meta Pixel setup for lead gen takes six steps:

1. Create the Pixel (a dataset) in Events Manager.
2. Add the base code to the <head> of every landing page.
3. Fire Lead when the submission succeeds, not on the click.
4. Share an event_id with the Conversions API.
5. Test with Test Events and Meta Ads Data Advisor.
6. Check what your consent banner blocks.

The Meta Pixel is the tool many still call the Facebook Pixel: the same fbq code, renamed after Facebook’s parent company became Meta. This is the browser half of the job, for a form on a landing page you control. The server half has its own guides: how to set up the Conversions API and Meta Pixel and CAPI deduplication. The aim here is a Pixel that agrees with your server instead of competing with it. For where tracking sits in a whole campaign, see the Facebook ads for lead generation playbook.

What the Meta Pixel should send from a lead gen landing page

Out of the box, the base code sends a PageView every time it loads. Everything else is your decision, so write a short event plan before anyone touches code:

One submission, one Lead. A landing page that fires Lead, CompleteRegistration and Contact for the same form gives Meta three conversions to learn from and you three numbers to reconcile. The setup checklist in Meta’s Data Advisor docs makes the same point: typically one conversion event, with extra ones only when a specific user action triggers them.

Meta Pixel setup, step by step

Step 1: Create the Pixel (dataset) in Events Manager

Events Manager lists your existing Pixels under Data Sources. Meta’s Help Center now calls the procedure creating a dataset for your Meta Pixel: one object with two names, Pixel and dataset, and one ID that goes in the base code and in every Conversions API request.

Two checks before you create anything:

• Does this website already have a Pixel? Use it. Meta wants the same Pixel ID on browser and server events (Conversions API get started), and a second Pixel on the same landing page causes the double firing in the mistakes table below.
• Which business owns it? Agencies should create it in the client’s business portfolio and work through shared access. When the contract ends, the data stays with the business that paid for it. The same goes for the domain: verify it in the client’s portfolio, and have the client share it with yours.

Step 2: Install the base code

Copy the base code from Events Manager and add it to every landing page you’ll track, plus the thank-you page if you use one. Meta’s get started guide recommends placing it between the opening and closing <head> tags, which “reduces the chances of browsers or third-party code blocking the Pixel’s execution”.

Meta also documents an <img> tag install, “although not recommended”. For a lead form, stay with the JavaScript base code.

With first-party cookies on, the Pixel saves a browser ID in the _fbp cookie and, when the landing page URL carries an fbclid, the click ID in _fbc (Meta’s fbp and fbc reference). Your server sends both back with the Lead; _fbc and _fbp cookies, explained has the formats.

Step 3: Fire the Lead event on a successful submission

The common shortcut is to attach the Lead to the submit button’s click. On a lead form, a click isn’t a lead:

• it fires when validation fails, such as a phone number in the wrong format;
• a double tap on a slow connection fires it twice;
• your server can still reject the submission as spam, or time out.

Each of those adds a Lead to Meta’s count with no lead in your CRM, and all of them feed the delivery system you’re asking to find more leads. Fire the Lead after your server has saved the lead: in the success callback of the submit request, or on a confirmation screen that renders once per lead.

// runs only after the server has confirmed the lead was saved
fbq('track', 'Lead', {}, { eventID: leadEventId });

Meta’s standard events reference defines Lead as “When a sign up is completed”. Spell it exactly like that, in the browser and on the server. The reference also lists CompleteRegistration, Schedule and SubmitApplication; if one of them describes your form better, use it, but pick one event per form and keep it.

If the Lead fires from a thank-you page instead, only a successful submission should be able to reach it, and a refresh mustn’t send a second Lead. Tie the event ID to the lead, never to the load.

Advanced matching. The Pixel can also send the visitor’s email and phone, hashed, so Meta can match the event to a person. Manual advanced matching passes them in fbq('init'), and Meta says to “place advanced matching parameters in the pixel base code or the values will not be treated as manual advanced matching values” (advanced matching docs). On a lead form the base code runs before anyone has typed a thing, so that’s a poor fit. Switch on automatic advanced matching in Events Manager, and let the Conversions API Lead carry the hashed email and phone from the submitted form; Event Match Quality for lead generation covers the hashing.

Step 4: Pass an event_id so the Pixel and the Conversions API deduplicate

Meta recommends implementing the Conversions API “alongside” the Pixel, a setup it calls redundant, and counts the two copies of a Lead once when the Pixel’s eventID matches the server’s event_id and the event names match, within 48 hours (Meta’s deduplication guide). Its standard events reference recommends passing eventID as the fourth argument of fbq whenever you use both.

The browser side takes four moves:

1. When the visitor submits, generate one ID for this lead. A UUID is fine.
2. Send it to your server with the form fields, in a hidden field for example.
3. When the server confirms, fire the Pixel’s Lead with that ID as eventID.
4. The server sends the Conversions API Lead with the same string as event_id.

Retries, fallback keys and the Event Deduplication tab are covered in Meta Pixel and CAPI deduplication; the server payload, field by field, is in how to set up the Conversions API.

On DropCPL landing pages, the server half of this step is already wired. DropCPL sends each Lead to Meta through the Conversions API with an event_id for deduplication plus fbc and fbp, and computes your CPL from the leads your form actually received. Start free →

Step 5: Test with Test Events and Meta Ads Data Advisor (formerly Meta Pixel Helper)

The Meta Pixel Helper is now Meta Ads Data Advisor, “formerly Meta Pixel Helper”: a browser extension for Chrome and Microsoft Edge, and existing installs were updated automatically (Meta Ads Data Advisor docs). Use it together with Test Events:

A test run that catches most setup errors:

1. Allow the landing page in your ad blocker. Meta’s own testing steps for Data Advisor include deactivating it.
2. Open the landing page. Data Advisor should show one Pixel, with PageView.
3. Submit the form with a deliberate mistake, such as letters in the phone number. No Lead should fire.
4. Submit it properly. One Lead.
5. Refresh the confirmation screen. Still one Lead.
6. Look for anything marked Auto-detected next to the events you coded.
7. Run the server test with a test_event_code and check deduplication, as the Conversions API setup guide describes. That guide also explains why test leads should be few.

Meta Pixel setup with a consent banner

Where the law requires consent for tracking, your consent banner decides whether the Pixel runs at all. Meta leaves that decision with you: its GDPR guide for the Pixel says “Each company is responsible for ensuring their own compliance with the GDPR” (Meta). What the banner blocks depends on how it’s wired:

With the consent API, order matters. Meta’s example calls revoke before init, and the call has to run everywhere the base code runs:

fbq('consent', 'revoke');
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');
// later, once the visitor has accepted:
fbq('consent', 'grant');

What this means for lead gen:

• People who decline still submit forms. Your CRM gets the lead and Meta’s browser count doesn’t, so Events Manager shows fewer Leads than you received. Check your consent rate before you call it a tracking bug, and decide budgets on your own count; real CPL vs platform CPL explains why.
• The server Lead needs the same gate as the Pixel. Sending from a server is a different route for the same data, under the same rules. Server-side tracking for Facebook ads has what Meta says about consent and the Conversions API.
• Test three paths: decline, accept on arrival, and accept just before submitting, and watch in Data Advisor which events go out in each. Meta’s consent guide doesn’t say what happens to events fired while consent is revoked, so check rather than assume.

Common Meta Pixel setup mistakes