Tag Archives: Google Tag Manager

Prospects vs Customers

Understanding your Website Visitors: Prospects vs Customers

A key metric for most websites is their conversion rate. It is a measure of how well their website is performing but, as it is an average, it can mask serious issues. People who already know you and your website (as they are existing customers) are much more likely to purchase during a single visit than people just discovering your website for the first time. But the data you use is for both groups combined.

L3 Analytics has developed an approach that identifies these two visitor segments (potentially with more granularity), allowing you to understand the behaviour of each. This is recorded in a custom dimension (which could be an Adobe eVar or similar in other tools) that records the type of visitor. Based on experiences with our clients, this can be used to expose some interesting behaviour. A website conversion rate might be 3.5% but only 0.4% for prospects, giving a very different picture on performance and your internal priorities.

How this Works

It is actually more difficult than it first seems to capture a Visitor Type. The most important lesson is that the Visitor Type MUST be set at the start of the session. This allows us to calculate the conversion rates for prospects vs customers. Otherwise only customers could place an order (as prospects become customers after doing so). But, on their next visit to the website, we need to know they are then a customer.

The exception is if the visitor logs in (having registered in a previous session) during the course of the session. After logging in, we know definitely what their Visitor Type was at the start of the session and the value should be updated to reflect this. It does mean this value needs to be passed through from internal systems.

Finally, we want to know if people are customers whether they are logged in or not. As a Visitor Type is not personally identifiable, we feel comfortable recording this after a visitor logs out.

The solution to all this is to use two cookies. One cookie is a short term cookie (equivalent to session-based) recording the value as at the start of the session (or after login). The other is a cookie with an expiration date in the distant future that records the actual Visitor Type as at that point in time. The short term cookie is the one recorded in your analytics tool.

How this Works in Practice

Creating the Cookies

The logic for defining the cookies for the simple use case where there are two Visitor Types only – prospects and customers – is as follows:

On every page load

  • If short cookie exists
    • Read current value
    • Write current value back out with 30 min expiration date
  • If short cookie doesn’t exist
    • If logged in
      • Identify visitor type (“prospect” or “customer”)
        • Set short cookie to visitor type with expiration of 30 min
        • Set long cookie to visitor type with expiration of 2 years
    • If not logged in
      • If long cookie exists
        • Set short cookie to value of long cookie with expiration of 30 min
      • Otherwise
        • Set short cookie to “prospect” with expiration of 30 min
        • Set long cookie to “prospect” with expiration of 2 years

On Login (not on registration)

  • Identify visitor type (“prospect” or “customer”)
    • Set short cookie to visitor type with expiration of 30 min
    • Set long cookie to visitor type with expiration of 2 years

On Purchase

  • If long cookie set to “prospect”
    • Set long cookie to “customer” with expiration of 2 years

Note the cookie needs to be set as “path global” so it can be read across the entire website. They should be set as first party cookies.

Capturing Visitor Type using Google Tag Manager

The following logic can be used with any Tag Management System, but the examples provided are for GTM.  The first step is to create a variable for each of the two cookies. These are very straightforward, simply grabbing the value from the two first party cookies.

session cookie variable

Then another variable needs to be created to record the Visitor Type to be used within the analytics tag. (The JavaScript required for this was provided by someone else, potentially Simo. If I remembered for sure, I would give due credit for this, apologies for not doing so.) The key reason for using this approach instead of just using the value within the short cookie is that, based on experience, the cookies have not always been created before the page tag fires and therefore we need to have a fall back option.

code for visitor type

The final step is to use this latest GTM variable within your GA tags to populate a Custom Dimension. Don’t forget to define this Custom Dimension within your Google Analytics configuration as well (or other tools). As the value for this custom dimension can change from session to session, the scope should be set at session level.

The Caveats for Visitor Type data

The first caveat is that this data will not be, and could never be, 100% accurate. For visitors who are not logged in, it is just not possible to know definitely whether they are an existing customer or a prospect.

