At Blue Mango Interactive, we work with different tag management vendors. All of them have their own version of the data layer. This post is about using the differences between them to your advantage. We’ll look at the page type standard from Qubit’s universal variable data layer and apply it to Google’s data layer for GTM.

What are page types?##

Page types group pages in categories based on their functional role. The page types instantly tell you where a user is on your website. As a standard, Qubit uses the following list:

  • home: for the homepage;
  • content: for regular content page, e.g. a blog or about us page;
  • category: pages that list products;
  • product: product detail pages;
  • basket: the shopping basket of your page;
  • checkout: the steps between the shopping basket and a transaction;
  • confirmation: the transaction page; and
  • search: a search results page.

These are the eight page types Qubit lists in their universal variable documentation. We’ve added Account ourselves because some or our clients’ websites have an account environment:

  • account: the pages where the users manage their accounts, look at order status, etc. The account pages normally require the user to be logged in.

Okay nice, but how do they help?##

If you implement a lot of tags, the triggers for tags will vary from easy to complex. Page types take the complexity out of some your triggers. We’ll take category pages as an example.

Without page types

If I have to place a tag on all category pages, I normally check the pages of the client’s website to find the best possible trigger. Normally, I look for a pattern in the URL structure. Unfortunately, they normally don’t have category written in there. They do tend to have a certain pattern, but it’s hard to capture it.

Let’s take a fictional fashion store as an example. The category page structure will probably follow the following format:

  • /category
  • /category/subcategory

Looking at the actual URLs, the category and subcategory are replaced by actual category names:

  • /shoes
  • /shoes/sneakers
  • /shoes/boots
  • /shoes/…
  • /jackets
  • /jackets/long
  • /jackets/short
  • /jackets/…

It’s possible to capture these URL variations with a regex like ^\/[a-z]*\/[a-z]*$, but you could end up including other content pages that match the regex as well, for example /blog/our-company-at-the-amsterdam-fashion-week. To rule these out, you’d have to know all possible category labels.

With page types

If you’d have page types, all you have to do is check if the page type equals category. Besides triggers, page types also allow you to add extra information about pages in Google Analytics. I’ll talk about setting this up later.

Transforming the Qubit page type standard to a Google Tag Manager standard##

For the implementation of the page types, we’ll start with Qubit’s documentation on their data layer, the universal variable (or uv for short).

window.universal_variable = {
    page: {
      type: ''
    }
  }
  

Note that the variable is nested. The uv doesn’t contain a pagetype variable, but a page variable with type nested inside. This allows you to add more page information within the page variable. Read the Qubit documentation for more ideas for page variables. At GEEK, we use it to store page author and article size information.

Technically, you’d be able to implement Qubit’s uv and use it in GTM by setting up a custom JavaScript variable. But since we’re talking about a GTM implementation, we’ll transform it into a dataLayer variable:

window.dataLayer = [{
    page: {
      type: ''
    }
  }];
  

I advise you to implement this part of the data layer in the <head>, so it’s available before loading the GTM container in the <body>. If you want to push it to the dataLayer at a later stage, add it like this:

window.dataLayer.push({
    page: {
      type: ''
    }
  });
  

Setting up the GTM variable##

With page types available in the dataLayer, you’re ready to set up the variable in GTM. This will be a dataLayer variable:

GTM page type variable
Add a dataLayer variable for page types to start using them in GTM

With the variable added, you’re ready to start using the variable in several ways:

Option 1: Triggers###

Set up a page type trigger. This allows you to fire tags on specific page types. You could use this to send data to Google Analytics for specific page types, or load feedback or assistance tools more effectively to better guide users through the customer journey:

GTM pagetype trigger
Add a page type trigger to load tags on specific page types

Option 2: Custom dimensions###

You can also setup page types as custom dimension. I’ll give you two examples:

Track page types for each pageview

This is a basic one. Add a custom dimension to each pageview on your site. You’ll be able to filter your page reports on the different pagetypes, helping you understand how different types of pages are performing. The setup contains two steps:

  • 1: Set a custom dimension in Google Analytics with a hit scope, to make sure a new value is added for every pageview.
  • 2: Add the dimension to your pageview tag.

1: Set the custom dimension

GTM pagetype custom dimension
Create a hit scope custom dimension in Google Analytics to add page types to each pageview

2: Add the custom dimension to the pageview tag
GTM pagetype custom dimension in GTM
Add the custom dimension to your GTM pageview tag to add page type data to each pageview

Track landing page types

This one is a bit more complex. We normally use landing pages to see how users with specific page entries act on our website. With landing page types, we’ll be able to group these landing page based on their functions. This way we can see how well category landing pages perform compared to a product page entry. Keep in mind that this is only useful for the page types home, content, category and product. The other page types only occur in the later stages of the buying cycle and won’t be a landing page because of it.

The setup contains four steps:

  • 1: Set a custom dimension in Google Analytics with a session scope, to set the landing page type for the session of the user.
  • 2: Create an event tag to send the landing page type custom dimension to Google Analytics.
  • 3: Create a referral hostname variable to use in the trigger for the event.
  • 4: Add a landing page trigger to the event so it will only fire on the first pageview of a user on your website.

1: Set a custom dimension with session scope
GTM landing page type custom dimension in GA
Add the custom dimension to your GTM pageview tag to add page type data to each pageview.

2: Create an event tag to send the landing page type custom dimension to Google Analytics
GTM landing page type custom dimension in GTM
Add the custom dimension to your GTM pageview tag to add page type data to each pageview

3: Create a referral hostname variable to use in the trigger for the event
GTM referral hostname variable
Add a HTTP Referrer hostname variable to your GTM container.

4: Add a landing page trigger to trigger the event on the first pageview
GTM landing page trigger
Add a trigger to the event tag that only fires the tag on the first pageview on your site. On your website, you’ll need to change it to match your own hostname.

These are two options that show you how you could use page types to your advantage as custom dimensions.

Keep looking around##

What I wanted to show with this post is that when you see something interesting for tool a, and you’re using tool b, you’re able to apply the learnings from tool a on tool b. So don’t think ‘I don’t have that tool, so I’ll skip that post’, and do think ‘that looks interesting, let’s see how I can apply this to the products I’m using’.

Leave a Reply