June Dershewitz on Web Analytics

The Dreaded 404 Not Found: Three Ways to Find Broken Links

Every so often I get a request along the lines of, "Hey web analyst, run me a broken links report." Although simple enough, this task is not without its nuances. Here are 3 tactics you can use to find broken links on your own site when you (inevitably) get asked:

1) Set forth a spider

You may be the resident expert in whatever web analytics tool your company uses, and when someone asks you about broken links they may expect that you'll use your web analytics tool to find broken links for them. However, it's not your only choice! Spiders are worth considering for this task, as well; they'll identify a slightly different set of broken links than you get from your web analytics tool.

Here's how I like to think about the difference: web analytics tools tell you which URLs visitors actually try and fail to view. Spiders tell you which URLs throw errors regardless of whether any visitor clicks the link or not, and regardless of whether the target URL lives on your site or elsewhere on the internet.

Newbie explanation: spiders are software programs that crawl pages on your site and scan for certain things like broken links. If your site employs a lot of JavaScript and forms and Flash and web 2.0 whiz-bang, you'll need to find a spider that can handle the complexity. There are basic free tools (like the W3C Link Checker) and fancy not-so-free tools (like this one from Accenture) and plenty of options in between.  If you haven't done so already, go test-drive a spider.

2) Analyze your logs

Back in the old days, when nearly every web analyst dealt with log files, it was actually quite easy to get a broken link report because it comes standard with log-processing solutions. These days, with so many of us using JavaScript tags alone for data collection, error tracking takes a bit of customization that you must initiate.  

If your web analytics tool uses log files, now is the time to locate your broken link report. If your tool uses JavaScript tags, it's worth checking to see if broken link reporting has been set up. If, for whatever reason, you don't have broken link reporting yet, there's still hope! You can still get something useful from your raw logs.

Normally I'd say don't mess with your logs - it's a slippery slope and before you know it you'll find yourself writing your own web analytics application from scratch. Don't go there! However, logs can actually be useful for error reporting, at least as a once-off project. The basic information about a broken link is contained within a single row, so there's no need to sessionalize multiple rows into visits.

Here are a few guidelines for log handling, should you have the need. Since log files are quite large your task will be easier if you pick a fairly short, recent date range for analysis. Next, you (or your sys admin) can filter down the logs so you just get the rows with status code 404. Pop your data into Excel (it fits in Excel, right?) and make sure you can identify what each column contains. The columns you'll be most interested in are requested URL (the broken link itself) and referring URL (the page on which the broken link appeared, if applicable). Finally, make a pivot table and identify the most common broken links and their sources.

3) Have a custom 404 page, and tag it

Allow me to demonstrate how to tell if any site has a custom error page: http://june.typepad.com/foo Oh no, a broken link! Now I know what my 404 page looks like, and by viewing source I can see if it's got a web analytics tag on it (as of this writing it does not). Try this on your own site. It will work like a charm unless you actually have a page called /foo.

If you discover that you haven't got a custom 404 page, it's time to make one - it's simply good form.  For inspiration, here's a practical and amusing post on how to create an effective error page.

As an extra step for those who use a tag-based web analytics tool, you will need to make sure your custom error page is properly tagged.  The specifics will depend on the tool you use, so go to your solution's document library and read the fabulous manual.  In the end you will get error reporting that's just as good as log file solutions, and a lot less effort than parsing raw logs.

Now, after trying out the 3 tactics mentioned here, take all of the problems you've unearthed and submit them as bugs. It will take far longer to fix the errors than it did for you to find them in the first place.  Mission accomplished!

Photo credit: Meteorry

Real-World Challenges of Tracking Mobile with Page Tags

[I offer a more-formal-than-not article based on recent real-world experience doing mobile analytics for a Semphonic client.  You will be interested if you are a traditional web analyst who soon faces the added responsibility of measuring mobile.

For what's bound to be an engaging discussion about mobile analytics, come to the X Change Conference and attend Bob Schukai's 2 huddles on the topic.  Bob advised me as I wrote the following article and I was really impressed with his depth of knowledge about the mobile space.]

