We’ve seen hundreds if not thousands of Google Analytics properties for BigCommerce stores over the years and we thought we’d document some of the checks we do to ensure clients have GA4 configured correctly.

Simple Check For Duplicate Tracking

The easiest way to identify this is to visit a seldom-visited page and check the page view count – it should be one. We use /sitemap – visit the page, note it’s page title (usually Sitemap), then head to GA4’s real-time report, look at the “Page title and screen name” report and page through the results until you find “Sitemap” – views count should be 1. If more than 1, it’s likely you have duplicate tracking.

Simple way to check for duplicate tracking in GA4

Is Revenue Tracking Correctly?

Click on Reports Snapshot and click the “Total revenue” Tab to view revenue. This figure should (roughly) match the same time period in BigCommerce. If more, it’s likely you have duplicate tracking somewhere, if significantly less (>10%) there may be an issue with tracking and/or you’re using a consent banner which reduces your ability to track all data.

Simple check that revenue is tracking in GA4

Duplicate GA4 Tracking – How to find it

Here’s a pretty exhaustive list of how duplicate tracking can occur in rough order of prevalence based on our experience.

BigCommerce Google Analytics 4 implementation

BigCommerce’s GA4 implementation isn’t as complete or as advanced as Tag Rocket and we also track many important extras such as Core Web Vitals and exceptions such as JavaScript errors and Missing Pages (404’s). All this extra data flows into the Tag Rocket Report – a valuable monitoring and reporting tool. If you’re using Tag Rocket, you’ll want to disable BC’s implementation. Here’s how:

You’ll also need to ensure the following is disabled to avoid issues – it’s located below the Affiliate Conversion Tracking section:

Duplicate Tracking Code

As I’ve written a more detailed article on where legacy code can exist for BigCommerce stores – I’ll simply summarise here:

  • BC Admin->Storefront->Script Manager
  • BC Admin->Storefront->Footer Scripts
  • BC Admin->Settings->Data Solutions
    • Universal Analytics
    • Visual Website Optimizer
    • Affiliate Conversion Tracking
  • Theme Files
  • Google Tag Manager (GTM)

To identify GA4 code, you’re looking for the Google Tag. Basically anything with the string “gtag” is a likely candidate. Be aware that Google Ads also uses the Google Tag – If you’re using Tag Rocket for both GA4 & Google Ads (highly recommended to avoid conflicts), then you can safely remove all other “gtag” code.

  <!-- Google tag (gtag.js) -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'TAG_ID');
  </script>
  gtag('event', 'conversion', {
    'send_to': 'AW-CONVERSION_ID/CONVERSION_LABEL',
    'value': 1.0,
    'currency': 'USD',
    'transaction_id': '12345',
  });

Universal Analytics Link To GA4

The Universal Analytics to Google Analytics 4 migration has caused many issues, some of which cause duplicate tracking. To safeguard against further issues, go to your old Universal Analytics property and disconnect your GA4 property.

Multiple Conversions

For a variety of reasons, events other than the default “purchase” event can be marked as conversions. Unless you have a specifically good reason to mark other events as conversions, don’t – they can cause confusion when looking at the reports. If you plan to disable extra conversions, be mindful that they may be being used in your Google Ads campaigns.

Combined Tags

Because Google Tag is used for both GA4 and Google Ads, Google provides ways to reroute events to both destinations via combining tags. We have concerns about this practice as the event specifications are different for each, so Tag Rocket sends platform-specific events separately. As sources and destinations can be rerouted it can create duplication where both sets of events get sent to both destinations, causing duplicate tracking:

To check if this is an issue for you go to Data Streams->Configure Tag Settings and check that your Google Tag appears like this with a single GA4 measurement ID, going to a single GA4 destination (ignore GT ID’s):

If you have a different configuration I recommend you contact us to assist, it’s a complicated process to fix and done incorrectly can lead to irreparable changes – see Google’s warning below:

Why Isn’t GA4 Tracking Some or All Events?

Here are the main reasons Tag Rocket’s GA4 tracking may not be working correctly for your BigCommerce store:

Consent Banner Present

Consent laws are tightening across the globe, especially in the European Union. We have worked extremely hard to make Tag Rocket compatible with most consent systems and to support Google’s Advanced consent mode to capture maximum data. The reality is however, that if you have a consent system working properly (read this article to check) there will be some customers that will deny consent, reducing your ability to track all users accurately.

Not a Stencil-themed BigCommerce store

Tag Rocket relies heavily on stencil handlebars for page context and data gathering. Headless architectures are at this stage not fully-supported. Partial support can be offered if utilising the stencil themed checkout and order-confirmation pages.

Site Speed Script Interference

There are many legitimate ways to improve site speed, one of which is to delay certain scripts to load the customer-visible page faster. Sometimes these tools are a bit aggressive and interfere with tracking scripts such as Tag Rocket.

The 2 most common script of these we find interfere with tracking are Website Speedy & the PapaThemes Setting shown below:

No Revenue Metrics Access

Sometimes the revenue data is missing when viewing a GA4 property due to the configuration of your permissions. Get an administrator to ensure the “No Revenue Metrics” option wasn’t enabled when setting up your permissions under Admin->Property Access Management->User:

Missing Head/Footer Scripts

There’s a few reasons why Tag Rocket’s scripts may not be loaded on various pages. The best check is to navigate to the following pages and confirm that the head/footer scripts are included with a Right-Click (in a blank space), then “View page source”, then search for “Tag Rocket App Head” & “Tag Rocket App Footer”:

  • Your Home Page
  • The Checkout Page
  • Order Confirmation Page (if possible)

If missing, then one of these reasons is the culprit:

Theme files missing includes

Tag Rocket relies on the 2 script entries that exist in BigCommerce’s Script Manager. Sometimes themes are missing the head/footer includes that add these scripts to the page – check these theme files and ensure that the {{{head.scripts}}} and {{{footer.scripts}}} lines are present:

  • /templates/pages/order-confirmation.html
  • /templates/pages/checkout.html
  • base.html

Custom Order Confirmation Page

Some themes use a custom order confirmation page. If present, this also has to have the footer/head scripts present.

Handlebars Failure

A “quirk” of Script Manager is that if there’s a handlebars failure in one Script Manager script, all subsequent scripts will fail. This is a tricky one to debug but we’ve had some practice at it – if you feel this might be the issue please contact us to assist.

I’ll soon be adding to this page the following further things to check:

  • Form & Site Search Settings
  • Retention Settings
  • Data Collection Settings
  • Consent Settings