The accuracy will improve over time as customers return and can be identified as such even if not logged in. However, this does not work if they delete their cookie or use a different device.

These is also a skew towards customers for purchases. To explain that, imagine two unidentified visitors entering the website, although both are actually customers. As such, they are identified as “prospect”. They both do some research while not logged in. One then exits the website while the other decides to purchase the products they found. During the checkout process, this visitor logs in and is identified as a “customer” with their behaviour during the entire session recorded as for a customer.

The results will show a 0% conversion rate for prospects and a 100% conversion rate for customers. Reality is a 50% conversion rate for customers. Again, nothing can be done here except being aware of this skew in the data.

Extending the List of Visitor Types

This really depends on your business and how you will use the information. For some businesses, there is a stage in between prospect and customer of “registered” (visitors who are in your email database but have not yet purchased). You could split prospects by New & Returning. Or better, by some sorts of segment like New, Aware, Research, Interested based on session scoring. For customers, there are so many segments or personas that could be applied, taking this information directly from the back end database e.g. loyal customers, discount shoppers, inactive customers, family shopper, etc.

Using the Visitor Type Information

With the tracking in place, it is then just a matter of analysing the data. If using Google Analytics, you can create a segment for each Visitor Type (so you can apply to all reports), create a Custom Report with Visitor Type as the first dimension (comparing performance side by side for selected metrics) or apply as a secondary dimension to many reports (for ad hoc analysis).

As noted at the start of this blog post, the obvious metric to look at is Conversion Rate. Beyond that, all the engagement metrics should demonstrate clear differences in behaviour. There are likely differences in the traffic sources used by prospects and customers (discovering website vs already being aware of it), the entry points into the website and the content being viewed.

An interesting one is looking at marketing costs and seeing just how much is spent on existing customers. This will allow a more accurate Cost of Acquisition to be calculated, taking into account only new customers, and only the marketing spend for prospects.

So, have I convinced you of the value of this piece of information? I find it provides the clearest and most valuable segmentation into performance, especially when it comes to driving actions. Of course, while full details have been provided on how to set up Visitor Type tracking, we would be happy to help out any companies who would like our assistance in doing so – please contact us on enquiries@l3analytics.com or +44 (0)20 8004 0835.

Lunametrics-code-sample.jpg

An alternative approach to GTM event tracking

Google Tag Manager feels like it has been around forever and we are now at the stage where I (& many other consultants) will refuse to do a Google Analytics implementation without it (or an equivalent TMS).  But it is still very new, features are evolving and best practices are still being invented.  With that in mind, I wanted to share the approach we use here at L3 Analytics for tracking events in Google Analytics.

I have to say first that we don’t have the developer background or skill-set of many other GTM experts – Phil, Carmen, Doug & of course Simo to name just a few.  As a result, I feel our approach has evolved differently, although we may now use similar ideas.

We aim to create minimal if any custom code within Google Tag Manager.  Instead we insist on our clients creating a Data Layer (on page load and for all visitor interactions) and using that to populate all the GA tracking via GTM.  There are exceptions and I will cover all that another time along with the reasons for this approach. But I want to focus here on event tracking with the information triggered by pushes to the data layer, not via the auto event tracking features in GTM.

The Current Approach

The current approach appears to be to use a naming convention for the variables pushed to the data layer of event, eventAction, eventLabel & eventValue.  Examples below can be found from Phil’s Guide to GTM and from one of the many great blog posts from LunaMetrics.

Code sample via Phil Pearce
Code sample via Lunametrics

 

The benefit of this approach is that you then only need one set of macros and a single tag for all your event tracking in Google Tag Manager.  Life is easy, job is done and even better, no work is required within GTM for new event tracking – just use the same naming convention.

Event category macro
Event Action macro

 

Event tag in GTM

However I don’t like this approach, it doesn’t feel right.  What is the point of a tag management tool if it doesn’t do anything except transfer information through to the analytics tool?  You can get the same result by adjusting the code slightly and sending the data directly to GA.

