BigCommerce conversion tracking means capturing every order on your storefront and delivering it accurately to Google Ads, Meta, and Microsoft. The platform’s only built-in surface for it, Affiliate Conversion Tracking, predates the modern ad stack. A reliable setup combines a site-wide capture script, a purchase event on the order confirmation page, and server-side delivery.
Search this term and the top result is BigCommerce’s own support article about passing order data to affiliate programs. Position two is an unanswered community question asking how to implement Google Ads enhanced conversions. Further down sit a Reddit thread asking why BigCommerce order counts and Google Ads conversion counts disagree, a YouTube tutorial from the conversion-code era, and two affiliate network integration docs.
That is not a search results page, it is a misunderstanding. The person typing the query wants their ad campaigns to see every order. The platform hears “conversion tracking” and answers with a settings panel it built for affiliate networks, and Google, taking its cue from the platform’s own documentation, files the entire query under the parent topic “affiliate conversion tracking”. Nobody on page one answers the question actually being asked. So let’s answer it.
The three surfaces BigCommerce gives you
Everything you can do about conversion tracking on BigCommerce runs through one of three surfaces, and they are not interchangeable.
| Surface | Where it runs | What it can see | What it can deliver |
|---|---|---|---|
| Affiliate Conversion Tracking (Settings > Web Analytics) | Order confirmation page only | Five template variables: order ID, order total, total in cents, subtotal, customer email | Nothing by itself. It renders whatever script you paste |
| Script Manager | Storefront pages, checkout, order confirmation | Whatever your script captures in the browser | Nothing by itself |
| Native channel integrations (GA4, Google, Meta pixels) | Browser, on pages the vendor tag covers | Standard pixel events | Browser-fired hits to each platform |
Two details in that table decide whether your purchase tracking works at all.
First, the Affiliate Conversion Tracking box is the one surface guaranteed to render exactly once per completed order, with order data interpolated by BigCommerce itself before the page reaches the browser. The variables are a small, fixed set (%%ORDER_ID%%, %%ORDER_AMOUNT%%, %%ORDER_AMOUNT_IN_CENTS%%, %%ORDER_SUBTOTAL%%, %%ORDER_EMAIL%%), designed in an era when an affiliate network needed an order total and nothing else. No line items, no currency code, no click ID. But an order ID, a value, and a customer email are exactly the minimum a modern conversion event needs, which makes this legacy slot quietly the most dependable purchase trigger on the platform.
Second, Script Manager scripts do not render on checkout or order confirmation unless the store runs Optimized One-Page Checkout. New Stencil stores have it by default; older stores have to switch it on manually. This is the silent failure mode behind a large share of “my purchase tag never fires” threads: the script is installed, the preview looks fine on storefront pages, and the one page that matters never loads it.
Capture points, not delivery systems
Here is the reframe that the tutorials skip. Every surface in that table is a capture point. None of them is a delivery system.
Pasting a Google Ads conversion snippet into the affiliate slot records the order in the browser and fires it from the browser. That is 2019-grade tracking, and it inherits every browser-grade loss: ad blockers eat the request on a meaningful slice of desktop traffic, Safari’s ITP caps JavaScript-written cookies at seven days so the gclid from last week’s click is gone by the time the order lands, and Firefox strips tracking parameters on top. Native browser tracking misses roughly a third of conversions across a typical store’s traffic mix, which is precisely the gap that server side tracking exists to close, and why the Reddit thread about BigCommerce orders disagreeing with Google Ads numbers has no good answer inside the browser.
Delivery is a separate job: getting the captured conversion to each ad platform’s server API (Google’s click conversion uploads, Meta’s Conversions API, Microsoft’s CAPI) with the click ID and hashed customer data attached, so the bidding systems learn from complete outcomes rather than the subset that survived the browser. If the platforms only see the surviving subset, they bid as if the missing buyers do not exist, and they bid down hardest on the segments where tracking fails most, which on BigCommerce’s desktop-heavy B2B stores is often the most valuable traffic.
The structural difference from WooCommerce
On woocommerce conversion tracking the honest answer is a server-side plugin: WooCommerce is self-hosted PHP, so code can hook woocommerce_payment_complete and emit the purchase event from the server whether or not the buyer’s browser cooperates. BigCommerce is SaaS. You cannot run your code on BigCommerce’s servers, so that architecture is simply unavailable, the same constraint that shapes shopify server side tracking.
That leaves exactly two ways to get server-side delivery on BigCommerce. You can stand up your own tagging infrastructure (a server GTM container you host, administer, and pay for per request) and route events through it. Or you can use a managed capture and delivery layer, where a storefront snippet does the capture and someone else’s infrastructure does the delivery. Convultra is the second kind, so read what follows knowing where we sit. The choice is a real one and depends on whether you want to own tagging infrastructure, but “do nothing and let the pixels handle it” is not one of the two options, it is the 30 to 40 percent gap.
The setup that works
Three steps, using BigCommerce’s surfaces for what each is actually good at.
Step 1: capture on every page. Add your tracking snippet via Script Manager (location: Footer, pages: All pages, category: Essential). Its job on landing is to grab whatever click ID the visitor arrived with (gclid, gbraid, wbraid, fbclid, msclkid, or oppref from ChatGPT ads) and persist it first-party at the server so Safari’s seven-day JavaScript cookie cap never applies. Convultra’s snippet holds click IDs for 90 days, which matches the platforms’ own click windows.
Step 2: fire the purchase where BigCommerce interpolates the order. Paste the purchase event into the Affiliate Conversion Tracking box, letting the template variables do the work:
<script>
Convultra.trackPurchase({
orderId: '%%ORDER_ID%%',
value: %%ORDER_AMOUNT%%,
currency: 'USD',
email: '%%ORDER_EMAIL%%' // hashed with SHA-256 before it is sent to any ad platform
});
</script>The queue stub in the dashboard snippet matters more than it looks: the call is queued even if the main SDK has not finished loading, so there is no race between your tag and the confirmation page’s other scripts. The email flows into hashed enhanced-conversion match data, which is the answer to that unanswered community question about enhanced conversions on BigCommerce: the data was on the confirmation page all along, in %%ORDER_EMAIL%%.
Step 3: deliver server-side. The captured order, click ID, and hashed identifiers go out from the server to Google Ads (click conversion uploads plus enhanced conversions) and OpenAI Ads today. Meta (Conversions API with a shared event ID so pixel and server events deduplicate), Microsoft Ads, and TikTok delivery are coming soon. This is the step no BigCommerce setting performs, and the one that makes the numbers reconcile.
One honest note on our own fit: Convultra has no BigCommerce app in the marketplace, and our platform auto-detection currently recognizes WordPress, Shopify, and Wix, not BigCommerce. The install is the generic one-line snippet plus the purchase event above, about ten minutes with Script Manager open. If you want a one-click app-store install, we are not that today.
When the numbers still look wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| Purchases missing entirely | Optimized One-Page Checkout disabled, so confirmation-page scripts never render | Enable it, or move the purchase event to the affiliate slot |
| Google Ads shows fewer conversions than BigCommerce orders | Browser-only firing losing ad-block and iOS traffic | Server-side delivery with click IDs captured at landing |
| Conversions recorded but unattributed | Click ID expired in a seven-day JavaScript cookie before purchase | Persist click IDs server-set and first-party at landing |
| Conversions double-counted | Pixel and server API both firing without a shared event ID | Deduplicate on one event ID minted at purchase |
| Manual and phone orders never appear | No confirmation page ever renders, so no script fires | Track offline orders via API upload, not the storefront |
What none of this fixes
A visitor who declines consent is untracked, lawfully, and stays that way. A click ID that Safari’s Link Tracking Protection stripped before the landing page loaded cannot be recovered by any capture discipline. An order placed over the phone renders no confirmation page and fires no script, the row above is a workaround rather than a fix. And headless Catalyst storefronts sidestep Script Manager entirely; there the snippet goes into your own build, which is more work and more control. Recovered tracking is a record of demand, not a source of it. What it changes is whether your bidding platforms learn from all of your orders or two thirds of them.
FAQ
Does BigCommerce have built-in conversion tracking?
Only in the affiliate sense. The Affiliate Conversion Tracking panel renders a script once per order with basic order variables, and native channel pixels fire browser events. Neither delivers conversions to ad platform server APIs, which is what conversion tracking means for paid media in 2026.
Why does Google Ads show fewer conversions than my BigCommerce order count?
Because browser-fired tags are blocked or expired for a meaningful share of buyers: ad blockers, Safari ITP’s seven-day cookie cap, and stripped parameters. The orders exist; the browser events reporting them do not. Server-side delivery closes most of the gap.
Can you run server-side tracking on BigCommerce?
Yes, but not on BigCommerce’s servers. Capture happens in the storefront via Script Manager or the affiliate slot, and delivery happens from external infrastructure, either a server GTM container you operate or a managed service.
What order data does BigCommerce expose on the confirmation page?
Five template variables: %%ORDER_ID%%, %%ORDER_AMOUNT%%, %%ORDER_AMOUNT_IN_CENTS%%, %%ORDER_SUBTOTAL%%, and %%ORDER_EMAIL%%. No line items, no currency code, no click IDs, so anything beyond a basic purchase event has to be captured earlier in the session.
Do enhanced conversions work on BigCommerce?
Yes. Hash the customer email from %%ORDER_EMAIL%% and include it with the conversion sent to Google. There is no native toggle for it, which is why the platform’s own community forum question on the topic sat unanswered.
Convultra captures every click ID at landing, fires purchases from the confirmation page, and delivers them server-side to Google Ads and OpenAI Ads today (Meta and Microsoft Ads coming soon) with server side conversion tracking and about a 98 percent match rate on the conversions it captures. Start free and see your first recovered BigCommerce conversions the same day.