Wix Conversion Tracking: What Works, What Doesn't, and How to Fix the Gaps

Wix is the platform I get the most "my Google Ads conversions just stopped counting" emails about. Not because Wix owners are careless, but because Wix gives you less tracking control than any other major builder, so when something breaks there's no obvious knob to turn. Here's what the native integrations really do, where they fall short, and the escape hatches that work.

What does Wix's native conversion tracking actually do?

Wix's built-in integrations connect your site to Google Analytics 4, the Meta pixel, and Google Ads through the dashboard, and for Wix Stores they fire the standard ecommerce events (product views, add to cart, checkout, purchase) automatically. That part works. You paste an ID, Wix injects the tag, events flow.

The problem is everything you can't see. You don't control which parameters ride along, you can't inspect the payload before it fires, and the automatic events only cover Wix's own commerce flows. Custom forms, quizzes, third-party embeds — the native integrations mostly shrug.

Three gaps bite hardest in my audits:

• Event deduplication. If you've pasted your own Meta pixel on top of the native integration (very common), purchases fire twice. Dedup needs a matching event_id on both events; Wix gives you no way to set or even see one.
• Conversion value on custom flows. Wix Stores purchases carry a value; conversions from forms, bookings, or custom checkouts usually report without one, so Google Ads can't optimize for revenue. The exact behavior differs between Stores, Bookings, and Events, so test your own vertical with a real transaction.
• No visibility. There's no debug surface inside Wix. You're testing from the outside with Tag Assistant and Meta's Test Events tool, guessing at what Wix injected.

1. Check the tag is on the page — View source and search for your AW- conversion ID. Custom code is gated to paid plans.
2. Test your trigger on a real order — Wix checkout can update the URL without a page load, so page-view triggers miss it.
3. Hunt for duplicate tags — The native Google integration plus a pasted gtag snippet means two sources reporting.
4. Accept what the browser eats — Ad blockers and ITP hit Wix like any site. Only a server-side setup routes around it.

Why is my Google Ads conversion tracking not working on Wix?

Nine times out of ten it's one of four causes: the conversion tag never made it onto the site because custom code is gated to paid plans, the page-URL trigger misses Wix's dynamically rendered thank-you page, duplicate tags double-count, or the browser blocked the tag. Work through them in that order.

1. Check the tag is actually on the page. Wix only lets you add custom code (your Google tag or conversion snippet) on a premium plan with a connected domain. Wix has changed this gating before, so check the current plan comparison rather than an old blog post. On a free or entry plan, the snippet you "installed" may never have rendered. View source, search for your AW- conversion ID.
2. Check your trigger against how Wix navigates. Parts of the Wix checkout behave like a single-page app: the URL updates without a full page load, so a tag triggered on "page load of /thank-you" can miss the actual order confirmation.
3. Hunt for duplicates. Native Google integration plus a manually pasted gtag snippet means two sources reporting. The conversion action's diagnostics flag some of this, not all.
4. Accept what the browser eats. Ad blockers and Safari's tracking prevention (WebKit's ITP caps script-set cookies at seven days) hit Wix like every other site. No Wix setting fixes this; only a server-side setup routes around it.

Can I use Google Tag Manager on Wix?

Yes, but GTM on Wix runs with one hand tied: Wix exposes no ecommerce dataLayer. On Shopify or WooCommerce I can push a full purchase object (items, value, currency, transaction ID) into the dataLayer and let every tag read from it. On Wix, GTM lands on the page with nothing to read. Your triggers are limited to page views, clicks, and element visibility — brittle stuff that breaks the next time the template changes.

That's why a GTM tutorial written for WordPress fails quietly on Wix. The container installs fine. The tags just have no data.

What is Velo, and when should I use it for tracking?

Velo is Wix's built-in development platform, and it's the sanctioned escape hatch for custom events. From page code you can call Wix's trackEvent API to send named events (add to cart, purchase, lead, or fully custom events) to your connected analytics tools, with your own parameters attached. That gets you what the point-and-click integrations can't: a conversion for your custom quiz funnel, a lead event with a value, an event that fires on the actual button click instead of a URL guess.

Velo also runs backend code, and that matters more than most owners realize: Wix can execute code when an order is paid, and that's the hook we use to get order data out to somewhere you control. More on that below.

