Tracking on-site campaigns with Google Analytics: The pros and cons of In-Page Analytics

Your homepage is usually your most important landing page. But it is not an easy task to find out how the page’s teasers or “on-site” or “internal campaigns” are performing, especially for content-heavy websites. In the first part of this series on how to track on-site campaigns, we will look at some general issues and then show you 5 pros and 9 cons for Google Analytics’ “In-Page Analytics”.

The teasers change once a week, so every week there’s the question: How well did each teaser perform?

If it were teaser links in an email campaign, the solution would be easy: Just tag all the links with your campaign parameters, and make sure your email service provider offers click tracking.

Why shouldn’t I use regular campaign tags?

Some people also use these normal campaign tags (utm_source etc.) in their on-site campaigns. That is not recommended because you lose the original source of the visitor as soon as she clicks on an on-site campaign link: The original source gets overridden by the parameters of that link.

Paid solutions: Mouse Movement and Click Heat Maps

So what is the solution? You can of course resort to full-scale click-tracking tools like CrazyEgg or PicNet Mouse Eye Tracking (both are paid solutions, PicNet offers a free trial on some pages). Be aware though that this means putting a lot more Javascript on your page which often needs IT buy-in (often hard to get), can impact the page loading time, and you have to use yet another tool. I also think it’s a little obtrusive to track each and every click and mouse movement of your visitor even if they are not (easily) individually identifiable.

Analyzing teaser performance with Google Analytics

You’re not lost if you just want to stick to Google Analytics. In my opinion, there are several proven methods to analyze on-site teaser performance:

1. In-Page Analytics (a.k.a. “Website Overlay”)
2. Event Tracking or Virtual Pageviews (actually two methods, but they work similarly)
3. URL parameters that specify the referring link (like http:\\www.mydomain.com/article?ref=home)

All have their pros and cons. To spoil the show, I use In-Page Analytics for some purposes and Event Tracking for others. I used URL parameters for a while, but almost entirely stopped doing so because it makes reporting a lot more complex and causes other issues. But depending on your goals and your resources, all three solutions may be viable options for you.

In this series on how to track on-site campaigns, we’ll look at all three methods in detail. This first post will focus on In-Page Analytics. See my next post for the advantages and fallacies of Event Tracking and Virtual Pageviews.

In-Page Analytics Pros:

1. Visual context. The best thing about In-Page Analytics. There is no easier way to compare teaser performance than by showing the actual page and displaying bubbles with numbers next to each link. In-Page Analytics allows you to click from page to page, see the “clicks” and click rates for every link (ok, for most links, more on that below) on each and every page, and you can hover over each link to see how it relates to your goals (=percent of visits that followed this link also converted for goal x). See more on how it works in general in the official Google Analytics Blog.
   
2. You can apply filters and advanced segments and visually analyze how visitors from Google behaved in comparison to visitors from your latest newsletter or compare visitors according to their screen resolution.
   
3. You don’t have to set up anything, it works right away for each and every page. Another huge plus. No additional Javascript, no concept for an Event Tracking hierarchy nor for additional URL parameters.
   
4. You have all the other page-related metrics right next to it (Bounce Rate, Time on Page etc.).
   
5. The visitor doesn’t have to click to get from page A to page B to show up in In-Page Analytics. He may also open page B through his context menu by right-clicking on the link and then choose “Open in new tab”. This is a deficit of Event Tracking as we are going to see in part 2 of this series.
   
6. No additional work for your editors or IT. You don’t have to add Javascript click events to teaser links or URL parameters that specify the referrer.
   

In-Page Analytics Cons:

1.  No history. You can only analyze the current form of your page. You cannot get the clicks on a link that is no longer on the page. If you forget to do your In-Page Analytics before putting new teasers on the page, there’s no way to get that data back.
   
2. Not useful if you have often-changing links (like banner or teaser rotations) or personalized pages (different links for different visitors). You can only analyze the clicks for the page the way you are currently seeing it in Google Analytics’ In-Page Analytics interface.
   
3. No distinction between different links to the same page. If there is a link on top of the page to page B and another one on the bottom, In-Page Analytics will display the same click rate for each. You can work around that by adding parameters to the URLs, but that has its own issues, most notably SEO because you are creating multiple URLs for one page. If you do so, you should have a well-thought-through concept with canonical URLs, special profile filters to exclude those parameters for certain reports and so on (more on that in the third part of this series).
   
