If you run Facebook and Instagram ads for a local business, your tracking is probably leaking. Not because you did anything wrong. Browsers block cookies, people decline tracking on their phones, and a single misnamed event quietly tells Meta to optimize toward the wrong thing. The ads keep spending. The reports look fine. The leads just never quite show up.
This guide fixes that. We'll set up the Meta Pixel, which Meta now calls a dataset, and pair it with the Conversions API so your tracking sends events from two directions at once: the visitor's browser and your server. Done right, that combination is the difference between an algorithm that learns and one that flails.
It's written for owners and in-house marketers, not developers. You won't need to write code from scratch. You will need access to your website and your Meta Business account, and about an afternoon.
Create one dataset in Events Manager. Install the browser pixel on every page and fire a clear Lead or Contact event on the action that makes you money. Verify your domain. Then send the same events server-side through the Conversions API with a shared event_id so Meta deduplicates them. The Conversions API is not optional anymore; it's the half of your tracking that survives ad-blockers and iOS.
Step 1: Find or create your dataset in Events Manager
Everything starts in Meta Events Manager, the hub inside Business Manager where all your tracking lives. If you've used Meta ads before, you may already have a pixel. Look before you build a second one. Duplicate datasets are the most common mess we untangle on a new account, and a split between two of them means neither has enough data to optimize well.
A quick note on names, because Meta changed them and the old ones still float around. What used to be called the "Facebook Pixel" or "Meta Pixel" is now your dataset inside Events Manager. The ID number is the same; only the label moved. When you see "pixel ID" in an old tutorial, that's your dataset ID today.
Step 1: Open Events Manager and check for an existing dataset
In Events Manager, open Data Sources (you can also reach the same place through Business Settings, then Data Sources, then Datasets). If one already exists and is receiving events, use it. If it's there but dead, you'll reactivate it in the next step rather than starting over.
Step 2: Create a dataset if you don't have one
Click Add, name it after your business (not "Test", which you'll regret later), and choose Web as the source. Meta hands you a dataset ID. Write it down. You'll use it in both the browser setup and the Conversions API setup, because both feed the same container.
Assign the dataset to your business, not your personal profile. If you set it up under a personal account and later hand the business to an agency or a new marketing hire, you can lose access to your own conversion history. Ownership lives at the Business level for a reason.
Step 2: Install the browser pixel and fire the right events
The browser pixel is the classic piece: a snippet of JavaScript that loads on your site and reports what visitors do. It's still valuable. It just can't carry the whole load anymore, which is why Step 4 exists. Get this half solid first.
Step 1: Add the base code to every page
If you use Google Tag Manager, this is easiest: create a new tag, paste Meta's base pixel code, and set it to fire on All Pages. If you're on Shopify, Squarespace, or WordPress, there's usually a native field or a plugin where you drop the dataset ID and skip the code entirely. Either way, the goal is the same: the base pixel fires once on every page load, tracking a generic PageView.
Step 2: Fire a real conversion event on the action that matters
A PageView alone tells Meta nothing about whether your ads work. You need to fire a standard event on the thing that's actually worth money. For a local service business, that's almost always a Lead or a Contact: a contact-form submit, a "Request an appointment" click, a click-to-call tap. Pick the one closest to a booked customer that still happens often enough to learn from.
Here's the judgment call most guides skip. A lot of local businesses fire their only conversion event on the deepest action in the funnel, like a fully completed online booking. The intent is right, but if that action only happens a handful of times a month, Meta never gets enough signal to optimize and ends up spreading budget almost at random. The fix we reach for is to move the primary event up the funnel to a more frequent, high-intent action, like a "Book now" or "Request appointment" click, and keep the completed booking as a secondary event. That way the algorithm has enough volume to actually learn, and you still measure the deeper conversion. The lesson: optimize on a frequent, high-intent event, and keep the deeper conversion as a backup measure.
Use Meta's named standard events where one fits, like Lead, Contact, Schedule, or Purchase. Standard events plug straight into Meta's optimization and reporting. Custom events work but make you do more configuration later.
Don't fire your conversion event on page load of a "thank you" page and on the button click. That's the same conversion counted twice, and it inflates your numbers until you stop trusting them. One action, one event.
Step 3: Verify your domain
Domain verification tells Meta, "I own this website." You do it once, in Business Settings under Brand Safety, then Domains. Add your domain and verify it one of three ways: a DNS TXT record, an HTML meta tag in your site's <head>, or an uploaded file. DNS is the most durable; the meta-tag method is the fastest if you have direct access to your template.
Meta used to require domain verification to configure event priority for iOS traffic under a system called Aggregated Event Measurement. That manual setup was retired in mid-2025, and Meta now aggregates eligible events automatically. So you no longer hand-rank eight events. But verifying your domain still matters: it controls who can edit ad links to your site and locks down your event configuration so a partner can't quietly change it. Skip it and you may see "unverified domain" warnings that limit what you can optimize. It's fifteen minutes. Do it.
Step 4: Add the Conversions API for server-side events
This is the step that separates working tracking from the half-broken kind. The browser pixel runs in the visitor's browser, so anything that blocks JavaScript also blocks your pixel: ad-blockers, privacy browsers, and the tracking prompt on every iPhone. A meaningful share of your real conversions simply never reach Meta through the browser alone.
The Conversions API (often shortened to CAPI) fixes that by sending events from your server straight to Meta, skipping the browser entirely. Meta's own guidance is to run the pixel and the Conversions API together, not one or the other, because the server-side path recovers the conversions the browser drops.
Step 1: Choose how to connect
You have three realistic options, easiest first:
- A native platform integration. Shopify, many WordPress plugins, and most major CRMs have a built-in Conversions API connection. You paste an access token, and it handles the sending. This is the right answer for most local businesses.
- A partner integration. Tools like Google Tag Manager's server-side container or a tag-management partner can route events to Meta. More control, more setup.
- A direct API integration. A developer sends events from your server using Meta's API. Most flexible, and the most work. Reserve it for when the first two genuinely can't do the job.
Step 2: Send the same key events you fire in the browser
Mirror your important conversions server-side: the same Lead or Contact you set up in Step 2. Send strong customer-information parameters with each event, like a hashed email or phone number, because the server-side path is where match quality is won or lost. Better matching means Meta attributes more conversions to the right ad.
Step 3: Deduplicate with a shared event_id
Here's the part people get wrong and then panic about. When the same conversion fires from both the browser pixel and the Conversions API, you do not want it counted twice. The fix is to send the same event_id on both copies of the event. Meta matches them and keeps one. No shared event_id means double-counted conversions and a campaign that thinks it's twice as good as it is.
Browser and server send the same event with the same ID. Meta sees the ID twice, says "same conversion," and counts it once. That's deduplication. It's the whole reason you can safely run both paths at the same time.
Step 5: Confirm event quality before you scale
Don't pour budget into a setup you haven't tested. Two tools in Events Manager tell you whether the plumbing holds.
First, the Test Events tool. Open it, then go to your own site and trigger a conversion: submit the form, click the call button. You should see the event appear in real time, and you should see it arrive from both the browser and the server. If only one shows up, one half of your setup isn't firing.
Second, the dataset's event overview and match quality. After events accumulate for a day or two, check that your key event shows a healthy share marked as deduplicated, and that your customer-information match quality isn't sitting in the red. Low match quality is usually a sign your server-side events aren't sending enough customer parameters. Fix that here, before it costs you reach.
How these pieces talk to each other
Once it's all live, the parts have clear jobs. Picture it as one container fed by two pipes:
- The dataset is the container. It's the single source of truth in Events Manager. Both pipes empty into it.
- The browser pixel is the first pipe. It captures on-site behavior fast and feeds optimization while the visitor is still there.
- The Conversions API is the second pipe. It recovers everything the browser drops and carries the strong customer matching that lifts attribution.
- The shared event_id is the valve. It keeps the two pipes from double-filling the container.
- Domain verification is the lock on the container. It decides who's allowed to change the configuration.
Get those five right and your Meta ads finally optimize against reality. That's the entire point. Everything Meta does well downstream depends on the signal being clean upstream.
Common mistakes
The setups we end up rebuilding usually fail in the same handful of ways:
- Running two datasets. Events split across two containers, so neither gathers enough volume to optimize. Consolidate to one.
- Browser pixel only. No Conversions API means you're blind to every conversion an ad-blocker or iPhone prompt hides. That's not a rounding error; it's often a large share of your leads.
- No shared event_id. Both paths fire, nothing deduplicates, and your conversions look inflated until you make decisions on numbers that aren't real.
- Optimizing on a rare event. If your only conversion happens a few times a month, the algorithm can't learn. Optimize on a frequent, high-intent event and keep the deep one as a secondary.
- Setting it up under a personal account. One staffing change and you've lost access to your own conversion history. Own everything at the Business level.
Frequently asked questions
Yes. Meta recommends running both together. The browser pixel captures on-site behavior; the Conversions API fills the gaps the browser misses, like blocked cookies and ad-blockers. Share an event_id between them so Meta deduplicates the matching events instead of counting them twice.
Yes. Meta renamed the pixel to "dataset" inside Events Manager. A dataset is the single container that receives events from both your browser pixel and your Conversions API. Your old pixel ID is now your dataset ID.
No, not by hand. Meta retired the manual Aggregated Event Measurement setup in mid-2025 and now aggregates eligible events automatically. You no longer rank eight events yourself. The underlying idea, optimizing on a clear primary conversion, still matters when you build campaigns.
Fire a Contact or Lead event on the click-to-call button on your site, and send the same event server-side through the Conversions API. For calls placed straight from the ad, use a call-tracking number or Meta's lead tools, since a tap-to-call on the ad itself never lands on your website where the pixel lives.
Meta generally wants around 50 conversions per ad set per week to exit the learning phase. For a low-volume local business, that's the real argument for tracking a top-of-funnel event like Lead or Contact rather than only booked appointments, so the algorithm has enough signal to learn from.
Sources
- Meta for Developers, Conversions API — server-side events, deduplication via
event_id, and running alongside the pixel. - Meta Business Help Center, About Aggregated Event Measurement — iOS measurement; manual configuration retired mid-2025.
- Meta Business Help Center, About domain verification.
- Meta Business Help Center, About the learning phase — approximately 50 conversions per ad set per week.