Wix installs the Meta pixel for you in a couple of clicks, which is why the duplicate install is the first thing we look for. This is the audit we run on a Wix site before we touch a campaign: where the duplicates come from, what the native integration will and will not send, and how to verify the rest.
Wix handles the Meta pixel through its marketing integrations. You connect your Meta account, pick a pixel, and Wix loads it across the site. No code, nothing to maintain. For most sites that is the right choice.
The trouble starts when someone adds the pixel a second way. Wix also lets you paste custom code into the site header, and plenty of tracking guides tell you to do exactly that. Or you add a Google Tag Manager container for other tags and it carries a Meta base code tag inside it. Now the same pixel ID loads twice on every page, every event on top of it is counted twice, and Meta optimizes against a signal that overstates how often people act.
The second thing to understand about Wix is how little of the tracking you control. The native integration sends the events it is built to send, and it does not hand you a panel for editing parameters event by event. If you need a specific value on a lead, a currency on a sale, or a content ID that matches your catalog, you are into custom code, and on Wix that means Velo. Plenty of sites never need that. The ones that do usually find out after building campaigns around a value that was never attached.
Third, changes do not go live until you publish. It sounds obvious, and it is one of the most common reasons a Wix pixel appears broken. The fix was made in the editor weeks ago and the live site never received it.
Most of what we find on Wix comes down to five things. Start at the top, because a duplicate install distorts every check that follows it.
The most common finding. The Meta integration is connected, and the same pixel ID also sits in a custom code block or a GTM container. Both fire on every page load.
Why it matters: your reported volume and cost per result both mislead you, and the budget decisions on top of them are wrong in the same direction. Deduplication does not save you. The event_id mechanism pairs a browser event with a matching server event. As far as Meta is concerned, one event sent twice by two different pixel IDs is two events that both happened.
Wix custom code lets you choose which pages a snippet loads on. A pixel set to load on the homepage only looks healthy when you test the homepage and vanishes on the pages where your conversions happen. Open every custom code entry and read its page scope, not just its content.
Check that the action you care about produces an event. Form submissions, bookings, and embedded schedulers are the usual gaps, because a confirmation inside an iframe or after a redirect is not something a base pixel notices on its own. If your campaigns optimize for a conversion that never arrives, you are paying for traffic rather than customers.
Value, currency, and content IDs are what make value based bidding and catalog features work. The native integration attaches what it attaches, and there is no settings field for adding more. Verify in Test Events what is arriving before you decide anything is missing, then treat Velo custom code as the last resort rather than the first move.
Cookie banners can block tracking until a visitor accepts, and some regional configurations block by default. Your own browser stopped showing you the banner the day you accepted it, so every check you run passes. The only symptom is Meta counting fewer events than your site counts sessions, month after month, with nothing in either tool flagging it. Test in a private window from a region where your banner is enforced.
Under an hour, start to finish.
Before you test anything, find out how many pixels exist. Check three places:
Write down every pixel ID and where it came from. If the same ID appears twice, that is your first finding.
Open the Meta integration and confirm it is connected to the right account and that the pixel ID matches the dataset you will watch in Events Manager. Then confirm the site has been published since your last change. An unpublished fix is one of the most common findings here.
Open Events Manager, choose your dataset, and go to Test Events. Copy the test event code, open your published site in a private window, and walk the path that matters: the landing page, the key content page, then the form submission, booking, or purchase you optimize for. Watch each event arrive once, not zero times and not twice, and check its parameters. This check shows what Meta received rather than what your page tried to send.
Install the Meta Pixel Helper extension and browse your live site. It is quick at catching a second pixel ID and at flagging missing parameters on the events it can see. Use it as a first look, and let Test Events settle anything ambiguous.
Load a page with developer tools open, filter the Network tab for facebook.com/tr, and count. One PageView request per page load is correct. Two is the duplicate install, proven rather than suspected, and the id parameter on each request tells you which pixel sent which. Open either request and the ev parameter names the event, while the remaining parameters show what was attached to it.
Keep the install layer that covers the most of your funnel, remove the other, publish, and re-run Test Events. Fixing three things at once and testing at the end is how sites end up with no tracking at all.
Back in Events Manager, check event match quality on your main conversion, the diagnostics tab, and whether the events you rely on are standard events rather than custom ones. 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.
Browser events get dropped by ad blockers, by tracking prevention, and by people who close the tab before the pixel finishes. A server-side path sends the same conversion from a server with the customer data you already hold, which is what raises match quality.
On Wix the routes are narrower than on a self-hosted site: what the platform and its app ecosystem offer, or a setup built with Velo. The rule does not change either way. One server sender, not two, and a shared event_id between the browser event and the server event for the same action.
The check that matters: after any 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 conversion without deduplication is worse than one channel sending it well.
Treat the Conversions API as a second delivery route for events you have already cleaned up, not as a way to skip cleaning them. Meta pixel vs Conversions API lays the comparison out in full. And when the events are finally right, the reported numbers will move, which we cover in why your ROAS numbers are wrong.
Most of step 1 and a good part of step 5 can be done for you. Our free Meta pixel audit scans your live site and reports what an outside browser can see: which pixel IDs load, whether the same ID appears in more than one install layer, which events it can find across the pages it crawls, whether those events carry value, currency, and content IDs, and whether a cookie banner sits in front of your tags. It also reads your GTM container and Meta's public config for each pixel ID it finds.
The scan is upfront about its limits. Anything behind a form submission, inside a booking iframe, or on a page that only exists after a real transaction cannot be entered from outside, so those 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 Test Events in step 3, and we spell out where the line sits on the audit methodology page. Twenty seconds, no login, and you do not need your pixel ID to start.
Other builders fail in their own ways, which is why we cover them separately in our Squarespace pixel audit, Webflow pixel audit, and Shopify pixel audit guides. If you sell through Wix Stores, the same duplicate and parameter checks apply, and our eCommerce practice covers what comes after the audit: tracking verified before any campaign work, then kept verified while spend scales.
Because the pixel is installed in two places. The native Meta integration in your Wix marketing integrations adds the pixel, and the same pixel ID also sits in a custom code embed or in a Google Tag Manager container you added yourself. Both fire on the same page load, so PageView and the events on top of it count twice. Keep one install layer, remove the other, publish, then retest. Event ID deduplication will not merge two browser pixels, it only pairs a browser event with a matching server event.
Check five things in order. That the integration is still connected and shows the pixel ID you expect. That the pixel ID matches the dataset you are watching in Events Manager. That you published the site after making the change, since editor changes do not go live on their own. That your custom code embed is set to load on the pages you care about rather than on the homepage only. That your cookie banner is not blocking the pixel for visitors who have not accepted. Then run Test Events and watch what actually arrives.
Only within what your setup supports. The native integration sends the events it is built to send, and it does not give you a field for editing parameters on each one. If you need a specific value, currency, or content ID on an event, that usually means custom code, and on Wix that means Velo. Before you build anything, verify in Test Events which parameters are already arriving, because the integration may already be attaching more than you assume.
Not for the common problems. Duplicate installs, a disconnected integration, an unpublished change, and a consent banner blocking the pixel are all fixed in settings. Velo becomes relevant when you need an event the platform does not fire on its own, or parameters the integration does not attach. Fix the settings level problems first, retest, and only then decide whether custom code is worth the maintenance.
Use Events Manager Test Events, because it shows what Meta received rather than what your page tried to send. Open your dataset, copy the test event code, browse the live published site in a private window, and complete the action you care about. Watch each event land once, not zero times and not twice, and check the parameters attached to it. Meta Pixel Helper and the network tab are useful second opinions on the pages you can reach.
Every account we take on starts with tracking verified end to end: one install layer, the conversion that matters confirmed in Events Manager, parameters checked, deduplication confirmed where a server path exists. Scan your site yourself in 20 seconds, or have us walk it with you.