4. No data for outbound links.If you have a lot of links going to other websites, In-Page Analytics will not do the job. This is because it does not really track the “clicks” on a link. It looks at what I call the “visit protocol” (also referred to as the ”clickstream” data). You can think of the visit protocol as something that protocols every Pageview like this (it doesn’t do it exactly this way, but it’s easier to imagine):
   
   • Visit ID: 123 | Page viewed: Homepage | Timestamp: 11:35 am | Pageview Count for current Visit: 1
     
   • Visit ID: 123 | Page viewed  Article A | Timestamp: 11:38 am | Pageview Count for current Visit: 2
     
   • Visit ID: 123 | Page viewed: Article B | Timestamp: 11:40 am | Pageview Count for current Visit: 3
     
   Using the visit ID as the common denominator, Google Analytics “stitches” its In-Page Analytics data together.
   To find out in which order the pages were viewed, GA “concludes backwards”, meaning that it can tell you about the previous page only if it has the current Pageview logged. So if the previous page for Article A was the homepage, it concludes that the visitor must have clicked on a link on the homepage to Article A.
   If it finds such a link on the homepage, it will display the data for it in In-Page Analytics. “Concluding backwards” of course is impossible when your visitor clicks on an outbound link that makes him leave your website.
   
5. No data for links to subdomains: In-Page Analytics by default also does not display “click” data when your visitor is leaving for a subdomain, even if you are tracking that subdomain with the same Google Analytics profile. That is probably not a very common case, but a big issue for my homepage (we have lots of links going to our community which is on a subdomain).
   
6. Clickstream data doesn’t really represent the clickstream: The underlying assumption of most clickstream data is: If Article B was viewed after Article A, then this visitor must have clicked on a link on Article A leading to Article B.
   But that might not be the case because he may have just opened both A and B via personal bookmarks. Or, while being on the homepage, he may have clicked on the link to Article A and then on the link to Article B (also on the homepage). Depending on how the web analytics tool infers the previous page (see above), it may end up telling you that Article A was the page that led the visitor to Article B (even though there might not even be a link from A to B). If you have a lot of links on your homepage, many users may behave this way: They first open the links that look good to them in new tabs, and then proceed to reading them.
   This of course is a general problem with clickstream data. When explaining this for the first time to people, they are often shocked at how “inaccurate” the data is. But as you all know, it is the tendencies that count, not the exact numbers (see Avinash Kaushik’s epic post on “Accuracy versus Precision“ (Jim Novo originally took this concept to Web Analytics)).
   
7. Data between In-Page Analytics and Navigation Summary doesn’t match: Looking at In-Page Analytics data, it tells me that, out of the 40,352 Pageviews of my homepage last week, 25% (8,015) went on to view the page “STIPENDIUM”, so they must have clicked on this link there:
   But if I look at the navigation summary for my homepage, I get a click rate of roughly 36% for the link to “STIPENDIUM”. My interpretation: The navigation summary, unlike In-Page Analytics, also shows next pages that were on subdomains; but shouldn’t that even lower the percentage of each “click” since there are more links to be clicked? Not necessarily, because In-Page Analytics also counts clicks if the current page is the same as the previous one (like when you click on “refresh”, which happens a lot on our homepage). The navigation summary only shows next pages if they were different from your current page.
   
   So the bases for calculation of In-Page Analytics click rates and Navigation Summary click rates are very different, even though they display the same number of Pageviews as their basis – very misleading! Both reports are ok most of the time if you want to get the tendencies but you should never put both reports side by side unless you really want to confuse someone.
   
8. No possibility to export or save the data. Since you can’t view historical data, the only way to save the current In-Page Analytics data is by taking a screenshot. You can’t export the data and send it to someone as a PDF or an Excel file to use it for further analysis (given the complexity and mass of data, this is understandable though).
   
9. It often crashes (ok, it’s still “beta”). As visual and user-friendly as it is, In-Page Analytics has some usability issues. Since there is a ton of data to load for each page, In-Page Analytics often needs a long time to load and often crashes and requires reloading the page. There are other minor issues like the fact that sometimes you cannot follow links because the bubbles pop up directly over it.
   

Conclusion

Now, just because there are 9 cons and just 5 pros doesn’t mean that the cons outweigh the pros. So this post should not be seen as a recommendation to refrain from In-Page Analytics.

In-Page Analytics is definitely awesome when your on-site campaigns are mostly static (content doesn’t change within the time frame you’re analyzing), if you don’t have too many outbound links or links to subdomains, and if you are in no need to save the data for historical analyses (before and after). With In-Page Analytics, you are getting a report that, in its basic form, can easily be grasped by anyone and offers great filtering and segmenting methods – without the need to put any extra code on your page.