Tag Archives: Tracking

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.

google-analytics new features

2 Unusual Content Groups

We’ve been spoiled with all Google Analytics (GA) features released this year. At L3, we’re particularly keen on Content Grouping. After playing around with this toy for a while, I’d like to share a small tip about it.

As a reminder, the aim of this feature is to categorise your content. It’s incredibly useful and I recommend everyone to set up their content grouping (see this guide from Justin Cutroni for more information).

It is an unsaid thing but we can also take advantage of this to capture additional information – whether it aims to categorise your content or not. For instance, there are two content groups we find so useful we tend to implement them to all clients: the URL being viewed and the referrer of the current page.

Why should I capture this information?

The first reason is that it’s stupidly easy to set up with a Tag Management system (TMS) as Google Tag Manager (GMT):

content-grouping-using-gtm

Then, it can literately save your hide to identify unknown tracking issues. For instance, if you are smart enough to improve your page naming convention, it can be used to check which URLs are being viewed for each page.

Hence, even if you rename pages, you can still easily access the URL of the page. You just need go to your page report, click on the page to check and apply a secondary dimension:

url-content-grouping

Likewise, you can use the URL Landing Content Group to check which query parameters were on your destination URLs. I particularly like this report because I can quickly spot if there is anything wrong in the campaign tracking.

For this, you can simply go to your landing page report, change the primary dimension and use the search box to filter all pages containing a question mark:landing-url-content-grouping

The referrer content group allows us to see which URLs were viewed before a specific page. For instance, it can be very handy to analyse which URLs lead to a 404 page:

referrer-content-grouping

Why capturing this information as a content group?

People may wonder why I don’t use 1 of the 20 available custom dimensions to capture this information instead…

The key reason is that I find more handy to have this set up as a Content Grouping. For instance, it can be used as a Primary dimension in the ‘All Pages’ and ‘Landing Pages’ reports whereas custom dimensions are only available as a Secondary Dimension:

no-custom-dimension-as-a-primary-dimension

Then, I can use a secondary dimension to check the previous, next or entry URL :

secondary-dimension

(note that I can also use the ‘Navigation Summary’ report as the URL level with this content grouping)

Following that, I prefer using Content Grouping to capture some information available across all pages of a website. For instance, the author name or the product category can only be captured on specific pages – I’d rather use here a custom dimension to avoid seeing ‘(not set)’ in my content group reports.  

In the end, I record most of the page-level information I need as custom dimensions. Hence, the 5 available Content Grouping slots are more than enough for me and I’m happy to add those 2 unusual content groups to make my life easier.

What about you?

What do you think about those two content groups? Would you be willing to give away 2 slots to capture this?

Please feel free to agree/disagree using comments – I would love to know if other analysts have other tips to share regarding Content Grouping.

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.

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!”:

%MINIFYHTML75a2ec1ad8939990d87b4df3e2895ab67%

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):

%MINIFYHTML75a2ec1ad8939990d87b4df3e2895ab68%

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:

%MINIFYHTML75a2ec1ad8939990d87b4df3e2895ab611%

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?

sr51.png

GA Flash Audit – Snow and Rock

This is a Google Analytics Flash Audit performed on the Snow and Rock website.  It evaluates their implementation of Google Analytics and makes some suggestions as to what can be done to improve the usefulness of the data via the configuration or an improved implementation.

Note that L3 Analytics does not have access to the Snow and Rock Google Analytics account so all comments made are based on observed implementation of their website.  It is entirely possible that some of the recommendations are already in place or being achieved through other means.

Basic Details

Company Name: Snow and Rock

Website: www.snowandrock.com

Code on Website

Snow and Rock is using the old synchronous version of Google Analytics (outdated since 2010) on most of the website. The blog has the asynchronous tracking code through Yoast’s WordPress plugin.

They still have the tracking code for the A/B testing tool Google Website Optimizer which has been replaced since June 2012 by Google Analytics Content Experiment.

Snow and Rock has several tracking codes on their website:

  • SLI systems (merchandising)
  • myThings (retargeting)
  • SaleCycle (retargeting)
  • AppNexus (advertising)
  • RightMedia (advertising)
  • Facebook Exchange (advertising)
  • Bazaarvoice (review platform)
  • AddThis (sharing platform)

They don’t use any Tag Management Systems (TMS).

Google Analytics code

Standard code

There were no pages encountered that did not contain Google Analytics code.

The GA account number was consistent across all pages on the main website (UA-3618498-1). The blog and the mobile websites are tracked through different web properties (UA-3618498-4 and UA-3618498-5). This separation makes sense because they are independent websites with different behaviours.  However it does mean top products across the mobile and desktop websites cannot be easily identified.

Internal search pages are hosted on the subdomain search.snowandrock.com. The subdomain tracking code is correctly implemented on those pages but it needs to be added to the main domain.

