How to install the Facebook pixel on Wix

Wix has a native Meta integration, which makes installation one of the simplest in this cluster. What is not simple is what comes after: two platform quirks erase events silently, and both happen with a perfectly correct setup.

The native path

Under marketing and SEO, in the marketing integrations area, there is a dedicated Meta pixel field. You enter the pixel ID — the 15 or 16 digit string from Events Manager — and the platform handles the rest.

If the site has a Wix store, the integration already fires commerce events: product view, add to cart, checkout start and purchase. You configure nothing beyond the number.

Menu names change over time. What you are looking for is a field expecting a number, in the marketing area.

When custom code is worth it instead

The native integration covers the standard funnel. Custom code earns its place in two cases:

• Events the integration does not have. A click on a specific button, a form submission outside the store, a scroll milestone.
• Parameters you need to control, like your own product ID or custom categories.

Outside those, code adds a layer that can break and improves nothing. And running both for the same event lands you in the duplication problem two sections below.

The quirk nobody warns you about: consent

This is the most frequent cause of "my events dropped for no reason" on Wix sites.

The platform has a cookie consent banner, and the Meta pixel is categorized as a marketing tool. When someone declines marketing cookies, the pixel does not fire. That is correct behavior and legally necessary — and it cuts your event volume with no change to any campaign.

The practical effect: if 40% of visitors decline, you lose 40% of events, and Meta sees a smaller funnel than the real one. Cost per result in the report rises, because the conversion denominator shrank.

There is no trick here, and looking for one would be a bad idea. What exists is knowing this happens, so you do not investigate creative when the cause is consent. If the drop coincides with the banner going live, you found your explanation.

The second quirk: edit mode

Wix has an editing environment and a published site. Code pasted and not published does nothing, and the integration saves but only takes effect after publishing.

It sounds obvious written down, and it is the second most common cause of a setup that "does not work". Before redoing anything, confirm the live site is the version carrying the configuration.

The mistake that doubles your sales

Two sources firing the same event: the native integration plus custom code you pasted "to be safe".

The symptom is exactly double the real conversions, with a good-looking ROAS and a bank account that disagrees. The fix is picking one source per event and turning off the other.

Worth inspecting the custom code on any site that passed through several hands: a pixel pasted twice in the header is more common than it sounds, and the symptom is identical.

Order value

Without the value parameter, an US$ 90 order and a US$ 1,500 one count the same. The algorithm optimizes event volume instead of revenue, and the report has no ROAS.

Open Events Manager, go into the purchase event and confirm value is there. If it is not, fix that before touching audience or creative — highest return on the list, and the most ignored.

How to confirm it works

1. Events Manager, recent pixel activity.
2. Accept cookies when you enter your own site, so you are not testing the blocked case.
3. Browse as a customer: home, product, cart, checkout.
4. Confirm the event sequence and the value inside the purchase.
5. Repeat declining cookies and watch what stops firing. That is the size of your blind spot.

Step 5 fixes nothing but informs a lot. Knowing 40% of events do not exist changes how you read the entire report.

Why numbers do not match the store dashboard

Wix counts orders; Meta counts conversions attributed to ads within a window — and, on Wix, only from people who accepted marketing cookies.

That stacks three sources of difference: attribution, window and consent. Which is why the gap here is usually larger than on other platforms, and does not indicate a broken setup.

A 20% to 30% difference is plausible on a site with an active consent banner. A 90% difference is broken. The crediting period behind part of it is in attribution window.

When the Conversions API helps here

With consent declined, neither the pixel nor the API should fire — the legal basis is the same for both, and sending server-side does not route around a refusal.

Where the API genuinely helps is the other problem: restrictive browsers and ad blockers erasing events from people who did accept. There, server-side sending legitimately recovers what the browser lost.

The threshold: if the gap exceeds roughly 20% after ruling out consent and setup, it is worth implementing.

The mid-funnel events that pay for the work

A store measuring only purchases cannot diagnose anything. The middle events show where the funnel breaks:

• Carts in volume, no purchases. The bottleneck is checkout: shipping, timing, payment.
• Checkout starts without purchases. Usually shipping cost revealed at the end.
• Product views without carts. Price, photo or description.

Without those columns, every problem looks like a creative problem, and you swap ads when you should change shipping. The landing-page side is in landing page not converting.

One pixel, always

A site that has been advertising for a while tends to accumulate pixels: one from the old agency, one from whoever touched the site, one created by accident while setting up Business Manager. Then someone has to choose, and the temptation is to create a clean new one.

That is the worst option. Conversion history is what trains the algorithm, and a new pixel starts at zero — cost per result rises for the first few weeks and nobody understands why.

The right move is picking the pixel with the most history, entering it in the integration, and abandoning the others without deleting them. Deleting erases the history permanently; abandoning leaves the data there in case you need to check something old.

When nothing fires at all

In order, most common to least:

1. Site not published after saving the configuration. The live version does not carry it.
2. Free plan without access to the integration or code area.
3. Pixel ID with a typo. One wrong digit creates a pixel that does not exist, and nothing warns you.
4. Cookies declined in your own test session.
5. Pixel belonging to another ad account, collecting where you are not looking.

Item 4 catches people testing their own site with a privacy-minded browser. Accept the banner before concluding the setup is broken.

Before you scale

With the pixel measuring purchases and values, and knowing the size of your consent blind spot, accumulate enough volume to read a result before raising budget. The criteria are in when to scale a campaign, and the reporting routine on the paid media reporting page.