Two honest caveats. Velo is JavaScript; if nobody on your team writes code, this is hire-someone territory. And browser-side Velo events still die to the same ad blockers and ITP limits as any other tag — Velo widens what you can track, not how reliably the browser delivers it.

Layer	What sits there
Inputs	Wix order paid event, Velo backend code, Velo trackEvent custom events
track.yoursite.com	Server GTM sets the event_id, attaches order value and hashed customer data
Destinations	Google Ads, GA4, Meta CAPI

Do I need first-party server-side tracking on Wix?

If you're spending real money on Google or Meta ads, yes — and Wix's limits make the case stronger, because it's the one fix that doesn't depend on what Wix lets you touch. Plain language first: server-side tracking means conversion data doesn't only travel from the shopper's browser to Google and Meta. It also travels from a server you control — on your own subdomain, like track.yoursite.com — straight to the platforms' APIs. "First-party" means the cookies and requests belong to your domain, so browsers treat them as your site's own data instead of third-party tracking to throttle.

Why that matters specifically on Wix:

• It recovers the conversions browsers block. Ad blockers and Safari's privacy rules are invisible to a server-to-server call. The order happened; the server reports it. On a platform where you can't harden the browser side anyway, that reliability can't be built any other way.
• It restores the control Wix took away. You set the event_id for clean deduplication, attach real order values, and send hashed customer data that lifts Meta's Event Match Quality — which is what the platforms optimize and bid on.
• Wix already has the exit door. Wix can notify an external endpoint when an order is paid, via Velo backend events or automation webhooks. That order data flows into a server-side Google Tag Manager container on your subdomain, which forwards it to Google Ads, GA4, and Meta CAPI — one source of truth, properly deduplicated.
• Your data outlives the platform. First-party cookies on your subdomain last longer under ITP, and if you ever leave Wix, the tracking layer comes with you.

Without this, your Google Ads numbers are the browser's best effort minus everything blocked or dropped. With it, the gap between real orders and reported conversions gets small enough to bid on confidently.

When is Wix fine as-is, and when is it the ceiling?

Keep the native setup if you're a content site or a small Wix Stores shop spending little on ads: imperfect data on a $300/month budget costs less than the fix. Add Velo events plus first-party server-side tracking when ad spend is real, when leads come through custom flows, or when Google Ads and your order list disagree by more than a rounding error.

And sometimes Wix is genuinely the ceiling. If your roadmap needs subscription logic Wix doesn't model, multi-step funnels with per-step values, or integrations the webhooks can't express, you can burn months fighting the platform. I've told owners plainly: replatforming (Shopify or WooCommerce, where full dataLayer control is native) is sometimes cheaper than another year of workarounds. That's the minority — most Wix stores get to trustworthy numbers with the webhook-to-server-side route. But it's dishonest to pretend the ceiling isn't there.

Frequently asked questions

Why is my Wix Google Ads conversion tracking not working?

Usually one of four things: the snippet isn't rendering because custom code requires a premium plan, the page-URL trigger misses Wix's dynamic order confirmation, duplicate tags are muddying the data, or browsers are blocking the tag. Verify the tag in page source first, then test a real order with Tag Assistant.

Does Wix have a dataLayer for Google Tag Manager?

No. Wix doesn't expose an ecommerce dataLayer, so a GTM container has no purchase data to read. Push events yourself with Velo or move the data server-side through order webhooks.

Can Wix send conversions to the Meta Conversions API?

Not with meaningful control from the dashboard. The reliable route is sending order data from Wix (Velo backend events or webhooks) to a server-side GTM container, which forwards purchases to Meta CAPI with a proper event_id.

Do I need a paid Wix plan for conversion tracking?

For anything beyond the built-in integrations, yes — Wix gates custom code behind premium plans with a connected domain. If your snippet isn't showing in page source, check your plan first.

Is Velo good enough to fix Wix tracking on its own?

Velo fixes coverage (custom events, real values, correct triggers) but not delivery: its browser events still get blocked like any other tag. Pair it with server-side tracking for reliability.

Should I leave Wix because of its tracking limits?

Usually no. Order webhooks feeding a first-party server-side setup get most Wix stores to trustworthy numbers. Replatform only when your funnel itself needs things Wix can't model.