Virtual page views are used to add search query parameters at the end of page names instead of anchors (/search#w=running shoes becomes /search?w=running). This is the correct approach to allow Google Analytics internal site search reporting to be set up.

All pages in the checkout process including the Basket page use virtual page names.  This greatly improves the usability of all page name related reports in GA around this section of the website.

Additional Variables

No custom variables were encountered during the exploration of the Snow and Rock website.

Events were encountered during the exploration of the website on list pages filters but the information sent to GA is wrong (utmac=UA-XXXXX-X). The tracking code placed in file listing.js contains the asynchronous version of event tracking. Updating GA standard code should fix the issue.

Marketing Campaign Parameters

Snow and Rock has been identified as using a number of marketing channels including Twitter, Facebook, Google+, and email.  None of the Social Media links are tagged with GA campaign parameters that will enable this marketing to be identified within Google Analytics.  Emails are tagged following a strong campaign name convention.

Potential Configuration of Google Analytics

Internal (Site) Search

Snow and Rock is able to set-up Internal Search reporting.  They need to set the parameter “w” as the query parameter within the Profile Settings.

Page Names

To maximise the usefulness of web analytics reporting and analysis, page names should be recognisable as relating to a particular page on the website and follow a hierarchical structure.  If they do not naturally follow a strong naming convention, pages can be renamed as part of the configuration of Google Analytics.  For an ecommerce website, pages are grouped into three sections: ecommerce pages, checkout process (Basket page through to Order Confirmation page) and non-ecommerce pages.

Ecommerce pages

There are some pages in this section which do not follow a strong page naming convention.  Pages that should be renamed in the configuration are:

  • Department pages
    • Apply a profile filter that renames the specific department pages as /department/<department name> e.g.
      • Field A -> ^/all/([a-z0-9-]+)/fcp-category/
      • Output -> /department/$A1

  • Product List pages
    • Apply a profile filter that renames all product list pages as /product-list/<department name>/<sub category name> e.g.
      • Field A -> ^/([a-z0-9-]+)/([a-z0-9-]+)/fcp-category/list
      • Output -> /product-list/$A2/$A1
  • Product Detail pages
    • Apply a profile filter that renames product pages as /product/<department name>/<sub category>/<product name>/<sku code> e.g.
      • Field A -> ^/([a-z0-9-]+)/([a-z0-9-]+)/([a-z0-9-]+)/fcp-product/([0-9]+)
      • Output -> /product/$A3/$A2/$A1/$A4

Checkout Process pages

Pages in this section naturally follow a strong page naming convention with most pages using virtual page views.

Non ecommerce pages

Pages in this section naturally follow a strong page naming convention.  It could be enhanced slightly for many of the standard website pages by using a profile filter that renames some of these pages as /information/<page name> e.g.

  • Field A -> ^/[a-z0-9-]+/content/fcp-content
  • Output -> /information/$A1

Goals

It is recommended that if not already set-up, Goals are created for the following website actions based on the existing implementation and previously suggested configuration:

Macro Conversion Events

  • Place Order
    • One goal includes a funnel for the stages of the ecommerce funnel
    • The same goal but the funnel reflects the pages within the checkout process

Stages of the Ecommerce Funnel

  • View Ecommerce page
    • Any of Department, Product List, Product Details or Search pages
  • View Product List page
  • View Basket Page (as a proxy for create basket which cannot be tracked)

Micro Conversion Events

  • Contact Snow and Rock
    • The thank you page for submitting the contact form
  • Sign up to Newsletter
    • The thank you page for signing up
  • View Gift Voucher page
  • View Store Locator

Recommendations for an Enhanced Implementation

Page Tracking Code

Snow and Rock is currently using the old traditional tracking code. This version of the tracking code still works so they could leave it as is. However, we have noted that they need to enable subdomain tracking on the main website so could use this opportunity to switch to Google Analytics asynchronous code.  If so, their standard page tag should be placed just before the </head> tag and would be:

<script type=”text/javascript”>

var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘ UA-3618498-1’]);
_gaq.push([‘_setDomainName’, ‘snowandrock.com’]);
_gaq.push([‘_trackPageview’]);

