How to properly setup Google Analytics (and GA4) using Google Tag Manager on a Squarespace Ajax SPA site

How to properly setup Google Analytics (and GA4) using Google Tag Manager on a Squarespace Ajax SPA site

So this is basic enough that I am surprised it hasn’t been covered yet. Essentially, due to some of the Squarespace 7.0 site templates using AJAX, they effectively act like single-page applications (SPAs). While this provides some sleek UI with dynamic content, it also means that full page loads are not happening (which is the point) and therefore scripts on your site are not reloading.

At it’s core then, with SPAs, you’re not going to have scripts like GTM container scripts or GA scripts automatically reload on every page view because there are no “page views”. This is why the built-in tracking for Google Analytics within Squarespace doesn’t work if you have AJAX tracking enabled. Their solution is to turn off AJAX loading in your Squarepace site settings, which is fine, but the reality is you should be using Google Tag Manager to handle Google Analytics and other tags anyways.

So I’m going to cover that.

TLDR;

1. I assume you already know how to insert the Google Tag Manager container script via Squarespace’s settings.

2. Read this article from Analytics Mania covering SPA tracking with GTM. It will help you understand the core principles of what’s happening and, ultimately, would allow you to decide and troubleshoot how you want to create a solution if your Squarespace template isn’t the exact same as the one I am using.

3. Based on the article, you’re going to verify that you’re seeing ‘gtm.historyChange’ events either in the Google Tag Manager Debugger or within the browser console using something like AdSwerve’s dataLayer inspector Chrome Extension.

4. Instead of using the normal ‘Page View’ triggers in Google Tag Manager, you’ll create a trigger using the gtm.historyChange event. You’ll also create dataLayer Variables to grab data from the gtm.historyChange event, in particular when the gtm.historyChangeSource is “pushState”.

5. You’ll then use that trigger and those variables and triggers to use with GA tags, GA4 tags, and whatever else you might want to setup within GTM consistency.

6. For GA4 basic events like page views, for now, all you’ll need to use is the GA4 Configuration Tag in GTM and the normal Page View event trigger. Then in GA4 Admin settings you can enable “Enhanced Measurement” to automatically capture page views and other events.

More Detail

1. You’ll create datalayer variables in GTM to grab the page URL values from the datalayer.push gtm.historyChange event. The first is to get gtm.historyChangeSource: “pushState” which you will use in the trigger and the second is to get gtm.newURL.

2. You’ll use the gtm.newURL variable and have it set the “page” field in your GA Settings Variable.

3. Your GA Pageview tag will then use the GA settings variable and you’ll create a trigger using the gtm.historychange event to fire that tag. In particular, that trigger will look for when gtm.historyChange is “pushState” and not “replaceState”.

4. You’ll duplicate the GA Pageview tag, but adjust the trigger so that this tag only fires on the initial load (initial pageview of the site). This is because gtm.historyChange doesn’t appear in the initial load which means the first GA pageview tag won’t fire until a user browses to another page.

5. Your GTM container should have the following tag structure:

6. After pushing your changes, when you move from one page to another, when using the AdSwerve’s debugger tool, you can see how in the gtm.historyChange event, that when gtm.historyChangeSource: "pushState", the gtm.newUrl represents the page URL for the page you navigated to.

In this example, I went from my home page to '/my-experience’. In the following GA pageview event, since we have the GA Setttings Cookie referencing the gtm.newUrl value, the pageview is sent using that value as highlithed in the “dl:” parameter. I should mention, in this simple example, I haven’t bothered to fix the “dt:” aka the Document Title for the pageview it’s still referencing the old Document Title for the original page I viewed (my home page). I’ll change that later.

7. Create a GA4 Configuration Tag, add your measurement ID, and use the normal page view event trigger in GTM. Additionally, in the GA4 Admin Settings, enable “Enhanced Measurement”.

Adding GA4 to at least track page views is fairly straightforward due to the nature of what GA4 is built on and the browser history events I mentioned previously. If the browser history states, aren’t updating or are undefined, then this simple configuration won’t work.

Additionally, there are a host of other things you can track as part of “Enhanced Measurement” as well as creating more custom GA4 events (read Simo Ahava’s GA4 Event Setup Guide) but for now, this should help get the page_view event into your GA4 property. If you do enable Enhanced Measurement events be sure to QA them and be ready to possibly disable them.

Conclusion

This is a fairly standard setup of how to use GTM with SPAs but specific to some nuances of Sqaurespace’s templates. There are still other ways to clean this up, but this is a good place to get started. There are other things to eventually look into as well, for example, you should double check whether you’re getting the rogue referral issue and implement the fix as recommended by Simo Ahava and on a related note determine whether you’ll need to persist URL and campaign tracking parameters. I didn’t cover the advanced GA4 setup in this example, but this should at least help get the initial data collection rolling.