Note: This post has moved from Leapthree.com to Ayima as part of the 2018 acquisition.
This is an account of a business issue that was raised with me during a training course and a step by step run through of how we used Google Analytics to identify and fix the issue. Unfortunately (but understandably) my client wasn’t comfortable with sharing their confidential data so all details will have to remain slightly vague. My apologies for this but I think you should still get the idea behind this approach.
What is this “Undefined” page?
I was running a web analytics training day with a client recently and I was asked for help with a problem one of the analysts was having. A new page had appeared in their Google Analytics data since the re-launch of a category page under the page name of /<category_name>/undefined. The analyst knew this was not a real page but couldn’t identify where it was coming from or how to fix it.
Step 1 – Find the page
My first task was to identify the page itself. The url wasn’t much help in this so I thought I would have a look at the Page Title of the page. To do this, I created a custom report with dimensions of “Page” and then “Page Title”, while the metrics I selected were pageviews and unique events (equivalent to visits).
With this report created, I applied a filter to identify the /<category_name>/undefined page and clicked through to see what its Page Title was. This displayed that the Page Title in fact 404 Page Not Found. Ahh – this undefined page was a 404 Error. But how were people accessing it?
Step 2 – Identify the method used to access this page
Given the question was where people click through to view a page, the Navigation Summary report was the logical next report. I accessed this by selecting the /<category_name>/undefined page within the Pages report and then switching to Navigation Summary.
In a way it was not a huge surprise to discover that basically the only way visitors access the /<category name>/undefined page is via the new /<category_name> page. This is the page which coincidentally went live on the same day the /<category_name>/undefined page started reporting data. We could immediately look on this page and try to find a broken link but it would be much easier if we could narrow down the range of options first.
Step 3 – Additional insights into the source required
Acting on a hunch, I returned to the pages report. Once again I selected the /<category_name>/undefined page but this time I changed the dimension from “Page” to “Browser”.
The result was great, all but two page views were due to a single browser, Internet Explorer. If we had been searching for this link using any other browser, we would never have found it. The internal analyst I was working with suggested drilling down further into Browser Version which was an excellent idea. I changed the dimension again but this only showed the issue was across all versions of IE.
Step 4 – Can we pinpoint the link that is broken
Aimed with this new intelligence, I returned to the Navigation Summary report, this time with the /<category_name> page selected. I created and applied two segments, one for visits from Internet Explorer and one for visits from the next most popular browser (Chrome). Through this comparison, I was hoping we could discover which page/s visitors could access using Chrome but not using IE.
Most of the next pages viewed had a similar ratio in the number of views comparing between IE and Chrome – IE has just over twice as many views. But there were a certain group of pages, all with the same page naming convention, which had slightly less Next Page views in IE as in Chrome.
This intelligence pinpointed the exact issue. There were some links on the /<category_name> page which were meant to lead to this group of pages that were broken when using any version of Internet Explorer – resulting in a 404 Error instead of the desired page.
Step 5 – Use the Web Analytics intelligence
We opened up Internet Explorer and looked for links to that group of pages. There is a carousel that allowed you to select a product and then click through to details of that product. This link appeared to work, suggesting the issue was elsewhere.
But the internal analyst discovered that if you clicked back through the carousel to a product and then clicked on the link through to that product, it could lead to the 404 Page Not Found Error page with a page name of /<category_name>/undefined. Success!
Step 6 – Fix the problem
The internal analyst took this insight to the developers, having pinpointed the issue using the intelligence from web analytics data and identified the exact cause of the issue. The result – the issue was fixed that very same day.
Now that’s what web analytics is all about…