(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

Tag Management System

Snow and Rock has several tracking codes for different purposes: analytics, merchandising, display, SEM, retargeting etc.

To manage rules and obtain more flexibility, they could implement a tag management system like Google Tag Manager.

 

Custom Variables

It is recommended that the following custom variables are tracked:

  • Visitor
    • Customer ID
      • set when a purchase is made or when a visitor logs in to the website and is recognised as having previously made a purchase
    • Visitor Type
      • Identifies the visitor as a guest, existing customer or registered user (who hasn’t yet purchased)
  • Page View
    • On the Product Details page
      • Availability
      • On Sale flag
      • Method used to access product details page
    • On the Search Results page
      • Number of search results returned
    • On form validation errors
      • Include name of the form, first field that triggered the error and the error message
    • On 404 Page Not found errors
      • Include URL of the page and referrer to the page

Events

It is recommended that the following actions on the Snow and Rock website are tracked as events:

  • Visitor login
    • Include method of logging in, number of previous orders and their value
  • View Product Info & Care and Delivery & Returns tabs on Product Details pages
  • Clicks on product images on Product Details pages
  • Clicks on internal promotional boxes/links
  • Clicks out to Social Media networks
    • Using Social Events as appropriate
  • Clicks on add to my shopping bag
    • Include category, brand and product names to measure a product level success rate
    • Capture the value of products added to basket to enable Snow & Rock to calculate the value of abandoned baskets

Key Ecommerce Investigations

Analyse the Ecommerce Funnel

Not all stages of the ecommerce funnel can currently be identified and reported on.  The stage which cannot be measured is:

  • Create Basket
    • No measurement is recorded when a product is added to the basket

Create a Merchandising Report

It is not possible to create a Merchandising report for Snow and Rock due to no measurements being captured when visitors add a product to their basket.

Analyse Performance by Entry Point

With the recommended configuration in place for department, product list and product pages, it will be possible to create a report comparing % Entries, Bounce Rate and Conversion Rate for different website entry points and different traffic sources.

Summary

Snow and Rock currently has a basic GA implementation.  The page naming convention don’t follow a hierarchical structure and could be easily improved using Google Analytics profile filters in the configuration.

The biggest issue is they don’t record the number of baskets created.  As a results, they have no visibility of performance through the ecommerce funnel and no method of evaluating performance at a product page level. If they used events on the add-to-cart button, they could then set up merchandising reports.

The subdomain tracking code needs to be updated. They are still using the traditional Google Analytics code and could use this opportunity to switch to asynchronous one.

There is a seriously large level of additional information they could easily capture. For example, there is no visibility on 404 error pages. They could also start tracking the customer ID to perform cohort and multichannel analysis.

Tracking Errors with Web Analytics

I have developed an approach to tracking form validation and 404 page not found errors that I now use with all clients. The insights derived have been used to fix issues with their websites, positively impacting on their bottom line. The instructions below are for Google Analytics but the same approach can be used with any web Analytics tool.

Within GA, this approach requires the use of five page level custom variables. Yes, there are only five custom variable slots available total (soon to be more). But I said five variables, not five slots. Form pages and 404 error pages are two different page types and therefore we can reuse the custom variable slots. In fact, I generally use three slots for all of my page level custom variables.

Validation Errors

The first set of custom variables need to be set on pages where a form validation error has occurred. There are three pieces of information to be captured (so three slots):

  • the name of the form
  • the name of the first field that triggered a validation error
  • the error message for this field

Only the name of the first field that triggers a validation error needs to be captured as it is not realistic to capture everything, the first field will be sufficient.

The naming convention for these validation error custom variables is thus:

GA custom variables for Form Validation errors

The GA code on the page if you fail validation on a payment details page due to the customer entering a card number with spaces (form should be fixed to accept this) is:

_gaq.push([‘_setCustomVar’, 1, ‘form error – form’, ‘payment details’, 3]); _gaq.push([‘_setCustomVar’, 2, ‘form error – field’, ‘card number’, 3]); _gaq.push([‘_setCustomVar’, 3, ‘form error – message’, ‘Invalid card number, spaces not allowed’, 3]); _gaq.push([‘_trackPageview’]);

Your developers will need to add code to capture the form name, field name and error message. Note as well that the maximum length of each custom variable name and value combination is 128 characters so the error message may need to be truncated.

404 Page Not Found Errors

The code for 404 error pages is similar with only two pieces of information to be captured:

  • URL of the page
  • referrer to the page

Note that I recommend using the same page name for all 404 error pages as it makes identifying and understanding the scale and impact of these pages much easier.  A page name can be as simple as /error-page.

The naming convention for these custom variables is:

GA custom variables for 404 Page Not Found errors

The code on a misspelled page for the L3 Analytics Set-up service that is accessed via a YouTube page would be:

_gaq.push([‘_setCustomVar’, 1, ‘404 error – url’, ‘/services/web-analytics-setup/’, 3]); _gaq.push([‘_setCustomVar’, 2, ‘404 error – referrer’, ‘www.youtube.com/watch?v=3Sk7cOqB9Dk’, 3]); _gaq.push([‘_trackPageview’, /error-page]);

Accessing the Insights

So the data is being collected but how does it become actionable? DO NOT use the standard custom variable reports, they are not accurate/useful for page level custom variables. Instead create custom reports, one for each business question you wish to answer.

Each custom report should use the metrics of unique events (this equates to visits) and pageviews. The dimensions should be custom variable value 1, custom variable value 2 and, for the Form Validation Errors report, custom variable value 3. On the 404 Page Not Found Error report, create a second report tab with the two dimensions reversed.

Configuration for a Google Analytics Form Validation Custom Report

The key point is to create a filter for each report. This filter is based on the dimension custom variable key 1 matching “form error – form” or “404 error – URL”.  To make even easier, I have already created these custom report for you, simply copy these URLs to the address bar while in the appropriate Google Analytics account.

Identifying Actions to Take

On the Validation errors report, you will see a list of forms with the number of validation errors triggered for that form. Click on a form and you will see that fields that triggered the errors, again ranked based on number of errors. Finally click on a field name to see what the actual validation errors are. That’s actionable information!!

It is a similar story for the 404 error page report. You can see the top urls or top referrers creating these errors. In either case, you can click through for more information to help you narrow down the cause of the errors. Now go fix the links or set up some redirects.

So what do you think? Can you suggest any other ways this approach can be used? Please share the story in the comments if these reports help you to fix any problems.

GA Flash Audit – Joy

Joy Homepage

This is a Google Analytics Flash Audit performed on the Joy website.  It evaluates their implementation of Google Analytics and makes some suggestions as to what can be done to improve the usefulness of the data via the configuration or an improved implementation.

Joy currently has a basic implementation of Google Analytics although they may be using ClickTracks as their primary web analytics tool.  They will experience issues in understanding performance through a lack of hierarchy in page names (can be improved in the configuration) with a serious issue due to no visibility of visitor behaviour within the checkout process.  The Add to Basket action is also not tracked meaning it is not possible to analyse performance through the full ecommerce funnel or create a Merchandising report.

If you would like a free Flash Audit performed on your website, please contact Peter on 07843617347 or via peteroneill@l3analytics.com.  A copy of the audit can be downloaded at the end of this post.

Basic Details

Company Name: Joy

Website: www.joythestore.com

Visits: 31,000 (Sept 2011)

UK Visits: 24,000 (Sept 2011)

Code on Website

Joy is using the traditional version of Google Analytics.

They also have code for the following web analytics tools on their website:

  • ClickTracks

Joy does not have code for any other tools on their website.

Google Analytics code

Standard Code

The only pages found that do not contain Google Analytics code were within the /blog subdirectory.  However there is a big issue with the Checkout process as all information and navigation between sections occurs on a single page.  Therefore there is no way to tell, based on standard page tags, where visitors encounter issues with this process.

The GA account number was consistent across all pages.

The Joy website does not require any sub domain or cross domain tracking.  However there was code identified that affects cookies:

  • pageTracker._initData();
    • This line of code is not required and can be deleted
    • It should not have any negative impact on tracking in the meantime

No pages viewed contained virtual page names (where the page name is overwritten in the code).

Additional Variables

No custom variables were encountered during the exploration of the Joy website.

No events were encountered during the exploration of the website.

No virtual pages were encountered during the exploration of the website.

Marketing Campaign parameters

Joy has been identified as using a number of marketing channels including Twitter, Facebook and email.  None of the Social Media links are tagged with GA campaign parameters that will enable this marketing to be identified within Google Analytics.  It is unclear if emails are tagged as no email has been received yet through subscribing to the Joy mailing list.

Potential Configuration of Google Analytics

Internal (Site) Search

Joy is able to set-up Internal Search reporting.  They need to specify the search URL parameter as SearchTerm.

Page Names

To maximise the usefulness of web analytics reporting and analysis, page names should be recognisable as relating to a particular page on the website and follow a hierarchical structure.  If they do not naturally follow a strong naming convention, pages can be renamed as part of the configuration of Google Analytics.  For an ecommerce website, pages are grouped into three sections: ecommerce pages, checkout process (Basket page through to Order Confirmation page) and non-ecommerce pages.

Ecommerce pages

There are some pages in this section which do not follow a strong page naming convention.  Pages that should be renamed in the configuration are:

  • Department pages
    • Apply a profile filter that renames the specific department pages as /department/<department name> e.g.
      • Field A -> /c-[0-9]+-(new-in|women|men|etc).aspx
      • Output -> /department/$A1
  • Product List pages
    • Apply a profile filter that renames all product list pages (whether at Category or Sub Category level) as /product-list/<product list name> e.g.
      • Field A -> /c-[0-9]+-([a-z-]+).aspx
      • Output -> /product-list/$A1
  • Product Detail pages
    • Apply a profile filter that renames product pages as /product-details/<product name> e.g.
      • Field A -> /p-[0-9]+-([a-z-0-9]+).aspx
      • Output -> /product-details/$A1

These profile filters would result in usable page names.  However, if Joy wished to have a great page naming convention, they could take advantage of their existing breadcrumb.  This breadcrumb has a strong page naming convention using a nice hierarchical structure.  Virtual page names could be dynamically generated based on the breadcrumb for each page.

Joy Ecommerce Page Naming Convention

Checkout Process pages

The pages in Checkout Process are not tracked in Google Analytics as all visitor interactions occur within a single page.

Non ecommerce pages

Pages in this section naturally follow a strong page naming convention.  It could be enhanced slightly for many of the standard website pages by using a profile filter that renames some of these pages as /website/<page name> e.g.

  • Field A -> /t-([a-z]+).aspx
  • Output -> /website/$A1

Goals

It is recommended that if not already set-up, Goals are created for the following website actions based on the existing implementation and previously suggested configuration:

Macro Conversion Events

  • Place Order
    • With a funnel for the stages of the ecommerce funnel

Micro Conversion Events

  • Contact Joy
    • The thank you page for submitting the contact form
  • Sign up to Newsletter
    • The thank you page for signing up
  • View Gift Voucher page
  • View Store Locator

Stages of the Ecommerce Funnel

  • View Ecommerce page
    • Any of Department, Product List, Product Details or Search pages
  • View Product List page
  • View Basket Page (as a proxy for create basket which cannot be tracked)
  • Commence Checkout

Joy Product Details page

Recommendations for an Enhanced Implementation

Customisation of Cookies

Joy has no need to add code to customise cookies.  Instead the _initData() line should be removed.  Ideally they would switch to Google Analytics asynchronous code at the same time.  If so, their standard page tag should be placed just before the </head> tag and would be:

    <script type="text/javascript">
      var _gaq = _gaq || [];
      _gaq.push(['_setAccount', 'UA-7354804-1']);
      _gaq.push(['_trackPageview']);
      _gaq.push(['_trackPageLoadTime']);
      (function() {
        var ga = document.createElement('script'); ga.type =
        'text/javascript'; ga.async = true;
        ga.src = ('https:' == document.location.protocol ? 'https://ssl' :
        'http://www') + '.google-analytics.com/ga.js';
        var s = document.getElementsByTagName('script')[0];
        s.parentNode.insertBefore(ga, s);
      })();
    </script>

Custom Variables

It is recommended that the following custom variables are tracked:

  • Visitor
    • Customer
      • set when a purchase is made or when a visitor logs in to the website and is recognised as having previously made a purchase
  • Page View
    • On the Product Details page
      • Availability
      • On Sale flag
      • Method used to access product details page
        • E.g. Product List page, Search Results, “Try these too”, “Don’t forget”
    • On the Search Results page
      • Number of search results returned
    • On Blog posts
      • Age of article e.g. this week, this month, 6 months, this year, older

Events

It is recommended that the following actions on the Joy website are tracked as events:

  • Visitor login
    • Include method of logging in, number of previous orders and their value
  • View Product Info & Care and Delivery & Returns tabs on Product Details pages
  • Clicks on product images on Product Details pages
  • Clicks on internal promotional boxes/links on the Homepage
  • Clicks out to Social Media networks
    • Using Social Events as appropriate

Virtual Page Views

It is recommended that the following actions on the Joy website are tracked as virtual page views:

Add to Basket

When a visitor currently adds a product to basket, there is nothing to indicate that a product has been added to the basket.  A virtual page name should be generated to indicate that an Add to Basket action has occurred.  The page name would be for this visitor action would be:

  • /add_to_basket/<product name>

Checkout Process pages

Joy Checkout Process

As mentioned, the sections within the Checkout Process are not tracked within GA.  Instead there is only a single page view of /checkout1.aspx?checkout=true.  It is likely there is a new page view for the order confirmation page but as an order was not completed, this cannot be verified.  The solution is to generate a virtual page view for each section of the checkout process that the visitor views.  This measurement would be triggered as each section of the checkout process is exposed.  The naming convention should be

  • /checkout/<section name>

Key Ecommerce Investigations

Analyse the Ecommerce Funnel

Not all stages of the ecommerce funnel can currently be identified and reported on.  The stage which cannot be measured is:

  • Create Basket
    • No measurement is recorded when a product is added to the basket

Analyse the Checkout Process

As previously stated, it is not possible to analyse the checkout process as no measurements are triggered as the visitor progresses through the process.

Create a Merchandising Report

It is not possible to create a Merchandising report for Joy due to no measurements being captured when visitors add a product to their basket.

Analyse Performance by Entry Point

With the recommended configuration in place for department, product list and product pages, it will be possible to create a report comparing % Entries, Bounce Rate and Conversion Rate for different website entry points and different traffic sources.

Download Guide to Google Analytics Flash Audit

Download Joy Flash Audit

Google Analytics Page Level Custom Variables

Hand holding colour cards

Google Analytics custom variables have been around for nearly two years now and while I find myself including them in implementations, I have not reviewed the results in detail.  But opportunities have arisen over the past few months to perform more detailed GA implementations and to dig into the data for custom variables.  This has led to some interesting discoveries, primarily around Page Level CVs.

To cover off the basics first, page CVs have a large variety of uses.  Some can be general, (e.g. page type, page depth, site section) while others are specific to the type of the page such as:

  • article page – author, category
  • product page – brand, availability, price level
  • search results – number of search results

The Google Analytics code for custom variables uses two parameters as settings for the variable and two parameters providing it with a name and value.  These are:

  • Index – the location the data is stored in, can be 1 to 5
  • Name – the name of the custom variable
  • Value – the value of the custom variable
  • Scope – 3 for page level, 2 for visit level, 1 for visitors (defaults to page level if blank)

But enough about that, if you want to know more about the actual code, check out the Google Analytics documentation.  And for details on how to implement and what the different settings mean and the basic uses, there are excellent posts from LunaMetrics (parts I to III) and Justin Cutroni.  I want to talk about what I found interesting.

Length of Custom Variable Names & Values

A limiting factor with custom variables currently is that the combined length of their name and value cannot exceed 64 bytes.  Hopefully Google will ease up on this restriction at some stage but it does mean you need to be careful with your naming convention.  It is a lot of characters but easy to go beyond, particularly if you use an article name or a sub directory structure.  This could be the reason for your custom variables not appearing in your reports.

Using Custom Variables with Events

Another factor that is reported in all the documentation and blog posts but doesn’t appear focused on is that page level custom variables are actually measurement level, not page level.  This means they can also be associated with events, not just pages.  You could even trigger multiple measurements on a single page (whether using events or virtual page names) and attach a set of custom variables to each one.

This allows you to get more descriptive around actions on the website as you are not limited to the three label parameters in an event.  For example, you might be using an event to capture the details of an outbound link.  This can be extended through using one page CVs to identify which section of the page the link was clicked from and a second to identify the position within that page section.

As with so much around the implementation of Google Analytics, the possibilities are limited by your creativity.  I haven’t tested it but it wouldn’t surprise me if you could even include custom variables within ecommerce transaction measurements, allowing you more fields to describe customer/purchase behaviour.

More than Five Custom Variables

It is a well know fact that there is a limit of five custom variables in Google Analytics.  Apparently there is an unsupported workaround in the code but I haven’t experimented with this.  But this limit only applies to the number of custom variables that are in use at any one time.  Now visitor & visit CVs apply to all pages on your website as do any page CVs which are implemented on all pages.

But say you are only using two of those (a visitor CV for registered users and a page CV for page type), then you have three slots to be reused for other page level CVs across the rest of the site.  This is not three custom variables but three slots for custom variables.  And as you are using custom variables for different purposes on different page types, you are not limited to a total of five custom variables.  You can have three CVs on your blog pages and a different set of three CVs on your product detail pages.  Events can even use four CVs as the page type CV won’t apply.  So remember that the limit is five custom variables at any one time, not five custom variables in total.

Picture of coloured balloons

Including Custom Variables in Segmented Profiles

Segmented profiles can be set up to include only visits that meet certain criteria or to include only data within visits that meets criteria.  For the segmented profiles that target pages within visits, events and custom variables need to meet the criteria as well.  But, the page name they use to compare against the criteria is the default page name (from the URL), not a virtual page name or a page name renamed by prior profile filters.

Do you need to use a Visitor/Visit CV?

In line with the observation earlier that you have more than five custom variables available if using non global page level custom variables, it make sense to avoid using visitor or visit CVs where possible.  So have a think about what you are trying to accomplish.  Are you creating a visit based CV for visitors who log in so that you can get the proportion who do and understand their behaviour?  If so, can’t you just use an event or page level custom variable and then create an advanced segment around this – it will give you the same result.

Interpreting Metrics for Page Level CVs

The real fun for me started when I started to really look at the numbers for page CVs.  The Visits number just didn’t look right, seemed much too low for many of the variables.  I was using Next Analytics to extract data into Excel so reached out to Mike Sullivan for his thoughts and he pointed me in the right direction.

A Visit for page custom variable is only counted for the first value recorded – that is the first value per name, not per slot.  It is not visits in which that custom variable value was viewed. If the custom variable is on all pages within a website, then Visits should equal Entrances.  But basically it is a useless metric and frustrating as it appears within the default custom variable report (which appears designed for visitor/visit custom variables, particularly as described as a Demographics report in the new UI).

There is an alternative.  Page views are a type of event and therefore the Total Events and Unique Events metrics can be used with page level CVs.  Unique Events equates to Visits, the metric I was after, while Total Events is the total count of occurrences of that value, similar to Pageviews.  So if using a page CV in a segment, Visits are fine.  But if using it as a dimension or a filter, then use Unique Events instead.

Two more points.  The metric Entrances only appears to be recorded if the custom variable is on the landing page for the visit.  If the custom variable value is recorded for the first time on the second page, it will be a Visit for that value (and an Event) but not an Entrance.

And everything I have said here also applies to Pages.  It is why Unique Page Views is used in content reports instead of Visits and why you can use Unique Events and Total Events metrics with Pages as a dimension.  Just keep that in mind when using page names in a filter when creating custom reports, dashboard widgets or extracting data via the API.

Sample set-up for a custom report for page level custom variables

Using Page CVs in Custom Reports

Which leads into the next question, how do you access this data.  The answer is to set up custom reports for all your page level custom variables and use these instead of the standard reports.   You can set filters for only a particular custom variable name so can customise the report to show the exact data you want.  Another option is to set up widgets within GA Dashboards to report on similar information.

Request to Google

So it appears that page level custom variables behave quite differently to visitor/visit level custom variables.  The output is not Demographic reports but Content reports.  In a way, it is similar to the difference between s.Props and Evars in Omniture SiteCatalyst, one is a traffic/content metric while the other is persistent with Goals/Conversion Events as the key metrics.

But I digress.  My request to Google is to create a new set of custom reports and include them in the Content section of the new GA menu structure.  Leave all visitor/visit custom variables in the existing Demographic reports section (you know which variables they are) but move any page level custom variables to this new set of reports.  It will make sense to users and reduce the risk of misinterpreting data.  Do people agree/disagree with this proposal?

GA Flash Audit – New England Lifestyle

The New England Lifestyle homepage

This is a Google Analytics Flash Audit performed on the New England Lifestyle website.  It evaluates their implementation of Google Analytics and makes some suggestions as to what can be done to improve the usefulness of the data via the configuration or an improved implementation.

New England Lifestyle appears to have a basic implementation of Google Analytics.  The resultant page names are reasonable in most cases but could definitely be improved to aid in analysis and understanding of performance.  A 3rd party shopping cart is being used which requires some additional work for accurate ecommerce tracking.

The blog is currently not tracked in the main GA account – this should be included using subdomain tracking.  The action for Adding to Cart is also not tracked at present, this is an essential step which needs to be captured in some way.  With a bit of work, New England Lifestyle could have an excellent set-up of Google Analytics allowing them to understand and improve their business performance.

Note that this Flash Audit was performed following a discussion between the website owner and L3 Analytics regarding a comment made on another L3 Analytics post.  If you would like a free Flash Audit performed on your website, please contact Peter on 07843617347 or via peteroneill@l3analytics.com.  A copy of the audit can be downloaded at the end of this post.

Basic Details

Company Name: New England Lifestyle

Website: www.newenglandlifestyle.com

Visits: 17,000 (June 2011)

UK Visits: N/A (June 2011)

Code on Website

New England Lifestyle is using the traditional version of Google Analytics.

They also have code for the Yahoo! Web Analytics web analytics tool on their website.

New England Lifestyle does not have code for any non web analytics tools on their website.

Google Analytics code

Standard Code

There were no pages encountered that did not contain Google Analytics code.

The GA account number wasn’t consistent across all pages.  New England Lifestyle is using one GA account for the main website (UA-1145732-1) and another for the Blog section of the website (UA-1145732-2).  I recommend using the same account number across the entire website with subdomain tracking in place.  This will allow New England Lifestyle to understand if their blog posts are encouraging traffic and purchases on their main website.

They are currently using the line pageTracker._initData(); which is unnecessary.  It can potentially cause problems with subdomain tracking and so should be removed.  Details of the new page tag are provided later in this document.

No pages viewed contained virtual page names (where the page name is overwritten in the code).

Shopping Cart

New England Lifestyle uses a 3rd party Shopping Cart to process online orders.  As such, they cannot track visitor behaviour on these offsite pages.  I did not complete the transaction so cannot comment on the tracking for purchases.  But New England Lifestyle needs to ensure that the visitor returns to a thank you page on their website with transaction details passed through, enabling e-commerce code to be populated.  These visitors need to retain their original traffic source information, typically through adding the utm_nooverride=1 URL query parameter.

Additional Variables

No custom variables were encountered during the exploration of the New England Lifestyle website.

No events were encountered during the exploration of the website.

No virtual pages were encountered during the exploration of the website.

Marketing Campaign parameters

New England Lifestyle has been identified as using a couple of marketing channels.  Some of these are tagged with GA campaign parameters that will enable this marketing to be identified within Google Analytics.  The marketing channels that have been checked are:

  • Paid Search on Google – is auto-tagged with GA campaign parameters
  • RSS – is not tagged with GA campaign parameters (should be automatically set up via Feedburner)
  • Newsletter – a copy has not yet been received so not possible to say if tagged or not as yet (update to this Flash Audit will be made when this information is available)

Potential Configuration of Google Analytics

Internal (Site) Search

New England Lifestyle is partially able to set-up Internal Search reporting.  They need to specify the search URL parameter as search.  However I never managed to perform a search which generated a list of search results, even using category terms such as “Bedroom”.

When specific product search terms were used such as “Fiori Piccolo Glass Vase”, the website takes the visitor directly through to the product page.  This is good usability but it does mean the internal search is not captured as the resultant URL does not contain the required URL query parameter.

New England Lifestyle should use a virtual page name for when this happens, concatenating the normal page name along with the internal search URL Query Parameter.  The resultant page name would be:

/accessories-and-decoration_fiori-piccolo-glass-vase.htm?search=fiori+piccolo+glass+vase

Page Names

To maximise the usefulness of web analytics reporting and analysis, page names should be recognisable as relating to a particular page on the website and follow a hierarchical structure.  If they do not naturally follow a strong naming convention, pages can be renamed as part of the configuration of Google Analytics.  For an ecommerce website, pages are grouped into three sections: ecommerce pages, checkout process (Basket page through to Order Confirmation page) and non-ecommerce pages.

Ecommerce pages

There are some pages in this section which do not follow a strong page naming convention.  The biggest issues are

  • The page type is not captured or immediately obvious
  • Category and product pages do not contain information on which department they belong to

However, Product pages do contain the name of the category they belong to.

This solution could be resolved through the use of Virtual Page Names, Profile Filters or a combination of the two.  One option is to simply include the department name for Category and Product pages, using the breadcrumb to provide this detail.

Example of the New England Lifestyle breadcrumb

The page name for this page would become

/living-room-furniture/tables_new-england-coffee-table.htm’]);

