My Photo

Twitter Updates

    follow me on Twitter

    « eMetrics Recap in 100 Words | Main | X Change 2008 News and Deals »

    June 04, 2008


    Feed You can follow this conversation by subscribing to the comment feed for this post.

    Tim Wilson

    Isn't this a good case for *not* relying on page tags as your sole source of web analytics data? I'm not saying to try to build out a system that actually combines page tag and log file data, but I do think it is useful to occasionally take a look at your log files for your top downloads (and it's fine to ID these from the "downloads-initiated" data from the page tag).

    The thing to check, though, is that the downloads are getting completed -- either by bytes transferred or by status code. This still stops short of "the content got put in front of the user," but it's a lot closer. This is especially important for larger downloads -- evaluation software, for instance, or PDFs that are 100s of pages long. It's good to confirm that people are sticking with the download and not bailing out early for one reason or another.


    Interesting post here.. at least provides some good info for a beginner in Web Analytics like me! Here is my take on tracking download. When a client wants to track the number of downloads, can the download-able file be placed in a separate directory (lets say

    You will be able to track the download initiation from the log file by analyzing the data, while its evident that download started, you aren't able to confirm if the download was completed successfully. It would really good to compare the value of initiated downloads and bandwidth usage in subdirectory (in this case being and corresponding file) which should give approximate success of downloads happened.

    This is ain't a way to successfully track all completed downloads but atleast provide you an insight of approximate counts on downloads that happened. I hope what I am trying to explain here makes sense..!

    Your blog is really interesting, following you at twitter and subscribed to your RSS!


    Jacques Warren

    I have to disagree with Tom in part. Yes, relying on a profile that analyzes web server logs for the PDF and other downloads is a way to easily do it (but out of reach of the pure ASP solutions). However, in many cases, we need to couple the downloads with other dimensions; in such case there's a strong need in having those numbers in the same reports.

    June, a quick note: WebTrends has taken out all references to tracking downloads from the 8.1 literature as well as the knowledge base. Weirdly, this means they don't support it anymore. Talk about a bummer...

    June Dershewitz

    Thanks for your feedback, everyone! I guess I'm not the only one to notice this issue.

    Tim: True, page-tagging isn't the best way to do data collection if you care a lot about downloads. However, I think many companies have chosen a page-tagging tool just for the sheer convenience of it (read: never having to wrestle with logs). If a company decides to switch to logs (or tags+logs) then they have to decide if the added benefit is worth the added hassle.

    Also, good point about usability and big files. Without "download completed" stats we don't really know if files are prohibitively large. I suppose a qualitative survey or a spot-check of logs could help answer that question, but it's still less than ideal.

    Vinay: I'm glad you found me! I'm following you on Twitter now, too. I do understand your idea about using directory bandwidth to approximate completed downloads. However, I believe that bandwidth for a directory is just the sum of the bandwidth of every tagged html file in that directory - so if the directory contained no tagged files, the bandwidth would be zero. It would be pretty easy to test this out. :)

    Jacques: I know exactly what you mean about wanting to "couple the downloads with other dimensions." Ideally we'd like to segment completed vs. failed downloads by referring keyword, or landing page, or anything else that visitor did during their visit or their lifetime. Right now we can't.

    That's frustrating news about WebTrends and downloads. I'm still using WT v8 with one of my clients. Luckily they don't care too much about measuring downloads.

    Jacques Warren

    Hi June,

    I understand that the functionality will still be "usable", but not officially part of support/how-to's. That really escapes me... I mean, that is almost enough for a prospect to decide against purchasing WebTrends. Add to this that Omniture say they have made it even easier to track events such as podcast viewing, etc. which you would need dcsmultitrack for in WebTrends.

    June Dershewitz

    Jacques: That is not a good move! I wonder if WebTrends has any plans to support download tracking functionality in the future? Based on the reaction that I've gotten to this blog post, there's obviously a demand for tag-based or hybrid solutions that provide better download tracking than what we currently get today.

    Eric Rickson

    Hi there June and Jacques - WebTrends continues to support the tracking of flash, downloads, and an array of different web 2.0 events using our dcsMultiTrack functionality. This feature is broadly used by our customers and will remain one of our key methods for collecting events that don't fit within traditional metaphor of a page view.

    In terms of the documentation, we have been cleaning up our content and will be reintroducing it in the next month. Also, keep your eyes out for some new tools from us to make the tracking of these events even easier.


    Eric Rickson
    Product Manager

    June Dershewitz

    Eric: Thanks for your feedback! I'm glad to hear that dcsMultiTrack will continue to be supported, and it's also a relief to know that the documentation will be reintroduced. There's obviously a need for it.

    Fred Kuu

    This is an interesting post as I've had to address this question quite a bit at my workplace.

    Technically speaking, there is a way to "couple the downloads with other dimensions" such that you can look at download completions by segment X. The approach requires both a page-tagging solution with a first party cookie configuration and log files enabled on the servers that serve your downloads. However, there may be legal/privacy restrictions that would prevent you from doing this so I'll leave it at that.

    For companies that tend to have large files, you really should not use attempted downloads (provided by page-tagging solutions) interchangeably with download completions. You should just call it out for what it is - an attempt to download. There are way too many variables to consider why someone clicked on the link to download but did not fully download the file.

    June Dershewitz

    Hi Fred! Thanks for posting that tip about how to segment traffic based on downloads completed; very clever. I'm curious to know - since you do track downloads completed - what
    kind of business decisions you feel you can make based on downloads completed that you can't make based on downloads initiated?

    The comments to this entry are closed.