Stop Using The File Downloads Report!
Those of you who have read my blogs for a while know that I am a big proponent of using as many SiteCatalyst features as possible. However, in this post I am going to venture into uncharted territory by suggesting reasons to NOT use a SiteCatalyst feature – File Downloads. While you may be skeptical about this, I ask that you hear me out on my reasons and alternative approach before passing judgment!
How Does the File Downloads Feature Work?
Before dismissing the File Downloads functionality, let’s take a minute to understand what it does. Like most web analytics programs, SiteCatalyst provides out-of-the-box functionality for File Downloads such that when a website visitor clicks to download a file, it captures the file name in a special File Downloads report. In reality, file downloads are treated a lot like Exit Links as far as SiteCatalyst is concerned. The File Downloads report is very handy since you can open it and see which files are downloaded most like this:
Why I Don’t Like Using The File Downloads Report
As I have become more sophisticated in how I approach SiteCatalyst, I have found several flaws in the File Downloads report. Here is a quick summary of my issues with it:
- One of my pet peeves of the File Download report is that it stores the path of the file with both an http:// and a https:// so you often times have the same file represented twice in your reports. This throws off your data and it can confuse users. You can modify this by tweaking your JavaScript file, but I wish there were an out-of-the-box option to do this.
- There is no easy way to see how each file download impacts website Success Events.
- Often times, I want to see where the website visitor was when they downloaded a particular file, especially if the same file can be downloaded from different pages on my site. In the past, I have worked around this by modifying my JavaScript file to pass the file name to a custom sProp and then enabling the Previous Value Plug-in to store the previous pagename and enabling a Traffic Data Correlation between file name and Previous Page. This provides a way where I can choose any file name and then break it down by pagename to see the ranked order of pages it was downloaded from. Net Result – Out of the box File Downloads report doesn’t get me what I want.
- However, the real reason I don’t like the File Download report is that it ruins my Pathing reports. I love pathing. I like seeing where people go backwards and forwards through my site. But when I look at the Next Page Flow report or the Next Page report, I am not getting an accurate picture if there are File Downloads on a page. There are many cases where the most clicked element on a web page is a PDF that visitors download. However, when I look at my pathing reports, this file is nowhere to be seen. I can see it in the ClickMap report, but not in my SiteCatalyst pathing reports. Therefore, when my users look at the next page report, they are looking at incorrect data due to the fact that 10% of visitors downloaded that PDF.
So What Should You Do…
I don’t like to complain without offering alternative solutions so the following outlines what I would do instead of using the File Downloads report. Per my list above, at the end of the day, I have the following requirements for understanding File Download activity on my site:
- Easily see which files have been downloaded the most (and only once per file regardless of http or https)
- Understand from which pages visitors are downloading files
- See how each file download impacts my KPI’s
- Ability to see file downloads in my pathing reports so I can see what is really happening on each page
Seems reasonable enough right? So here is how you accomplish all of these without using the File Download report:
- Work with your developer to treat every file download as if it were a web page on your site such that it is passed to the Pagename variable (s.pagename)
- Ensure that when passing the file name to the s.pagename variable, you strip out the http or https so you just get the raw file path (you can also strip out your domain to make the pagename shorter)
- When creating this pagename, be sure to insert the phrase “file|” or “file:” in the pagename (or something similar)
- Remove the File Download code from your JavaScript file (so you don’t get double-charged server calls)
So that doesn’t seem so hard does it? But what does this actually get you? Let me extol the countless benefits:
- Passing the file download name to the s.pagename variable means SiteCatalyst sees file downloads the same way it sees any page on your website. This means you can see file downloads in Pathing reports so your next page and previous page reports will be accurate.
- If you remove the http or https you will only have one pagename for each file so you avoid the duplicate file issue I mentioned earlier.
- If you insert a file identifier (“file:”) then you can recreate the current File Downloads report you have today by just opening the Pages report and doing an advanced filter on “file:” in the Search area area.
- If you want to see which page visitors were on previous to downloading a specific file, you no longer need to use an extra sProp nor enable a correlation. All you have to do is find the file in the Pages report and open the Previous Page pathing report.
- If, by chance, people link directly to your file downloads, you can also calculate the Bounce Rate of each File Download since it is now part of the pagename variable which has pathing (and thereby Single Access & Entries) by default.
- Anyone want to see Daily, Weekly and Monthly Unique Visitors for each File Download? You just did it if you have those enabled on your Pagename variable (which most people have by default)!
- As I mentioned above, it is not easy to see how often each file on your web site “participates” in your key success events? This is because you cannot enable Participation on the File Downloads report. However, now that File Downloads are part of the Pagename report, you can easily enable Participation on the s.pagename variable (which you should already be doing) to see how often each file download impacts your key KPI’s.
- Last, but not least, if you have any correlations to the Pagename report (which is very common), you now have those correlations to every file on your website. For example, if you have Pagename correlated to Visit Number or GeoSegmentation Country, you now have all file downloads correlated to these as well without having to pay for any extra correlations or variables!
All in all, you can get a lot of bang for your buck with this handy trick. I think it can easily save you a few sProps, correlations and unique visitor CPM increases (I make no money on this blog so feel free to send contract savings my way 
)!
Final Thoughts…
Well there you have it. These are the reasons why I have chosen to take an alternative approach to the File Download report and I think it makes a pretty compelling argument! I will be curious to get your thoughts and see if you agree or disagree with me on this…
Adam Greco is the Director of Web Analytics at Salesforce.com. You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco. Please send questions and comments to adam@the-omni-man.com.
Please note: I am no longer an employee of Omniture and the content/views expressed here are my own and not those of Omniture.
Excellent article, and definitely food for thought on my next Omniture implementation.
Great article. But how do you track “people link directly to your file downloads”? That wouldn’t load the s_code.
Crap! I just finished a re-implementation across 20+ sites, I would have loved to do this!
Great post…again.
Andreas – When I say people linking directly to your site, I mean that you can see referrers for each File Download since when the file loads, it is treated as a Page which has referrers…You can also see the Bounce Rate since Pages has pathing enabled by default…
Hi Adam,
A couple of things I want to clarify with your post.
My understanding of file download in Omniture is that it is not like looking at logs. It is merely, a link tracker and takes a count on the links that have been clicked. Wont tell you if the file clicked was downloaded successfully.
So using the s.pagename for pathing reporting, won’t that inflate your data as you would want to assign a unique click value of that action for visitors?
eg// pre/post site usage as per the event/action.
Narbeh – I may need you to e-mail me to fully understand what you are asking, but the solution outlined here will not do more than the File Download tracking will do (i.e. know if they successfully downloaded it), but it simply moves it to a place that is easier to report on with the benefits I listed in the post. Feel free to e-mail me if you want to discuss further…
Adam
Adam,
I would consider extending this solution to the s.channel variable for sites with various content groups and downloads per each content group (e.g. large B2Bs or electronics companies such as HP, Canon, Dell etc.).
This would give the analyst an aggregate level view of download per content group (with the right naming structure, of course).
Thank you for a great post.
Michael
Michael – It is a given that every Omniture customer should have Pathing enabled on their s.channel (Site Sections) variable. This is usually done from day one of the implementation.
Adam,
I might not have been clear in my previous comment.
I was suggesting adding the downloads measurement to the s.channel. I wasn’t refering to the Pathing being enabled.
Hope this makes more sense.
Michael
Great post. This was confirmation that we did something right with our implementation. One of the drivers for us was the pathing on the site as well as a better view of activity on our responder sites. One the top actions on our campaign responder site was downloading a featured document. With just download reporting this activity was not measured as part of bounce rates or time on page. This solution fixes that.
I also had the same question as comment #2 earlier by Andreas. I just want to clarify whether your solution offers the ability to measure entries to the site on the document itself? If so, are you wrapping the documents in some code to make manual tracking calls? Our implementation uses the s_code to make the calls so the host page needs to load first. In our case the documents are never entry pages so we cannot measure bounce rate.
Finally, comment #9 by Michael is really useful. We have a lot of content categories on our site and it would it is useful to have category counts for our assets. This also would provide a simple way to drill down to document level reporting.
Thanks for the post.
Rob