Ever since the iPhone 4 came out, I’ve been a bit annoyed with the way mobile (Apple) devices are tracked in Google Analytics. While we get plenty of device information for other brands, Apple has (perhaps unintentionally) made it difficult to detect and track iPhone models. To make a long story short, Apple devices usually only identify themselves as iOS devices without any specific model information. Basically, iPhones introduce themselves to Google Analytics by saying “Hi, I’m an iPhone” instead of “Hello, I’m an iPhone 5”. Which is what we’re going to change with this post. Continue reading
Implementation and auditing of Google Analytics and Google Tag Manager is essential when working with web analytics. After all, what good are reporting and analytics if you can’t trust your data? Usually, when setting up GTM and Analytics on a website, you’ll find yourself checking source code for the correct dataLayer or using real-time reports to see if data comes in. But Chrome Extensions for Google Analytics and Tag Manager makes it much easier.
The thing is, the whole implementation and debugging part is a cumbersome process. So is it possible to optimize that process? Well, yes – say hello to Chrome Extensions. Chrome Extensions are small plugins for the Google Chrome browser. And some of them are specifically for debugging the setup of Google Tag Manager and Google Analytics. So in this post, I’ll introduce you to my list of the most essential and, IMHO, the best extensions for Google Analytics and Google Tag Manager. Continue reading
A client of mine recently asked me to track ‘mouse interaction’ with an iframe that they embed on several pages. By ‘mouse interaction’, the client basically meant that they would like to track whenever users hovered their mouse cursor over the iframe for a certain amount of time. I’ve previously posted that you can track any mouse or keyboard interactions with Google Analytics. As long as they occur within the browser.
Luckily, there’s a widely supported browser event called ‘mouseover‘. The mouseover event fires when a user moves the mouse cursor over a specified element – for instance, an iframe. But it can be used on any visible HTML element on the page. So, by combining this event with a timer, it’s possible to push a dataLayer event to Google Tag Manager. And then use that event to send an event hit Google Analytics.
In the end, we’ll end up tracking Google Analytics events whenever a user hovers his or hers mouse over our specified element. Continue reading
The Time on Page metric is probably one of the most misunderstood metrics in Google Analytics. Google Analytics measures the time on page for each page, but can only do so by measuring the elapsed time between two interactions. The first interaction is the timestamp of the initial pageview, and the second interaction is usually the timestamp for the next pageview (or an event). So for sessions with just one pageview (i.e. bounces) there’s just one timestamp. In those cases, Google Analytics is unable to measure the time on page. As such, for the time spent on a page for bouncing sessions and on exit pages there’s simply no data. (there’s no ‘last’ timestamp on exit pages either). The real time on page is therefore likely higher than what your reports are telling you.
Did you know you can detect and track device orientation changes in Google Analytics? That is, if a mobile or tablet user switches between portrait and landscape mode? Well, of course it’s possible (basically anything that happens inside a browser can be detected and tracked in Google Analytics).
In a previous post, I wrote about how to detect and track the browser’s viewport (which was made almost obsolete by the new native Browser Size dimension). This tells us how users as a whole view our website, and provide valuable information about how to layout our pages. If users on a specific site or page have very large viewports, then we can make use of a lot of screen real estate.
In this post, I’ll take it a step further. Because sometimes, I really need to know if users are literally turning their devices (mobiles or tablets). Perhaps our responsive website has been designed for browsing in landscape mode. But in reality our users might prefer to browse in portrait mode. In any case, we need to know, so we can go tell our designers to optimise the experience for one or the other (or both!). Continue reading