Book
Tracking

Setting up the Meta pixel for a funding funnel

Ten steps, and the two that everything else depends on.

Alex Makowski · Updated 17 September 2026 · 6 min read

The short answer

Installing a Meta pixel takes a few clicks. What decides whether it works is where it does not fire. Create one pixel per funnel, put the base code on every page, build the qualification into the form, send qualified and disqualified submissions to two separate URLs, put a one-time passcode in front of the qualified one, and fire the lead event on that page and nowhere else. Then add the Conversions API for the same event, confirm deduplication, test both exits, and point the campaign at the lead event.

A monkey can install a pixel. It is a few clicks in Events Manager and a script in the head of the page, and there is nothing to get wrong. Everything that actually decides whether the account works sits in the next nine steps, and most of it is about the places the event must not fire.

A monkey can install a pixel, at 8:05. Chapters and transcript →
Whiteboard headed “The one idea”: “The pixel doesn’t measure your leads. It decides who your next leads are.” Four bullets: every time Lead fires, you’re telling Meta this is what I want, go find more like them; fire it on every form submit and Meta hunts for people who submit forms — startups, $5k/mo, tire kickers, spam; fire it only after qualification and OTP and Meta hunts for merchants worth a phone call; same spend, same creatives, completely different lead.
The premise the whole build rests on. Same spend and the same creatives produce a different merchant depending on what the pixel has been told to look for.

The ten steps

StepWhat you doWhy it is on the list
1Create the pixel in Events Manager. One pixel per funnelA pixel shared across two offers learns two contradictory definitions of a lead
2Install the base code on every pagePageView everywhere is harmless, and it loads the pixel so the lead event has something to fire through later
3Build the form so it can disqualifyRevenue, amount, time in business, statements, state — each answer either continues the form or ends it
4Build two destination pagesTwo separate URLs, not one thank-you page with different text on it
5Put the one-time passcode in front of the qualified pageNothing routes to the qualified page until the six-digit code comes back
6Fire the lead event on the qualified page, nowhere elseNot on the submit button, not on form start, not on step two
7Add the Conversions API for the same eventA server copy that cannot be blocked, carrying the hashed contact details
8Check deduplicationThe Deduplicated column in Events Manager should be filling up
9Test both exitsA disqualified test that fires a lead event stops everything else
10Point the campaign at the lead event, and webhook the qualified page to the CRMThe optimisation and the phone call both hang off the same page load
Two steps from the board. Step 1, Create the pixel: Events Manager → Connect data sources → Web. One pixel per funnel. Don’t share a pixel between a funding offer and a credit repair offer — you’ll break both. Step 2, Install the base code on every page: base code fires PageView everywhere, that’s fine. PageView is harmless, and it loads the pixel so LEAD has something to fire through later. GHL: Sites → Funnel → Settings → Tracking code (head). WordPress: PixelYourSite or a header-scripts plugin. Custom: paste in <head>.
Steps one and two. The only decision in either of them is whether to share a pixel between two offers, and the answer is never.

Steps three and four: the form does the disqualifying

The gates are conditional logic inside the form, not copy on the page. Revenue, requesting amount, time in business, months of statements and state, and each answer either continues the application or ends it. The form’s job is to find the merchants you cannot fund before the pixel ever hears about them, which is why the fields that qualify have to be asked rather than assumed.

Then two destinations. A qualified submission lands on a page that says one of our partners will contact you in the next few minutes. A failure lands on a real page — another offer, a plain thank-you, whatever suits — and it is never the same URL. That page is also the reason a disqualified merchant is still worth something: you paid for the click, the record can be called or sold on, and none of it reaches Meta.

Step 4, Build two destination pages: /qualified — “one of our partners will contact you in the next few minutes.” /not-a-fit — a real page. Redirect them to another offer, say thanks, whatever. It just can’t be the same URL. All platforms: two separate URLs. Not one thank-you page with different text. Step 5, Put OTP in front of the qualified redirect: six-digit code to the mobile number. Nothing routes to /qualified until it comes back. That kills VoIP, landlines, typos and spam before Meta ever hears about them. GHL: phone verification on the form step. Custom: Twilio Verify or equivalent.
Steps four and five. The passcode sits between the form and the qualified page, so a submission that cannot receive a code never becomes a conversion event.

