Misbehaviors in Google Analytics

Often professionals working with Google Analytics tend to forget the basics of implementation. Not that they are bad at this – but most of the time they don’t think at all of problems that can happen during the website development, developers gone wild… and they tackle problem at the end – when their service is called upon.

Lets try for beginning, to set things up from the start – before professionals take over and do their magic. Data of website owners/companies should be OK. First step in setting things right is proper implementation of tracking code.

Working with programmers and development teams, it came to my knowledge that most of the time – tracking code implementation is just a line in their checklist. No real thinking about what has to be there, which code to use etc… But this line item happen all the time and developer habits die hard. Team or programmers modulize implementation and their only concern is to place tracking ID. No mention of changes in tracking code or methods for collecting data.

At this moment in time (end of February 2014) we have 2 possible ways – Classic and Universal. Stated in Developers part of Google Universal Analytics Upgrade Center in Phase 3 Universal Analytics will be Out of Beta and it will  consist of all beautiful stuff we have in Classic Analytics (remarketing and support for display advertising (demographics is already implemented)).

However, nothing is stoping you or any other website owner to have this data already. Most of “old” websites use some sort of implemented GA (for Google Analytics), either as Sync or Async version, with or without Display Advertising support (so called dc.js implementation) or just plain Universal Analytics code (analytics.js).

But why this blog post?

Developers do their job and move on. Implementation of GA is no simple task and so many things can go wrong. We have sevelar point of failure and we will cover it below. In process of implementation there are several things

  1. creation of property (either Universal or Classic)
  2. adjustments to code – extras (optional)
  3. placement of final code on template pages at the right place
  4. verification of how things were implemented and do they work

Point 4 is solvable with Google Tag Assistant – nice little piece of extension for Chrome. It can detect various implementation ways, all problems and can suggest solution. When verification exist, Point 3 is easy to change if there is any problem. Which moves us to Point 1 (and 2) which is origin of problem.

How and what do you want to track?

Choosing Analytics property

Choosing Analytics property

Using Universal is a clear win as this is clear path of Google Analytics toward better understanding of traffic and analysis available for all. But until Phase 3 of Universal Analytics we can not expect to have remarketing (essential for great AdWords campaigns), demographics and interests (however we started noticing this data in Universal some time ago).

Anyway, all Classic properties created now or in past will be migrated with all data. Until then, one of the clear paths we like to do is to have 2 properties per website in order to have complete view on visitors and their actions and habits. Back to code that has to be implemented. Whichever type of analytics you choose, have in mind that developers must implement it properly. How does it look like?

Different codes for different properties

Different codes for different properties

Each code must be implemented in its basic form properly and at the right place. Take a look at difference between Classic and Classic with Display Advertising enabled – just one line of code, that makes great difference if you have Google AdWords campaigns and you analyze data and are in desperate need of demographics.

What is wrong than?

In our experience – 5 out of 10 clients we saw in the past month have Universal Analytics activated on property level but actual code on site is Classic. This is one problem.

We’ve seen also usage of Universal code with Classic property. It seems that someone jumped into Universal wagon without changing property type or upgrading. Anyhow, these things can be seen if you compare how you defined property and code implemented on site.

Also, we see wrong position of either Analytics code on web page. In order to verify that everything is OK there must be clear oversight of all parts from creation of property, implementation and checking if it is placed properly. We strongly encourage clients if they are at classic analytics (ga.js) implementation to move to async code (and check current status) and to add display advertising option  (dc.js) in order to understand their audience (and have great advertising).

In the future this property will migrate to Universal and there will be no harm d0ne. If clients have Universal Analytics we let them be, but advise to add additional code in order to take advantage of good remarketing (Classic code with Advertising support – dc.js implementation). And it is simple as that.

Control and understand – that we do not live in perfect world. Understand that developers with low priority tasks just put code where it should be without consulting with specialist. Accept the fact that there is so much data within Google Analytics that can explain a lot of business issues and help them solve.

But first of all – do you know was the implementation done right? We know that misbehaviors exist and that we have to deal with them at the start – not at the end.

— If you are ok with your current setup you should go further.

Ostavi komentar