How To Track Users in an Embedded Application with Google Tag Manager

Some service providers use embedded applications to easily replicate a complex user journey across multiple websites. Often these user journeys are not tracked. As a result we are unable to optimise conversions for important steps in the user experience. However, with a bit of planning and developer help, it is perfectly possible to track user interactions within ‘.NET’ or other applications.

Why do companies embed applications into a website?

Companies which provide white-labelled websites sometimes use an embedded application. This simplifies the process of replicating their services for different clients. This acts like a single page application (SPA) as the URL does not change. In this case the application is embedded in a web page and calls APIs from another website to deliver content.

Embedding an application within a web page. It creates a number of challenges for tracking user interactions in Google Analytics.

Firstly

• Embedding an application into a web page means that when content is changed within the application the URL shown in the browser does not change. Google Tag Manager (GTM) and Google Analytics rely on URL changes to detect when a new page has been served.

Secondly

• As applications call another website to deliver dynamic content. GTM code on the host website won’t be able to detect user interactions within the application as it’s hosted on separate website. This is similar to an iFrame, but unlike iframes it controls the whole page and can be mobile responsive.

Thirdly

• Because the application delivers dynamic content according to information held about the user or how they respond to specific content. We need the ability to track in-page interactions. This is why it’s important to have unique IDs on page elements to enable tracking of individual fields.

Below is the process to resolve these issues using GTM and Google Analytics.

Three Steps:

• Enable cross-domain tracking
• Integrate GTM into the web application.
• Add virtual page views script to each page in the application.
• Add unique IDs to each element on the pages within the application.
• Test, test, test.

1. Cross-Domain Tracking:

Prior to implementation I decided to configure GTM and GA for cross-domain tracking to avoid problems with double counting that can occur when users go between two domains. It wasn’t clear that it would be required. I don’t see the point of taking the risk and jeopardising the implementation to save a relatively small amount of effort.

Whether it is required will depend upon the nature of the application. You should enable cross-domain tracking just in case. After GTM was implemented, I investigated if the target domain was decorated and found no evidence that it was. This suggests that in my case cross-domain tracking wasn’t required. I wouldn’t have known this before the implementation.

2. Implementing GTM in the embedded application:

I’ve assumed you already use GTM to implement your analytics code. If not, you should migrate to GTM. Otherwise you are limiting your potential to optimise your analytics and the insights they deliver. Migrating to GTM is not difficult. You can often retain your GA base code during the process to ensure you can retain your historical data if required.

The one exception to having both GA base code and GTM working in unison is inside an embedded application. We found a conflict between GA base and GTM within the application meant virtual page view would not fire.

Implementing GTM within an embedded application requires placing the GTM JavaScript on every dynamic page served by the app. The code needs to be put high up in the head tag and a snippet in the body tag.

Go to your GTM container and select the ‘Admin’ tab and then on the right hand-side menu select ‘Install Google Tag Manager’. You will see the code as shown below with instructions on where to place the code. It includes your container ID which starts with ‘GTM-‘. Make sure this is the same as the code on the rest of your website as it should be identical.

Do Not Edit the Code

If you don’t want to begin collecting data until cookie permissions etc are set you can control this from your GTM container. You can either refrain from publishing the container or pause the page view tag until you are ready to send data to GA.

Once the code is live you should open GTM in ‘Preview’ mode and refresh your website to check GTM opens in your browser within the application. What you won’t see are any pageviews for the dynamic pages. When the browser refreshes you should see the page view for the URL that the application sits on. If you have some generic ‘Click’ tags set up you should also see them firing when you interact with the dynamic pages.

3. Virtual Page Views:

Implement virtual page views rather than events because Google Analytics Goals doesn’t allow events for creating funnels. This means you couldn’t use the Funnel Visualisation report in GA if you set up events. You would also miss out on the ability to measure page load speed by using events.

Please read my blog on how to create virtual page views in Google Tag Manager for step-by-step instructions on this process. This involves five steps outlined in the blog post.

These Are;

1. Adding virtual pageview data layer script to each dynamic page.
2. Create new data layer variables for the page title and URL.
3. Edit the GA Settings variable to include virtual page views.
4. Create a custom event trigger.
5. Create a virtual pageview tag.

Example of the Script Used

A developer needs to place this on every dynamic page in the application.

datalayer.push ({

‘event’:’virtualPageView’

‘virtualPageURL’:’/glossary-of-conversion/adaptive-design/’

‘virtualPageTitle’:’Adaptive_Design’

});

You should test that the tag is working by using the ‘Preview’ mode in GTM. Also, check the ‘Realtime’ console in Google Analytics for the environment you are testing it in to check the data is being sent to GA.

4. Add Unique IDs to Elements on the Page:

Having unique IDs on each page element is especially important when tracking dynamic pages where the content changes according to the nature of the user journey. IDs helps you configure tags in GTM to track user behaviour and identify drop off points. This allows you to create variables using ‘Lookup tables’ in GTM which can help you to minimise the number of tags in a container.

In addition, form analytics solutions such as Zuko and Hotjar rely on IDs to identify and track each input field. Ensure you also add IDs to images because these can be used to configure triggers in GTM that fire on the visibility of an individual image. This can be used to for advertising banners, but also for images that might signify the customer has a particular type of account or product.

Create some conventions to ensure some consistency of IDs. For example, use ‘BUT_’ as the prefix for all buttons and ‘LNX_’ for links. This allows you to set rules in GTM to prevent tags firing when a different type of field is clicked. It also helps with setting up Lookup tables in GTM.

Adding unique IDs is good practice in general, but with an embedded application it helps reduce uncertainty about whether all interactions are being tracked.

Summary:

As white labelled websites become more common it is likely embedding applications within websites will become more common. Tracking user interactions in an application embedded in a website is essential to understand behaviour throughout the whole user journey.

Plan the implementation to increase your chances of success. Explain to your team the process required to track users in an embedded application and get their input to make the process run smoothly.

Enable cross-domain tracking as without it you may get double counting together with other data quality issues.

By adding GTM script and virtual pageviews to each page of the website hosting the embedded application you can begin track user interactions throughout the whole web journey. With the addition of unique IDs for page elements this will allow you to configure tags and form analytics to provide detailed tracking within each page of the embedded application.

This means that you can now create complex funnel visualisations in Data Studio to automate user journey reporting. This will show you the pages where the largest drop offs are within the embedded application. It also allows you to identify problematic fields within individual pages of the application. Create separate funnels for each page so that you can visually see the drop off for each field.