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
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:
- In-Page Analytics (a.k.a. “Website Overlay”)
- Event Tracking or Virtual Pageviews (actually two methods, but they work similarly)
- 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:
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.
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.
You don’t have to set up anything, it works right
away for each and every page. Another huge plus. No additional
additional URL parameters.
You have all the other page-related metrics right next to it (Bounce Rate, Time on Page etc.).
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.
In-Page Analytics Cons:
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.
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.
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
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
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.
- Visit ID: 123 | Page viewed: Homepage | Timestamp: 11:35 am | Pageview Count for current Visit: 1
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).
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)).
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.
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
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.
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.