Steps five and six: the passcode, then exactly one event

A six-digit code goes to the mobile number the merchant typed, and nothing routes to the qualified page until it comes back. That removes VoIP numbers, landlines, typos and spam before any of it becomes data. It is the clearest case of friction that earns its drop-off, because everyone it stops is someone who could not have been called anyway.

Step six is the one people get wrong after doing the first five right. The standard Lead event fires on the page load of the qualified page. Not on the submit button, not on form start, not on “step two”. The page that only loads after the passcode has come back is the only place it belongs, because that page load is the only moment in the funnel that means what you want Meta to go and find.

Step 6 from the board: Fire LEAD on /qualified. Nowhere else. Standard event, name it Lead. Fires on page load of /qualified. Not on the submit button. Not on form start. Not on “step 2.” The page that only loads after OTP is the only place it belongs. GHL: Facebook integration → event on this page, or a page-level script. WordPress: PixelYourSite → event on URL. Custom: fbq(“track”,“Lead”,{},{eventID:“ABC123”}).
The event fires once, on one page load. The event ID in the custom snippet is what lets the server copy be matched to it.

Steps seven to ten: the server copy, and the test that matters

Step seven adds the Conversions API sending the same Lead from your server, with the same event ID and the hashed contact details attached. Step eight is confirming that Meta is collapsing the two copies into one rather than counting both — why the lead is sent twice covers what that check looks for and what a failed one does to your cost per lead.

Step nine is the one to do before spending anything. In Events Manager, use the test event code and run a qualified submission through: one Lead, browser and server, deduplicated. Then run a disqualified one: PageView only. If the disqualified test fires a Lead, stop. Nothing else on this list matters until that is fixed, because the account is training on merchants nobody can fund.

Step 9, Test both exits: Events Manager → Test events. Qualified test: one LEAD, browser and server, deduplicated. Disqualified test: PageView only. “If the disqualified test fires a LEAD — stop. Nothing else matters until that’s fixed.” All platforms: use the test event code so it doesn’t touch live data. Step 10, Point the campaign at it. Webhook to the CRM: Objective Leads → Website → Performance goal “maximize conversions” → Conversion event Lead on this pixel. Then /qualified also fires a webhook into your CRM so the rep is dialing inside 60 seconds. Speed to lead is the other half of quality.
Steps nine and ten. The qualified page does two jobs at once: it fires the conversion event and it pushes the record into the CRM.

Before you spend a dollar

The same ten steps as a list to tick off, which is worth doing on an account that already exists as well as one being built. A funnel that has been running for months with the event on the wrong page has a pixel full of the wrong merchants, and that is a thing to find out now rather than after another month of spend.

Checklist headed “Before you spend a dollar”, twelve unticked boxes: base code on every page, PageView firing; two URLs, /qualified and /not-a-fit; gates are conditional logic in the form, not copy on the page; OTP sits between the form and /qualified; LEAD fires on /qualified page load, nowhere else; disqualified test fires PageView only, confirmed in Test Events; Conversions API sending the same LEAD with hashed data; Deduplicated column filling in Events Manager; campaign conversion event set to Lead on this pixel; webhook from /qualified into the CRM, test lead landed, rep notified; Microsoft Clarity installed, recordings filtered to non-converters; Funded → Purchase event wired only if you’re at about 50 funded a week.
The board’s own checklist. The last line is the only one that most accounts should leave unticked on purpose.

That last box is a volume question rather than a setup question: funded deals as a Purchase event need about fifty a week before Meta can read them, which puts them out of reach of almost every account. Everything above it applies at any budget above the $100-a-day floor.

Questions.

Keep reading.

Book 15 minutes with Alex.

We will tell you straight up if we cannot help you.

Read this before you book.

  • ✗We do not offer free trials.
  • ✗We do not give discounts.
  • ✗We do not do commission deals.
  • ✓We require an upfront investment to work with us.

If you are not able to invest into getting more leads for your brokerage, do not book a call.

— Alex