If this solution was used (most likely if only limited resources are available for creating virtual page names), profile filters could then be applied to rename Department, Category and Product pages as follows:

  • Department Pages
    • Custom Filter -> Advanced
    • Field A -> ^/(living-room-furniture|dining-furniture|bedroom-furniture|mirrors|home-office|home-accessories).htm$
    • Output -> /dept/$A1
  • Category Pages
    • Custom Filter -> Advanced
    • Field A -> URI Request -> ^/(living-room-furniture|dining-furniture|bedroom-furniture|mirrors|home-office|home-accessories)/([a-z-]+).htm$
    • Output -> URI Request -> /category/$A1/$A2
  • Product pages
    • Custom Filter -> Advanced
    • Field A -> URI Request -> ^/( living-room-furniture|dining-furniture|bedroom-furniture|mirrors|home-office|home-accessories)/( a-z-]+)_(.*).htm$
    • Output -> URI Request -> /product/$A1/$A2/$A3

This will lead to a nice clean and hierarchical page naming convention for the ecommerce pages on the website.

Checkout Process pages

There are only two pages in this section that can be viewed without completing the transaction.  The basket page is fine as it is but the Your Details page could be renamed using a profile filter from /order.htm to /checkout/your_details.

Non ecommerce pages

Most of the non ecommerce pages on the New England Lifestyle website are named accordingly to the information on the page with no need for a hierarchy.  However, the Blog pages need to be adjusted when tracking is extended to include this site section.  This can easily be done using a Profile Filter:

  • Custom Filter -> Advanced
  • Field A -> Hostname -> blog.newenglandlifestyle.com
  • Field B -> URI Request -> (.*)
  • Output -> URI Request -> /blog/$B1

