Native integrations plus GTM
BigCommerce can send GA4 and Meta events natively, and many stores also add GTM or an app that does the same. Each one fires its own purchase, so platforms report more sales than you made.
This is for BigCommerce merchants whose GA4, Google Ads and Meta numbers don't line up with their orders. BigCommerce has native GA4 and Meta connections, Script Manager, theme files and apps that can all add tracking, so stores often end up with three senders for the same purchase. I pick one clean path for each event and back the important ones up server-side.
Proper BigCommerce tracking means one GA4 and one Meta setup, not the native integration plus GTM. GTM is added through Script Manager with the right page locations and consent category, purchases fire on the order confirmation page with the order ID, and server-side GTM sends Meta CAPI and other platforms a backup copy from order data.
The events I set up on BigCommerce, and where each one is sent.
BigCommerce can send GA4 and Meta events natively, and many stores also add GTM or an app that does the same. Each one fires its own purchase, so platforms report more sales than you made.
Scripts are placed on storefront pages, checkout, order confirmation or all pages. Storefront-only scripts never see the checkout or confirmation page, and checkout placement only applies to BigCommerce's Optimized One-Page Checkout.
Every Script Manager script has a consent category. With the cookie banner enabled, a script left in the wrong category may load late or not at all, and tags quietly stop firing.
Stencil themes don't output a full GA4 ecommerce dataLayer for GTM by default. Custom-built events often miss item IDs that match your Merchant Center feed, or skip add-to-cart from quick view and category pages.
On a headless or Catalyst storefront, native script injection and some integrations don't apply. Tracking has to be built into the frontend and the server.
| Event | When it fires | Sent to |
|---|---|---|
view_item_list | Category, brand or search page loads | GA4 |
view_item / ViewContent | Product page or quick view opened | GA4, Meta Pixel + CAPI, TikTok |
add_to_cart / AddToCart | Product added from product, category or quick view | GA4, Meta Pixel + CAPI, TikTok |
begin_checkout / InitiateCheckout | Checkout page loads | GA4, Meta Pixel + CAPI, TikTok |
add_payment_info | Payment step reached in checkout | GA4 |
purchase / Purchase | Order confirmation page loads (once per order) | GA4, Google Ads, Meta Pixel, TikTok |
purchase (server) | BigCommerce order webhook received by server-side GTM | Meta CAPI, GA4, TikTok Events API |
I list every source of tracking on the store and compare recent purchases in GA4, Google Ads and Meta with your BigCommerce orders.
We decide what stays with native integrations, such as product catalogue sync, and what moves to GTM. Everything else is switched off.
I add GTM through Script Manager, build the ecommerce dataLayer and confirmation page purchase, then connect order webhooks to server-side GTM.
I run test orders through each payment method with the cookie banner active, and check every platform counts each order once.
I compare numbers against BigCommerce for two weeks, then hand over the event map and Script Manager notes.
Script Manager is the right place for GTM on a Stencil store. The location setting matters: storefront pages exclude checkout and order confirmation, so a GTM container placed there never sees a purchase. I place GTM on all pages, then let GTM decide what fires where.
The consent category matters too. When the store's cookie banner is on, BigCommerce uses each script's category to decide whether it loads. I set GTM up so it always loads and passes consent state to tags through Consent Mode, rather than having the whole container blocked.
BigCommerce's native GA4 connection and Meta channel are easy to switch on and handle catalogue sync well. For conversion tracking they give you less control over parameters, deduplication and other platforms, and they are the usual cause of duplicate purchases when GTM is added on top.
I usually keep the Meta channel for catalogue and shops features and move conversion events to GTM and server-side GTM, or keep the native events and skip the matching GTM tags. Either works, as long as there's one sender per event.
Add the GTM snippets through Script Manager, set the location to all pages so checkout and order confirmation are covered, and pick a suitable consent category. Older Blueprint themes don't support Script Manager and need theme edits instead.
Common causes are duplicate senders from native integrations and GTM, scripts placed only on storefront pages, consent settings blocking tags, and ad blockers. A server-side purchase from order webhooks closes most of the gap.
You can, but not for the same events. If the native GA4 integration sends purchases, don't send them from GTM too. I usually choose one and document which events it owns.
Meta's BigCommerce channel can send server events. For more control, or to send the same order to Google Ads, GA4 and TikTok, I use server-side GTM fed by the browser and by BigCommerce order webhooks, with shared event IDs.
Yes. On a headless storefront I build the dataLayer into the frontend code and send server events from your backend or order webhooks, since native script injection doesn't apply there.
The step-by-step checklist I use to set up GA4 ecommerce tracking: events, data layer, GTM tags and testing, so product and revenue reports are accurate.
What server-side tracking really is, how server-side GTM works, what it fixes and what it does not, and a checklist to decide if your business needs it.

Meta merges Pixel and server events only when the event name and event ID match. Here is how to set that up correctly and prove it works.
Get a free audit of your tracking and ad account. Usually replies within 1–2 hours.