Then what if you want to change anything?  You need to change the code on the website.  This is fine for GTM users with a developer background but not so much for me.  It means all the logic is defined within the website tracking and I want to get away from relying on developers to get business logic right.

Event Tracking in GTM, the L3 Analytics way

So I have taken a different approach.  I wanted to still have a minimal amount of work to add new event tracking but for all the logic to be defined within GTM.  All I wanted from the developers who created the code & the data layer was information about the visitor interaction that occurred.

My approach is to simply record in the data layer all the information about the visitor interaction that occurred.  Obviously the name of the interaction is required but after that, it depends on what the interaction was.  The name alone may tell me everything I need to know or there might be two, three or ten more items of information to be sent through as well.  Great – send them through, I can decide if I want to use them or not.  And how.  And where.

The format of the data layer push is

dataLayer.push({
‘event’: ‘visitor interaction’,
‘interactionName’: ‘<name of visitor interaction>’,
‘<variableName1>’: ‘<variable value 1>’,
‘<variableNameN>’: ‘<variable value N>’
});

To see that in practice, here are examples of what the push to the data layer would look like for five different visitor interactions.

Click on homepage widget

dataLayer.push({
‘event’: ‘visitor interaction’,
‘interactionName’: ‘homepage widget’,
‘hpWidgetType’: ‘<widget type>’,
‘hpWidgetName’: ‘<widget name>’
});

Apply a filter on a product list page

dataLayer.push({
‘event’: ‘visitor interaction’,
‘interactionName’: ‘product page filter’,
‘filterType’: ‘<type of filter>’,
‘filterValue’: ‘<value of filter>’,
‘numFiltersApplied’: ‘<number of filters previously applied>’
});

Track completion of a form field

dataLayer.push({
‘event’: ‘visitor interaction’,
‘interactionName’: ‘form field tracking’,
‘fieldFormName’: ‘<name of form>’,
‘fieldFieldName’: ‘<name of field completed>’
});

Submission of a form

dataLayer.push({
‘event’: ‘visitor interaction’,
‘interactionName’: ‘form submission’,
‘submitFormName’: ‘<name of form>’
});

 

Scrolling to the bottom of a content page

dataLayer.push({
‘event’: ‘visitor interaction’,
‘interactionName’: ‘content read scroll’
});

That is a few examples, you will see why in a minute.  First task though is to create a macro for each and every variable you are now recording.  This is more work than for the commonly used approach, I admit that.  Takes about 30 seconds per variable though so not much more work.

Homepage widget name macro
Interaction name macro

 

Now comes the really clever part.  You use Macro Lookup Tables to define all your event tracking logic.  Easier to show you than to explain, look at the macros below defining the event category, action and label for my five examples.  The logic is based on the interaction name variable and the values used can be hard coded or use another item of information that was pushed to the data layer with that visitor interaction.

Event Category lookup table macro

Event action lookup table macro Event label lookup table macro

If there is no Event Label (or Event Value) for a particular visitor interaction, that visitor interaction is not included within the lookup table.

Now, guess what your event tracking tag looks like?  Is this at all familiar?  In case you hadn’t guessed, the rule will be {{event}} equals “visitor interaction”.

Event tag in GTM

So, besides an easy setup, let’s see what the other key benefit of this approach is.  Imagine you want to adjust the event tracking on form submissions so the event category field records “form submission” and the event action field records the name of the form (no event label field required).  With the normal approach, you either need to create a new tag just for this event or have the code changed.  With this approach, it takes less than a minute to adjust the necessary macro look up tables.

The analyst has control over all of the event tracking logic.  It still uses a minimal number of tags and rules, just with a lot more (very simple) macros and three or four lookup tables.  It is a very scalable solution and simple enough for non analysts to learn & be able to modify.  And beyond all of that, it feels like a very elegant solution, using a TMS as it is meant to be used…

What do you think?

L3 Analytics is recruiting.  Please contact us if you want to be part of a team coming up with these sorts of ideas.

white-board.jpg

Google Tag Manager for Beginners – MeasureCamp #3