Given the page naming convention for blog posts, a second profile filter (ensure it is located below the previous one in the filter order) should be used to identify all blog posts.  This filter would read as:

  • Custom Filter -> Advanced
  • Field A -> URI Request -> ^/blog/[0-9]+/(.*)/
  • Output -> URI Request -> /blog/post/$A1

Another exception lies with the thank you pages for Contact Us and Email a Friend.  Both are usable as they are but don’t follow the best practice structure.  These pages should be renamed as follows:

  • Custom Filter -> Advanced
  • Field A -> URI Request -> /([a-z-]+)_thank-you.htm
  • Output -> URI Request -> /$A1/thank-you.htm

Goals

It is recommended that if not already set-up, Goals are created for the following website actions based on the existing implementation and previously suggested configuration:

  • Place Order
    • With a funnel for the stages of the ecommerce funnel
  • Place Order
    • With a funnel for the stages of the checkout process commencing with the Basket page
  • The thank you page for the Contact Us form
  • The thank you page for emailing product details to a friend
  • For each stage of the ecommerce funnel where possible

Recommendations for an Enhanced Implementation

Customisation of Cookies

As previously described, New England Lifestyle needs to customise their standard page tag to allow the Blog subdomain to be tracked.  Given this update, they should switch to GA Asynchronous code at the same time.  The new page tag will look like:

<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-1145732-1']);
  _gaq.push(['_setDomainName', 'newenglandlifestyle.com']);
  _gaq.push(['_trackPageview']);
  _gaq.push(['_trackPageLoadTime']);
  (function() {
     ...
  })();
</script>

This code should be located at the top of the page just above the </head> line.  It also includes the new GA tag for Page Load times.  This will automatically populate the Page Load reports within Google Analytics for a small sample of pages loaded.

A New England Lifestyle product page

Custom Variables

It is recommended that the following custom variables are tracked:

  • Visitor
    • Customer – this is set when a purchase is made or when a visitor logs in to the website and is recognised as having previously made a purchase
  • Visit
    • Basket created – this is set either when a basket is created or if a visitor returns to the website where a persistent basket is still existing
  • Page View
    • On the Product Details page
      • Discount
      • Range e.g. Manhattan, Newport
    • On the Search Results page
      • Number of search results returned
    • On Blog posts
      • Age of article e.g. this week, this month, 6 months, this year, older

Events

It is recommended that the following actions on the New England Lifestyle website are tracked as events:

  • Ask a question – on product pages
  • Click on email address – as a Mailto link
  • Clicking to view images
  • Clicking to commence checkout – from any page outside of the Basket

Virtual Page Views

It is recommended that the following actions on the New England Lifestyle website are tracked as virtual page views:

Add to Basket

When a visitor currently adds a product to basket, it generates a new page view of the Product page with nothing to indicate that a product has been added to the basket.  This new page that is generated should have a virtual page name used to indicate that it was due to an Add to Basket action.  The page name (assuming other recommendations have been actioned) would be:

/add_to_basket/department/category/product

Payment Details Page

As previously mentioned, the order is completed on a 3rd party shopping cart.  Even though the Payment Details page cannot be tagged, code should be added to the Continue to Payment button on the Your Details page to reflect that the visitor has proceeded to a new page within the checkout process.

So that this page can be used within a Google Analytics funnel, a virtual page view should be used and not an event.  The page name would be /checkout/payment_details.  There should be a check in place first so the virtual page view is only triggered if the visitor is going to pass validation on this form (How did you hear about us? should not be a required field).

Key Ecommerce Investigations

Analyse the Ecommerce Funnel

All stages of the ecommerce funnel can be identified and reported on recommendations are implemented.  Without this, it will not be possible to accurately analyse the performance of the New England Lifestyle website based on the ecommerce funnel.  Details for each stage of the funnel are:

  • Ecommerce Visit
    • Can be identified based on the first element in the page name only if page names are modified
  • Get to Product
    • Can be identified based on the first element in the page name only if page names are modified
  • Create Basket
    • Requires additional tracking on the site to capture this action
  • Commence Checkout
    • Can be tracked using /order.htm (or /checkout/your_details)

