Case study: how to implement Google Analytics on a single page app, via Google Tag Manager.
Soon after starting in my role as a customer acquisition manager, I realised the current Google Analytics implementation had some flaws and was not showing reliable data. On top of that, it failed to track cross-domain activity for two websites Walks operated.
What I needed was a new cross-domain implementation and just some time to fix the tracking issues I spotted.
It seemed like an easy task until I found out that both websites were built as single-page apps (SPA).
Therefore, the regular Google Analytics page view tracking wouldn’t work. In fact, in single-page apps, GA can only track one page view per session. Basically, only the landing page can be tracked and no other user’s action can be measured.
I needed a custom implementation via Google Tag Manager.
While researching the topic, I could see that I had several solutions available. The most straightforward and probably most common solution was to use the Google Tag Manager built-in History Change trigger. However, I soon learnt that this solution had some caveats, as the great Julian from MeasureSchool explains at the end of this video.
Therefore, I had to opt for a 100% custom solution which relied on custom data-layer pushes.
Since it was turning out to be a large web-development project, I decided I might as well implement Enhanced Ecommerce data layer as part of the same project.
After pitching the whole project to the management team, I was assigned two front-end developers and a two-month timeline.
The project was successfully delivered within the deadline and proved to have built a solid and, most importantly, scalable online tracking infrastructure.
Step 1: the pageview data layer
The very first step was to push a custom data layer event for every virtual page view. This way, using Google Tag Manager, I could trigger a GA pageview tag on this custom event and essentially track page views accurately. The data layer object contained information about the page URL and title.
All this information could be easily retrieved by dataLayer variables in GTM and used across any vendor tag like Facebook, Criteo, Twitter, etc
Step 2: fix the referrer issue
I noticed that because of the SPA, GA wasn’t retaining the traffic source information across pages. This meant that sessions were broken halfway and new “direct/none” source-medium was assigned. This was obviously an issue as myself and my team couldn’t reliably attribute traffic to the correct source. Also, the number of sessions was highly inflated harming the conversion rate.
In order to fix this, I implemented an extra piece of data layer and some custom script in the GA Settings section in GTM.
Step 3: Enhanced Ecommerce data layer implementation
The project wasn’t meant to apply a quick fix. Rather, it was aimed to implement a new scalable tracking infrastructure that would last in the long term. For this reason, I opted to go for the full Google Tag Manager Enhanced Ecommerce implementation.
This implementation allows you to track product and revenue data and use it for multiple purposes across several different platforms, like Google Analytics, Facebook Ads, Criteo and so on. Once the implementation is done, adding a new vendor tracking becomes an easy and smooth process.
Under my specifications, the developers added eCommerce data layers objects across both websites.
For example, this is the Product Click data-layer push.
Thanks to this project, the full enhanced e-commerce reporting on Google Analytics was unlocked.
I could safely and reliably implement the tracking for third-party ad platforms like Facebook Ads, Criteo, Pinterest Ads and AWIN. Also, thanks to the enhanced e-commerce implementation, I could run dynamic retargeting and feed-based ads.
Also, I and my team were finally able to get an accurate view of the user journey across the takewalks.com and walksofitaly.com.
check my full resume.