BigCommerce · Analytics
BigCommerce analytics agency
Measurement on BigCommerce starts with two structural advantages. Checkout sits on the store's own domain, and tags are installed through a manager that controls exactly where each one runs. The work is using that control properly, then reconciling what the platform, the analytics tool and each ad account report for the same week.
What BigCommerce changes
Platform facts that shape the work
These are true of BigCommerce today and they decide the approach before any strategy does.
Script Manager is the tag surface
Every tag is registered with a page scope, a document location and a load behavior. That gives a readable inventory of what runs where, and it also makes an accidental duplicate simple to create and, fortunately, simple to find.
Checkout stays on the same domain
Because checkout is served from the store's domain, sessions are not broken by a hop to another host and referral exclusions are rarely needed. Channel attribution is cleaner here than on architectures that hand off to a separate checkout domain.
The platform reports from its own data
BigCommerce produces order, product and customer reporting from the store record. Those figures will not match an analytics tool, and they should not, because the order record is the ledger for anything involving money.
APIs and webhooks support server side work
Orders and customers can be read through the platform APIs and pushed through webhooks, which makes server side event delivery and warehousing straightforward without adding anything to the storefront templates.
Channels split revenue at source
Storefronts and marketplace connections record orders against a channel, so revenue can be attributed to where it came from. Analytics has to mirror that split deliberately or a multi storefront business reports as one undifferentiated total.
The work
Item by item, inside BigCommerce
Definitions before tags
Written agreement on what counts as an order, what revenue includes, how a new customer is identified and which channel taxonomy the business uses, so later dashboards describe the same business rather than three versions of it.
Tag inventory cleanup
Every Script Manager entry traced to an owner and a purpose, duplicates removed, page scopes tightened, and anything left over from a previous agency or a trial switched off rather than left loading on every page.
Ecommerce event implementation
A complete event set from product view through add to cart, checkout start and purchase, with consistent item identifiers that match the catalog and the feed so product level reporting joins up across tools.
Server side delivery
Order webhooks used to send purchase and refund events from a server container, which keeps conversion data stable when browsers block scripts and lets refunds be reflected rather than left as permanent revenue.
Consent handling
Consent captured and passed to each tool that needs it, with tags scoped so nothing loads before permission, and a clear account of what is and is not measured in that state so reports can be read honestly.
Reconciliation and reporting
A standing comparison of store orders with analytics and each ad platform by channel and storefront, followed by a weekly view built around traffic, conversion rate, average order value and purchase frequency.
What goes wrong
On BigCommerce, specifically
- Adding a tag through Script Manager while the same tag already sits in the theme
- Letting scripts from a previous project keep loading because nobody knows what they do
- Reporting several storefronts as one total when each has its own currency and shipping promise
- Comparing platform reported orders with analytics sessions and treating the difference as a bug
- Leaving refunds out of every dashboard and reconciling with finance by hand each month
Why do BigCommerce reports and analytics disagree?
They measure different things. The platform counts orders it recorded. Analytics counts events fired in browsers that may block scripts or refuse consent. The gap is expected. Use the store record for revenue questions and analytics for behavior and channel direction, and state the usual gap so nobody rediscovers it monthly.
How should tags be organized on BigCommerce?
One tag manager container where possible, loaded through Script Manager with a page scope, and everything else routed through it. That gives one place to see what runs, one place to control consent, and far fewer duplicate conversion events than adding each vendor separately.
Does BigCommerce support server side tracking?
Yes, through order webhooks and the platform APIs feeding a server container. Because checkout is on your domain the browser side is already comparatively reliable, so server side work here is mostly about resilience, refund accuracy and consistent data across ad platforms.
How do you report on multiple BigCommerce storefronts?
Keep the channel dimension from the order data and mirror it in analytics, then decide on one currency of record for any combined view. Reporting them together without that structure hides which storefront is growing and which is quietly carrying the average.
What should a BigCommerce store review every week?
Sessions and conversion rate by template group, revenue and average order value by channel and storefront, filter and search usage on category pages, and the reconciliation between orders and tracked purchases. Anything beyond that is usually a monthly question rather than a weekly one.
More on BigCommerce
Grow on BigCommerce.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.