Why Analytics Master Builders Need To Think Like Data Architects

One common question in analytics is: “Which is better? Adobe, Webtrends or Google?” (Okay so rarely is Webtrends included in that question these days).

The answer is: “it depends”. This is largely dependent on what you need to measure, alongside other variables. It’s those variables you need to collect to identify what vendor should be selected including internal resource/setup, technical architecture and integration requirements. Performing the task of creating an analytics maturity model is a good way to assist in that creation (We will cover maturity models in more detail at a later date).

All too often organisations skip that process and move from one vendor to another without realising if they spent the time and effort to implement it correctly they would get the answers they need. The same can be said for those organisations who decide to go down the bespoke route and build their own analytics tool, by stepping back from the technical aspects and identifying the business measurement needs alongside the analytics maturity model you can identify which tool best meets your needs. You may find it is the one you already have and that all is lacking is a fresh look at how it is implemented.

We’ll cover vendor selection in more detail in a future post, for now we are assuming that Google Analytics has been selected (A common decision even for enterprise customers these days) and the decision has been made to upgrade to Universal Analytics.

What is Universal Analytics?

Google released their latest product in April 2014; Universal Analytics is the latest version of Google Analytics and comes with a complete re-write of the back-end code that powers their analytics tool. With the new product come some exciting new opportunities including enhanced e-commerce, cross device measurement and custom dimensions/metrics to name a few. Therefore it makes sense when making technical changes to an existing Google Analytics implementation to consider the need to upgrade.

Google Analytics Premium

The decision then is to decide whether we need to purchase the premium version of Google Analytics or not. The decision comes down to two key areas, the first relates to data limits – what traffic does the site get? Secondly what requirement do you have around the legal aspects of your data?

Google Analytics Premium is essentially a support contract, ensuring your agreed SLA’s and data ownership alongside a few extra features. The move from the free version to the premium version does not require any changes to your tracking. Both the legacy and universal version of GA can be part of any GA Premium license.

There are numerous considerations to be had in terms of deciding if you need GA Premium or not, we’ll cover these in more detail in a future post.

Data architecture – Planning the data landscape

Any enterprise analytics implementation requires a heavy level of data planning, at this stage it is akin to database architecture. We as the master builders of these new implementations need to consider how the data will look when marketers and analysts attempt to use this data in the future.

With Universal Analytics came the ability to track custom dimensions and metrics, alongside the newly released calculated metrics. With those new options and the ability to track custom events there is a heavy need for careful planning. Particularly if you are not using premium and only have 20 custom dimensions/metrics to play with.

Consider what segmentation you will require in-line with your measurement strategy. Should you have a non-ecommerce site where the macro-conversion is an online form, within that form consider what fields might be useful to your measurement needs. In the case of a B2B form perhaps you ask the enquirer how many employees they employ or their revenue range. Whilst that information is routinely passed to your CRM system how useful would it be to segment your marketing performance for low versus high revenue companies. This is where your data mapping comes into effect; therefore we may decide to create two new custom dimensions to hold this data.

The focus then should be on clear naming conventions for these new elements, conventions that allow any future analyst to clearly understand what they relate to. Be aware of potential language differences around the business for different KPI’s, what one team understands a certain KPI to be may differ. Thus ensuring a clear and consistent naming convention that has been approved by the necessary stakeholders is recommended.

We also need to be cautious with what we track. Just because we can track something does not mean we necessarily should, there are privacy concerns alongside legal aspects. Google for example does not allow us to track personally identifiable information. Thus tracking an email address or full name would not be allowed. However we can track a customer ID or other unique key that we can use to tie back to our CRM system.

This same customer ID can also be used to implement cross-device tracking, which uses that customer ID to stitch user sessions together across multiple devices and enables new reports to analyse that usage. Finally you could measure the effect of different devices on your customer lifecycle and how they influence each other.

If you are tracking e-commerce into analytics then consider what your product names, SKU’s and transaction IDs should look like. If you don’t have specific product names then it may be possible for you concatenate multiple parts of an order to create a virtual product name or ID. Further considerations include whether these products have variations such as colour, size or duration. Then consider how you intend to track these and which GA data fields you will use, this includes considering custom dimensions potentially alongside the use of GA’s enhanced e-commerce functionality.

Alongside mapping those data elements into GA we also need to consider which micro-conversions and other engagement activities we need to track. This may include areas such as carousels, video playback, on-site search and other areas. This will of course tie back to our measurement framework to ensure there is a cohesive link between strategy and technical measurement.


Good documentation is equally important at this stage, when the questions start coming in whether a particular action is tracked or not or what a particular custom metric means then you want to be confident in your answer.

It will also assist you in the QA process and in relation to extending the analytics or in any future website redevelopment.


When dealing with enterprise analytics implementations resist the temptation to jump straight to adding code. Spend a considerably level of effort planning what data elements you need and how they will map into the analytics platform. Consider how that data architecture will look to the end analyst/marketer.

Once we have the vision planned out and the data architecture fully documented, then we can continue to the development phase.