Real-World Challenges of Tracking Mobile with Page Tags

As the mobile web grows in popularity, so does the need for mobile measurement.  When put to the test, say, with a basic mobile campaign, we find that mobile measurement has not yet reached the level of maturity that we have come to expect from traditional web analytics.

If we treat mobile measurement like traditional web measurement we face challenges right away, starting with data collection.

Many popular web analytics tools available today – like Omniture and Google Analytics – rely on JavaScript tags for data collection.  Using this method, site owners place a tag on every page they wish to track; when a visitor accesses a tagged page, event-level data is sent back to the web analytics tool. 

Tracking mobile web in this manner is problematic, though, because mobile browsers do not reliably support JavaScript.  Some tag-based web analytics tools provide a fallback tracking method when JavaScript is not present – namely, a hard-coded 1x1 pixel image request that collects a subset of the standard event-level data.

An increasing number of mobile-specific tracking solutions are surfacing on the market; they offer arguably more robust data collection methods than traditional web analytics tools.  [My colleague Phil Kemelor has written a nice series on the mobile analytics vendor landscape, if you're interested.] However, despite known deficiencies, site owners may still opt to use a traditional web analytics tool for mobile measurement simply because it’s already an accepted business standard for tracking existing web content. 

In this article we will outline some of the challenges faced when using a tag-based web analytics tool adapted – by way of an image request – to measure mobile. 

An example

Consider two very similar online campaigns aimed at promoting the download of an application: the first campaign goes out as an email blast on traditional web, and the second campaign goes out as an SMS blast on mobile.  Beyond the difference in screen size, these two campaigns look a lot alike: a message, a click, a download.  But, when it comes to measuring the effectiveness of each campaign, mobile brings a whole new set of challenges.

Using this example – a pair of simple campaigns – we will illustrate common mobile measurement issues concerning campaign clickthroughs and downloadable files.

How do we track campaign clickthroughs?

In our campaigns, site-side tracking begins the moment someone clicks through from the message they receive to the landing page on the site.  This tracking process is well-defined on traditional web, but less so on mobile.

Campaign clickthroughs are typically tracked using a code appended to the query string of each URL.  When a visitor clicks through to the site, the campaign code gets collected by the JavaScript tag on the landing page and is then passed on to the web analytics tool.  Without the use of JavaScript, a bit more effort is required.

On mobile, and with image requests for data collection, we cannot easily intercept campaign code query parameters on URLs.  As a workaround, unique landing pages can be set up to track traffic from each campaign.  This approach, although it works, does add a layer of complexity to the campaign creation process beyond what we would normally do to track campaigns on traditional web sites.

How do we track downloads?

The measure of success in our campaigns is the download of a file.  Once again, established tracking techniques on traditional web must be re-evaluated on mobile.

Traditional tag-based web analytics tools track downloads at the moment the visitor clicks on a link to get a file.  This counts downloads initiated, not downloads completed, but it is a concession we’re willing to make in return for the convenience of tag-based tracking.  [For more on this somewhat-sticky subject see my recent post on downloads and page tags.]  However, since link click tracking requires the use of JavaScript, even this limited functionality is lacking on mobile.

On mobile, and with image requests for data collection, we must make do by treating the page just prior to download as a signifier of the download itself.  This method will necessarily inflate the number of downloads, though, since it’s entirely possible to back out of the process before actually requesting the file.  In this case, clear communication to data consumers is recommended in order to set expectations about data quality.

After all that, just the basics

The tracking techniques described above provide the absolute bare minimum we need in order to measure mobile campaign effectiveness, namely page views of the campaign landing page and downloads of the file.  Tracking becomes more problematic if we hope to get accurate visit and unique visitor counts; mobile browsers do not reliably set cookies, and we are left with very weak rules for visitor identification.

The lesson learned, in comparing very similar activities across traditional web and mobile, is that mobile requires somewhat more effort just to get the most basic tracking in place.  While we need not reinvent the wheel as we move into this new medium, mobile does force us to reconsider some of our fundamental assumptions about web measurement.