Jul 252014
 
Article Analytics

At the time of writing this post, the new “Universal Analytics” version of the Google Analytics tracking code, based on the analytics.js javascript library, is already out of beta phase, and most webmasters need to get ready to replace, in the pages of the sites managed by them, the old “Classic Analytics” tracking code based on the ga.js library with the new code.

This post presents some considerations that need to be taken into account in performing this migration.

Migration Phases

According to the main page in the Google  “Universal Analytics Upgrade Center“, the migration from Classic to Universal analytics is being done in four consecutive phases. The two first phases have already been completed, and the third phase is now the current phase (July 2014):

  • Phase 1: All properties can upgrade to Universal Analytics.
  • Phase 2: Auto-transfer process begins.
  • Phase 3: Universal Analytics out of beta. (Current Phase)
  • Phase 4: Universal Analytics is the operating standard for Google Analytics.

On the first phase, webmasters could decide to migrate their sites to Universal Analytics, that at that time was still in beta, and was missing some of the functionalities available in the old version.

On the second phase, Google has been migrating the great majority of “Properties” found in analytics accounts. Currently, the migration of most analytics accounts is done, and now the webmasters of sites using those accounts must proceed to replace the old tracking code based on ga.js with the new code based on analytics.js.

Benefits of Universal Analytics vs Classic Analytics

The new functionalities available in Universal Analytics are described in the About Universal Analytics page in the Google support site:

  • With Universal Analytics it is possible to attach a “User ID” to the information that analytics gathers for each pageview, or more generically, for each “Hit” done on the site. With the User ID, it is possible to track jointly accessess done by the same user on different sessions and from different devices.
  • Other than that, with Universal Analytics it is possible to create custom dimensions and metrics for a given web site. This functionality replaces and enhances the functionality previously available with the use of “custom variables”.
  • Universal Analytics also implements enhanced E-commerce reports, to enable a detailed analysis of the performacen of e-commerce sites.

Sample tracking code using ga.js

In the simplest cases, the ga.js tracking code looks like this:

But often the webmaster of a site makes some changes to this base code, to include tracking criteria specific of the site.

For instance:

Compared with the previous example, in this code we can see that:

  • A custom variable named ‘viewport’ has been added by means of a call to “_setCustomVar”.
  • The domain name has been explicitly set as “example.com”, by means of a call to “_setDomainName”. This is useful to track in the same property accesses to subdomains of the main domain.
  • Finally, a call to “_trackPageLoadTime” has been added, to track the average page load time for the site.

Sample tracking code using analytics.js

The default Universal Analytics tracking code that needs to be added to the site’s pages can be retrieved from the Analytics administration interface:

The webmaster will need to customize this code, as happened with the old ga.js tracking code, to add the site-specific tracking requirements.

The most common customizations are commented below:

Tracking across a domain and its subdomains.

Often, a web site is structured as a set of subdomains for instance, www.example.com, london.example.com and new-york.example.com could be all subdomains of the same site. The webmaster might want to treat consecutive accesses done by the same user to different subdomains of “example.com” as part of a single session.

To achieve this using the old ga.js tracking code, the domain name used to set the cookies used by analytics had to be explicitly set to the base domain with a call to “_setDomainName”, preceding the call to “_trackPageView”:

with the new tracking code, we can specify ‘auto’ as the domain name in the call to ‘create’:

Using ‘auto’ the domain name selected to generate the cookies will be the highest possible level, resulting in the same value for the main domain and its subdomains (A detailed explanation can be found in “Automatic Cookie Configuration” in the Google Analytics for Developers website).

Alternatively, the domain name used for generating cookies can be explicitly set as follows:

Cross-domain tracking

In some cases, a site can be structured as several distinct top level domains. For instance, ‘www.example.com’, ‘www.example.co.uk’ and ‘www.example.es’ could be all part of the same site.

If the webmaster decides that it makes sense to jointly track a session that accesses pages from several of these top level domains:

As a first step, the domains must be added to the list of “referral exclusions” in the Analytics admin interface. The page Referral Exclusions in the Google Help Center explains the details of the procedure to carry out this task

Then, the tracking code must be edited to indicate explicitly the domains that will be treated as equivalent:

In this sample code, a third argument in the call to ‘create’ enables the execution of the linker plugin

Next, the call to ‘require’ loads the linker plugin.

Finally, the call to linker:autoLink specifies the domains that will be treat as equivalent (Detailed information can be found on “Cross Domain Auto Linking” in the Google documentation for developers site)

Tracking the page load time

In Universal Analytics, tracking the page load time is done by default, with no need to make a call to “_trackPageLoadTime” as was the case in “Classic” Analytics. By default, tracking of the page load time is done on a sample of one per cent of the pageviews. For sites with low volume of traffic, it might be of interes increasing this percentage to obtain a more significative average.

To set a sample of the total pageviews other than the default 1%, an additional parameter ‘siteSpeedSampleRate’ can be specified in the call to ‘create’. For instance, to set a sample rate of 50%:

Migrating from Custom Variables to Custom Dimensions

In ga.js webmasters had the option to define custom variables. In the sample tracking code shown earlier in this post, we can see that a custom ‘viewport’ variable is definer to track the different screen resolutions of the devices used by visitors of the site.

In analytics.js, the “Custom Variables” feature has been replaced by “Custom Dimensions” and “Custom Metrics”.

Implementing a Custom Dimension is done in two steps: First, in the Analytics admin interface the Custom Dimension/Metric is defined. Second, the tracking code is edited to use the Custom Dimension/Metric.

Creating a Custom Dimension

After entering Analytics, click on Admin, and select the account and property where the Custom Dimension is going to be defined.

In the Property column, click on “Custom Definitions” -> “Custom Dimensions” -> “New Custom Dimension”, and give it a name.

Next, choose a scope level for the new dimension. The possible scope levels are  “Hit”, “Session”, “User”, or “Product”. The three first levels are equivalent to the corresponding scope levels in the definition of a Custom Variable in ga.js. The “Product” level is new in analytics.js

Finally, click on the “Active” checkbox and on the “Create” button to finish creating the custom dimension.

Creating a Custom Metric

The procedure for the creation of a custom metric is very similar to that for the creation of a custom dimension. Additionally, in the case of a custom metric, the type of data that will be gathered needs to be specified as Integer, Integer, Currency or Time.

Setting the value of a Custom Dimension in the tracking code

A Custom Dimension is assigned a value by means of a call to ‘set’. For instance:

In the sample tracking code for ga.js shown earlier in this post, we could see that the assignment of a value to the custom variable ‘viewport’ was done using the following sentences:

To convert this snippet to the new code,  ‘viewport’ will have to be defined first in the analytics admin interface as a custom dimension of session scope. Then, the code can be edited, replacing the call to ‘setCustomVar’ with a call to ‘set’:

References

 Posted by at 10:00 am

 Leave a Reply

(required)

(required)