The full manual process, in the order we run it on client accounts: base code, event coverage, parameters, the Conversions API, deduplication, and consent losses. Plus the shortcut, a free Meta pixel audit that runs 24 of these checks on a live URL in about 20 seconds.
A Meta pixel audit is a structured check that the conversion data leaving your website matches what actually happened on it. Not "is the pixel installed." Installed is the easy part, and it is where most checks stop. The real questions are whether every meaningful action fires an event, whether those events carry the parameters Meta needs, whether they arrive once instead of twice, and whether they survive ad blockers, consent banners, and browser privacy controls.
Broken tracking costs you twice, and the second cost is the expensive one. The first cost is reporting: your ROAS in Ads Manager stops describing reality, so you scale the wrong campaigns and kill the right ones. We wrote a whole guide on that failure mode in why your ROAS numbers are wrong. The second cost is optimization. Meta's delivery system learns from the conversion events you send it. Feed it half your purchases, or purchases with no value attached, and it optimizes toward the wrong people with a smaller, noisier training set. Your ads get worse, quietly, and nothing in the interface tells you why.
That is why an audit is worth doing before anything else in an account. Creative testing, budget scaling, and audience work all assume the measurement layer is honest. If it is not, every conclusion you draw from the numbers is guesswork with a decimal point. Comparing your account against industry benchmarks also means nothing if the denominator is missing conversions.
A complete audit covers four areas. Foundation is the install itself: the right pixel ID, once, on every page, loading early. Event coverage is whether the funnel actions Meta optimizes against actually fire. Data quality is the parameters on those events: value, currency, content IDs, and the customer information used for matching. Resilience is everything that keeps the signal alive when the browser is hostile: the Conversions API, deduplication, consent handling, and domain verification. Those are the same four categories our scanner scores, and the exact weighting is public on the methodology page.
Pixels rarely fail all at once. They fail in specific, repeatable ways, and each failure leaves a different fingerprint. Knowing the shortlist tells you where to look first.
The pixel is on the homepage and missing from the templates that matter. Landing pages built outside the main theme are the classic case: a campaign page ships from a separate builder, the pixel never gets added, and every paid click lands untracked. Close behind is the wrong ID, usually a leftover from a previous agency or a developer's test account, sitting alongside the real one and splitting your data across two datasets. Also common: the pixel loading late, near the closing body tag instead of in the head, so visitors who bounce fast never register at all.
Missing events are usually the deep funnel ones: InitiateCheckout and Purchase live on hosted checkout pages that a theme edit does not touch, so they get forgotten. Duplicates are the opposite problem and are more common than most people expect. A pixel hardcoded in the theme plus the same pixel deployed through Google Tag Manager means every event fires twice. Reported conversions double, your ROAS looks great, and Meta optimizes against inflated signal. If your Ads Manager purchase count is suspiciously close to twice your real order count, this is why.
The event fires, but it arrives empty. A Purchase with no value and no currency tells Meta a sale happened and nothing about what it was worth, which disables value optimization and makes ROAS reporting impossible. Browse events without content_ids break dynamic product ads and catalog retargeting. Lead events without a value make every lead look identical to the algorithm, so it happily buys you the cheapest and worst ones.
Browser-only tracking loses events on every ad blocker, every Safari and Firefox privacy setting, every declined consent banner, and every visitor who closes the tab before the request completes. Those conversions are not delayed, they are gone. A server-side channel is the only thing that recovers them. The tradeoffs between the two channels are covered in Meta pixel vs Conversions API.
This is the failure created by fixing the previous one. Once you add the Conversions API, every conversion has two chances to reach Meta, and without a shared identifier Meta counts both. The fix is an event_id sent on both the browser event and the server event for the same action, plus a matching event_name. Get that wrong and you have replaced a signal loss problem with a double counting problem, which is harder to spot because the numbers look better, not worse.
Consent management platforms often load the pixel as a blocked script until the visitor accepts. That is correct behavior, and it is also invisible to you, because you accepted your own banner months ago and your browser remembers. Every test you run passes. Meanwhile a large share of real visitors decline or ignore the banner and fire nothing. The only way to see it is to clear cookies, reload, decline, and watch what happens.
Check your site against this list, free, in about 20 seconds →This is the sequence, and the order matters. Each step assumes the one before it passed. You need four free tools: Meta Events Manager, the Test Events tab inside it, the Meta Pixel Helper Chrome extension, and your browser's developer tools. No code required for any of it.
Open Events Manager in Meta Business Suite and go to Data sources. Note the exact pixel ID (dataset ID) you expect to be live, and note which events the account is actually optimizing against in your campaigns. An audit is a comparison, so you need the expected state written down before you look at the real one. If you find more than one pixel in the account, decide now which is the real one. Split data across two datasets is one of the most common problems we find, and it cannot be fixed retroactively.
Install the Meta Pixel Helper Chrome extension and load your homepage. It lists every pixel found on the page, the ID for each, and the events fired. Three things to confirm: exactly one pixel ID, and it is the one from step 1; a PageView event firing; and no warnings in the extension panel. Then repeat on a product page, a collection or category page, the cart, and your main contact or lead form page. A pixel present on the homepage and missing from your product template is a very ordinary finding.
Pixel Helper tells you what fired. The network tab tells you exactly what was sent, which is what you need for the parameter checks later. Open developer tools, go to the Network tab, and filter for facebook.com/tr. Reload the page. Every pixel event appears as its own request. Click one and read the query string: id is your pixel ID, ev is the event name, and the cd[...] parameters carry the custom data, including value and currency. Two requests with the same ev on one page load means the event is firing twice, which is the duplicate install problem in its rawest form.
In Events Manager, open your dataset and go to the Test Events tab. Paste your website URL into the field and open the site in the resulting browser session. Now behave like a customer: view a product, add to cart, start checkout, and complete a real purchase. Use a discount code that takes it to a small amount rather than skipping the step, because a checkout you never complete never proves the Purchase event works. Watch each event appear in the Test Events feed as you go. Anything that does not appear is not firing, regardless of what the theme settings claim.
Do the same walk on mobile. Start from a real ad click if you can, on cellular data. Mobile themes, app based checkouts, and accelerated checkout buttons frequently fire different events than the desktop path, and mobile is where most of your traffic is.
Click into the Purchase event in Test Events and read its parameters. It needs a value that matches the order total, a currency, and ideally content_ids and content_type for catalog features. Confirm the value is a number, not a formatted string with a currency symbol in it, which is a frequent theme bug. Then check ViewContent and AddToCart carry content IDs matching the product IDs in your Meta catalog. If the IDs do not match the catalog, dynamic ads cannot retarget the product the visitor actually looked at.
Back in Events Manager, open the Diagnostics tab. Meta lists problems it has detected itself: invalid parameters, missing required fields, events with poor match rates, restrictions on the dataset. Work that list top down. Then open the Overview tab and look at the event match quality score on your Purchase event. That score reflects how much customer information you send with each event, such as hashed email, phone, name, city, and the Facebook click ID. Low match quality means Meta can attribute fewer of your conversions back to ads, which shows up as underreported ROAS. Advanced Matching, enabled in your pixel settings, is the usual fix.
Take the destination URL from each live ad and run steps 2 and 3 on it specifically. Pages built in a separate landing page tool, or campaign pages assembled quickly for a launch, are the single most common place a pixel goes missing, and they are also the pages carrying your paid traffic. Check any URL parameters survive too: if your ads append tracking parameters that a redirect strips, you lose click ID matching.
Open a fresh incognito window, clear cookies, and load your site. When the consent banner appears, decline. Then check the network tab again. If nothing fires for declined visitors, you now know the size of the hole, and you can decide how to handle it: Meta's Consent Mode style handling, a server-side channel, or a banner design that earns more acceptances. Repeat once with an ad blocker enabled, which usually kills browser events entirely, to see exactly what the Conversions API needs to carry on its own.
On a normal store this takes 60 to 90 minutes, and most of that is the funnel walk. Shopify has its own quirks around the pixel sandbox and hosted checkout, which we cover separately in the Shopify pixel audit guide. There are platform guides for GoHighLevel, ClickFunnels, WooCommerce, BigCommerce, Wix, Webflow, and Squarespace as well.
The Conversions API sends events to Meta from your server instead of the visitor's browser. It is the only part of the stack that keeps working when the browser refuses to cooperate, and it is also the part people most often set up once and never verify. Two questions matter: are the server events arriving, and is Meta merging them correctly with the browser events.
For the first, go back to Events Manager and open your dataset's Overview. Meta labels each event with its connection method, so you can see at a glance whether a given event is arriving from the browser, the server, or both. An event that shows browser only, on a site where you believe the Conversions API is live, means the integration is not sending that event. That is common with Purchase specifically, because hosted checkouts often need their own integration step.
For the second, look for the deduplication indicator on events arriving through both channels. Meta deduplicates when two events share the same event_name and the same event_id. The browser event's eventID and the server event's event_id must be identical for the same user action, which means your server has to generate the ID and pass it to the browser, or the browser has to generate it and pass it to your server. Either direction works. What does not work is each side generating its own.
The test is simple. Place one real order. Then check that Events Manager shows one Purchase, not two, and that the deduplication status reflects a matched pair. If you see two, your event IDs are not lining up, and every conversion you report is inflated. If you see one but it is browser only, the server side is not firing at all and you have no protection when the browser event is blocked.
Also confirm the server events carry customer information. A Conversions API event with only an IP address and user agent matches poorly. Hashed email, hashed phone, and the fbc and fbp cookie values passed through from the browser are what raise match quality, and match quality is what turns a delivered event into an attributed conversion.
One last item that is easy to miss: access tokens expire and get revoked. A Conversions API integration that worked for a year can stop overnight when someone rotates a system user token or removes an employee's access. Events Manager will show the event volume drop, but only if you look. That is the argument for a fixed audit cadence rather than an audit when something feels wrong.
Tracking does not break on a schedule, so the answer is a mix of routine and triggers.
If reported conversions fall while clicks and CPMs hold steady, stop and audit immediately regardless of when you last did. That pattern is the signature of a measurement break rather than a performance problem, and it is the first thing to rule out. Ongoing measurement work like this is what our measurement and analytics service handles for clients on a fixed cadence.
The manual audit is thorough and slow. Most of it can be checked from outside the site in seconds, which is why we built the scanner we use internally into a free Meta pixel audit and published it with no login and no email gate.
Paste a URL and it runs 24 checks across the same four categories this guide uses: foundation, event coverage, data quality, and resilience. It reads your page HTML and inline scripts, opens your Google Tag Manager container to see what is deployed inside it, queries Meta's public per-pixel config endpoint to confirm the ID is valid and to check for data restrictions and Advanced Matching, x-rays Shopify's pixel sandbox registry, and crawls up to six pages including the ad landing page you give it. It takes about 20 seconds and returns a scored report with findings ranked by severity.
It is honest about its limits, which is the part that matters for an audit. Hosted checkout events, code sealed inside sandbox pixels, and Conversions API internals cannot be verified from outside, so they are marked needs verification rather than counted as clean. The score is a verified health score: your setup gets credit only for what can be proven externally. The full scoring math, every check, and every deduction is documented on the audit methodology page.
The practical workflow is to scan first, fix what it finds, then spend your manual time only on the handful of items a scan cannot reach: the real test order, the Test Events walk, and the deduplication check in Events Manager. That turns a 90 minute audit into about 30 minutes of work on the things that actually need a human.
Work in four passes. First, confirm the base code: open your site with Meta Pixel Helper and check that exactly one pixel loads, with the ID you expect. Second, confirm event coverage: walk your funnel from ad click to purchase and watch each event fire in the Test Events tab of Events Manager. Third, confirm parameters: check that Purchase carries value and currency, and that browse events carry content IDs. Fourth, confirm resilience: verify the Conversions API is sending the same events with a shared event_id, and reload the site with your consent banner set to reject to see what still fires. The free Meta pixel audit covers most of passes one through three automatically.
A manual audit takes 60 to 90 minutes on a normal store, and most of that is walking the funnel and placing a real test order. An automated first pass is much faster: our scanner runs 24 checks on a live URL in about 20 seconds and hands back a prioritized fix list. The usual pattern is to scan first, then spend the manual time only on the items the scan cannot see from outside, which are hosted checkout events, sandboxed pixels, and Conversions API internals.
Four, and all of them are free. Meta Events Manager, which is where your data sources, diagnostics, and event match quality live. The Test Events tab inside Events Manager, which shows browser and server events arriving in real time. The Meta Pixel Helper Chrome extension, which lists the pixels and events on the page you are viewing. And your browser developer tools, where the Network tab filtered to facebook.com/tr shows every raw request the pixel sends, including its parameters.
Firing is not the same as working. A pixel is working when a real purchase produces a Purchase event that reaches Events Manager within seconds, carries a value and a currency, matches the order total, arrives once rather than twice, and shows a healthy event match quality score. Meta Pixel Helper showing a green check on your homepage only proves that the base code loaded. Test Events, run against a live order, is the check that actually settles it.
Yes, in almost every case. Browser events are lost to ad blockers, tracking prevention in Safari and Firefox, declined consent, and people who close the tab before the pixel fires. The Conversions API sends the same events from your server, so those conversions still reach Meta. It is not a replacement for the pixel. Run both, send a shared event_id on every event that exists in both channels, and Meta deduplicates them into one conversion. The full comparison is in Meta pixel vs Conversions API.
Glance at Events Manager diagnostics weekly, run a short scan monthly, and do a full manual audit once a quarter. On top of that, audit on trigger: after any theme or template update, a new app or plugin, a checkout or platform migration, a consent banner change, a domain change, or a new landing page built outside your normal template. Most broken tracking we find dates to a site change nobody connected to the ad account.
The audit checks 24 things on your live site in about 20 seconds, free, with no login and no email gate. If the fix list is longer than you want to handle, book 30 minutes and we will open Events Manager together and work through it.