Analyse the Checkout Process

Not all pages of the checkout process can be identified and reported on due to the use of a 3rd party shopping cart.  The use of a vertical page view to represent the 3rd Party Shopping Cart will be the best possible step to allow an approximate analysis of this process.

Create a Merchandising Report

It is not possible to create a Merchandising report for New England Lifestyle as not all the required elements are being tracked.  The elements that are not being tracked are:

  • Product Detail pages – are currently not uniquely identified as product pages
  • Add to Basket by Product – no tracking in place to record this

The recommended changes to the set-up of Google Analytics would allow New England Lifestyle to create this report.

Analyse Performance by Entry Point

With the recommended tracking in place for department, category and product pages, it will be possible to create a report comparing % Entries, Bounce Rate and Conversion Rate for different website entry points and different traffic sources.

Download Guide to Google Analytics Flash Audit

Download New England Lifestyle Flash Audit

Tracking Repeat Customers in Google Analytics

Justin Cutroni has just written an excellent post on five Google Analytics custom variables that ecommerce companies should definitely use.  Actually the principles behind these variables apply to all web analytics tools, just the type of variable used may differ.  He recommends using custom variables to track:

  • coupon and promotional codes
  • payment method
  • shipping method
  • repeat customers
  • purchase history

I did chip in with a comment on some other custom variables that would be useful for ecommerce website (my suggestions are all page level variables):

  • On the Product Details page
    • Availability (proportion of sizes/colours available)
    • Brand
    • Price Range (group into buckets so low, medium, high)
    • Sale (flag if at a reduced price)
  • On the Search Results page
    • Number of search results

While I like the principle behind what Justin is trying to capture with his last two custom variables, I am not sure this is the best method.  He suggests using visitor custom variables to first capture if someone is a repeat purchaser and then, via some clever server side configuration, to capture the number of purchases made.

The value of this is that these customers are likely to behave differently as they have used the website previously.  The problem with this approach is that it relies on the customer using the same device to make all their purchases and to never delete their cookies.  Both of which are unlikely over time.

Instead I suggest taking advantage of the fact that repeat customers will have set an account up and therefore will login to the website.  Not all customers will have but irregular customers who either always checkout as a guest or create new logins are not the customer segment we are interested in identifying.

Rather than a custom variable, I recommend triggering an event when a visitor either logs in or arrives on the website with a persistent login.  You can still create segments for visits in which this event was triggered providing you with the information required.  The value for the action field would be the method used to login, whether it was creating an account, logging in or having a persistent login on the website.

The event can also be used to capture information related to the purchase history as Justin recommends.  As websites can return the name of the person when they login, I assume they can return the number of orders these people have placed and even the total value of these orders.  Therefore use the event label to identify the number of orders placed by the visitor (previous to this visit), using ‘none’ if they have never made a purchase.  And populate the value label with the total revenue generated by the customer (rounded to the nearest dollar, pound, etc).

The only flaw with this approach is you can’t identify customers who return to the website but that don’t login.  But as per the original description, we are interested in the identifying and splitting out the behaviour of customers who make a purchase having previously purchased.

This is a new idea, can someone who tries it out let me and everyone else know if it works.  And thanks to Justin for the inspiration.