BigCommerce gives you two ways to install a Meta pixel and no warning when you use both. This is the audit we run on a BigCommerce store before we touch a campaign: where the duplicates come from, why checkout is the hardest part to verify, and how to settle it in an hour.
BigCommerce tracking lives in two places. The native Facebook channel connects your store to a Meta business and dataset and installs the pixel for you, including on checkout. Script Manager lets you paste any script and choose where it loads, which is how most custom tags get onto a BigCommerce storefront.
Both are reasonable. The problem is that they do not know about each other. A store connects the native integration at launch. A year later somebody pastes the Meta base code into Script Manager because a tagging guide told them to, or adds a GTM container that carries a Meta tag inside it. Now every storefront page load fires the same pixel ID twice, so ViewContent and AddToCart are counted twice and Meta optimizes against a signal that overstates how often people act.
The second structural issue is checkout. BigCommerce restricts the scripts that can run on checkout pages, which is good for payment security and awkward for tracking. A pixel placed on storefront pages generally does not follow the shopper through checkout, so Purchase, the event Meta optimizes hardest against, has to come from the native integration or a server-side path instead. Stores that installed the pixel manually often find everything above the cart is tracked and the sale itself is not.
Five things account for most of what we find. Take them in the order below, because the first one skews everything you would measure after it.
The most common finding. The Facebook channel is connected and a Script Manager entry holds the same pixel ID, so both fire on the same page load.
Why it matters: your reported volume and ROAS inflate, and every budget decision after that is made on inflated numbers. Deduplication does not save you. The event_id mechanism pairs a browser event with a matching server event. Two browser pixels each firing the same event under their own ID count as two separate events on Meta's side.
If your pixel arrived through Script Manager or a theme edit, checkout is the gap. Custom scripts are restricted there, so the shopper leaves your tracked pages at the cart and completes the order somewhere your script does not run. The symptom is a funnel that looks healthy up to InitiateCheckout and then goes quiet, with Meta reporting far fewer purchases than BigCommerce does.
A Purchase that arrives without value and currency tells Meta a sale happened but not what it was worth. Value based bidding cannot work and ROAS reporting stays empty. Check Purchase for value, currency, content_ids, and content_type, and confirm those content IDs match the product IDs in your catalog feed. BigCommerce product IDs, SKUs, and variant IDs are easy to mix up, and a mismatch quietly breaks catalog retargeting.
Open Script Manager and read every entry. Old agency tags, a GTM container from a project that ended, an analytics suite with a Meta tag inside it. Each one is a live install layer. Check the location and pages setting on each script too, because that scope is often the duplicate you are hunting.
Consent tools can block tracking scripts until a visitor accepts, and some regional configurations block by default. You will not catch it yourself, because your browser accepted the banner months ago and has been remembering that ever since. What it looks like from the outside is store session counts running well ahead of Meta's event volume, with no error anywhere to explain the difference. Test in a private window from a region where your banner is enforced.
An hour, with a real test order at the center of it.
Before you test anything, find out how many pixels exist. Check four places:
Write down every pixel ID and where it came from. If the same ID appears twice, you have your first finding.
Open the Facebook channel and confirm it is connected to the right business and dataset, and that the pixel ID matches the one you will watch in Events Manager. Connections lapse after permission changes and asset moves, with no warning on the storefront.
Open Events Manager, choose your dataset, and go to Test Events. Copy the test event code, open your store in a private window, and walk the full path: product page, add to cart, checkout, complete an order. Use a test payment gateway, or a real order you can refund. Watch each event arrive and check it for duplicates and for the parameters that should be attached. This is the only way to settle what happens inside checkout.
Install the Meta Pixel Helper extension and browse your storefront logged out. It is fast at catching a second pixel ID and at flagging missing parameters on product and cart events. Use it for the top of the funnel and let Test Events settle checkout.
Every pixel fire leaves a request behind, and the Network tab in developer tools is where you read them. Filter for facebook.com/tr and start with the ev parameter, which names the event, because that is the fastest way to see whether the fire you expected actually happened. The id parameter beside it names the pixel that sent it, and the rest of the query string is the payload, so you can confirm value, currency, and content IDs without leaving the tab. Two requests carrying the same ev value on one page load is a duplicate you have proven.
When you find two layers sending the same event, keep the one that covers checkout and disable the other. Change one thing, clear your cache, then re-run Test Events so you know which change did what. Fixing three things at once and re-testing at the end is how stores end up with no tracking at all.
Back in Events Manager, check event match quality on Purchase, the diagnostics tab, and whether deduplication is recognized on your browser and server pairs. An event that fires but carries thin customer data is worth less than a clean one. Our full Meta pixel audit guide covers the scoring across platforms.
If you spend real money on Meta, you want a server-side path. Browser events get dropped by ad blockers, by tracking prevention, and by people who close the tab before the pixel finishes. The browser also knows less about the buyer than your order record does, which is where match quality comes from.
The practical routes are a native or app based server-side connection, or a server-side tag container if your team already manages tags that way. The rule is the same either way: one server sender, not two. Two senders plus a browser pixel, with no shared event_id, produce inflated counts that are hard to unpick later.
The check that matters: once your server-side path is live, open a recent conversion in Events Manager and confirm the connection method reads as browser and server deduplicated, not as two separate counts. Two channels sending the same purchase without deduplication is worse than one channel sending it well.
A server-side setup does not stand in for a clean browser pixel. It carries the same events over a second road, which is only worth building once the first road is right. We put the two side by side in Meta pixel vs Conversions API. Expect your reported numbers to shift once the events are trustworthy, which is what why your ROAS numbers are wrong is about.
Most of step 1 and a good part of step 5 can be done for you. Our free Meta pixel audit scans your live store and reports what an outside browser can see: which pixel IDs load, whether the same ID appears in more than one install layer, which funnel events it can find across your product, category, and cart pages, whether those events carry value, currency, and content IDs, and whether a consent banner is sitting in front of your tags. It also reads your Google Tag Manager container and Meta's public config for each pixel ID it finds.
The scan is upfront about the BigCommerce wrinkle. Checkout and the order confirmation page cannot be entered from outside, so Purchase and InitiateCheckout come back marked as needs verification rather than as a pass or a failure, and the same is true of Conversions API delivery. You settle those with a test order in step 3, and we spell out where the line sits on the audit methodology page. It runs in about 20 seconds, with no login and no pixel ID to look up first.
Other platforms fail in their own ways, which is why we cover them separately in our Shopify pixel audit, WooCommerce pixel audit, and Squarespace pixel audit guides. If you would rather someone else own it, that is what our eCommerce practice does: tracking verified before any campaign work, then kept verified while spend scales.
Usually because the native Facebook integration and a Script Manager script are both live with the same pixel ID. The channel install adds the pixel on its own, and a script pasted into Script Manager or a theme file adds it again, so storefront events count twice. Keep one install layer and remove the other, then walk the funnel again with Test Events open. Deduplication by event_id only pairs a browser event with a matching server event, so it will not merge two browser pixels.
BigCommerce restricts what custom scripts can run on checkout, so a pixel pasted into your theme or set to storefront pages generally does not follow the shopper into checkout. Purchase usually has to come from the native Facebook integration, from a script placed specifically for the order confirmation page where your plan allows it, or from a server-side path. Confirm which one is live by placing a test order with Test Events open in Events Manager.
For most stores the native integration is the better default, because it covers checkout, which is the part a manual script struggles to reach. Script Manager is the right tool when you need something the integration does not offer, such as a custom event or a tag your team already manages. What you should avoid is running both with the same pixel ID for the same events, because that is the duplicate that inflates your numbers.
No, and any tool that says otherwise is guessing. Your product, category, and cart pages are readable from outside, so duplicate installs and missing storefront parameters can be caught by a scan. Checkout and the order confirmation page only exist inside a real transaction, so Purchase is reported as needs verification. You settle it yourself with a test order in Test Events.
If you spend meaningfully on Meta, yes. Browser events are lost to ad blockers, tracking prevention, and closed tabs, and your order record carries better customer data than the browser does. A native or app based server-side path is the usual route, with a server-side tag container as the alternative. Run one server sender, then confirm in Events Manager that conversions show a deduplicated browser and server connection rather than two separate counts.
Every store we take on starts with tracking verified end to end: one install layer, Purchase confirmed through a real checkout, a server-side path live, deduplication checked. Scan your store yourself in 20 seconds, or have us walk it with you.