Last Saturday, MeasureCamp came back with a third edition. I really enjoyed meeting other folks passionate about Digital Analytics. People were eager to share their knowledge with fun and we had loads of amazing sessions:

I performed one about Google Tag Manager in the morning. The presentation was for beginners but there were people from a wide range of backgrounds in the room: digital analysts, consultants, TMS vendors, CRO experts… It was a bit intimidating but we had great questions and discussions in the end.

There were three parts in this presentation. I began with an introduction on Tag Managements Systems. Then, I showed how to implement a basic GTM Container. To finish, I explained why a data layer can help to enhance an implementation.  I used local website for the demo but you can find most of the content in the slideshow right below:

 

Please feel free to ask any questions if you need more information about this presentation.

charles-21.png

Tracking clicks within iframes with Google Analytics and jQuery

A few days ago, I needed to implement Google Analytics click events within iframes. I was aware that “iframe tracking” often rhymes with “pain in the backside” but actually a few solutions do exist. One of my best finds was this great post from Doug Hall (Conversion Works):

It explains clearly why tracking iframe contents can be challenging. Social media buttons are a good example because most of them are pushed from a 3rd party domain. Two solutions are provided at the end:

  1. Using social sharing plugins like shareThis
  2. Using custom jQuery scripts like Goldon’s iframeTracker plugin

I tried the second one and I thought it could be interesting to share how to play around with this jQuery script using Google Tag Manager and Universal Analytics.

As a reminder, all credit from this post can be attributed to Doug Hall and Goldon – I have just applied here their recommendation.

The problem with tracking iframe contents

Let’s imagine I wanted to trigger Google Analytics events when visitors click on the following social media buttons:

(for information this is not a plugin, all buttons have manually been implemented, I’ve just used the standard source provided by each social media platform)


My first thought would be: “easy-peasy, a bit of jQuery within Google Tag Manager and it should work!”:

%MINIFYHTML2d29229611cb8f4edfc9d704651564df7%

In reality, it’s a bit more intricate. If we try clicking on the above buttons and look at the result with a HTTP Header reader like HttpFox or Charles, we will notice that it works fine for Pinterest and LinkedIn but it doesn’t for the other ones (which are embedded through iframes):

All right, click tracking doesn’t work on the first three buttons because of lovely iframes but are we giving up? I’d rather “be more dog” like the last O2 TV ad and jump to grab the stick by trying other solutions like Goldon’s jQuery Plugin.

Using the jQuery Plugin iframeTracker

Instructions and technical details for this plugin can be found on GitHub. Basically, we just need to follow two steps to track clicks within iframes with Google Tag Manager and Universal Analytics:

1- Adding a first tag to enable the plugin

We create a first tag containing the source of the file jquery.iframetracker.js between <script></script> and we select a rule to fire this script only on pages containing the iframes we want to track:

2- Adding a second tag to enable the tracking

Then, to track clicks, we need to deploy another script with a jQuery selector calling the plugin. Here is the structure to use (more options are available on GitHub):

%MINIFYHTML2d29229611cb8f4edfc9d704651564df8%

Let’s try to apply this on the previous example. You’ll find just below the same exact buttons, the only change is that I have added the class “iframetrack” on Twitter, Facebook and Google+ to select iframes I wanted to track more easily:


Here is for information the second tag I have set up within my Google Tag Manager container to enable the tracking:

%MINIFYHTML2d29229611cb8f4edfc9d704651564df11%

If we now try to click on the below buttons and look at the information sent to Google Analytics, we will notice that this time all 5 social buttons are tracked:

Conclusion

It’s great to see that there are ways to track clicks within iframes. This solution might not be 100% perfect, I haven’t yet tried this plugin on many browsers but it looks to work fine on Firefox and Chrome. It implies using jQuery but it can be helpful to track clicks on elements embedded through iframes such as social buttons, video players, ads, etc.

Now your turn, what do you think about this plugin? Have you already tried it? Would you recommend other solutions to track interactions within iframes?