Server logs or SDC javascript tracking?

Applies to:  software

The Outsider talked about this topic a while ago at the end of the AVG Linkscanner posting.  That posting consisted of lists of the pros and cons of the two data collection methods.  “Pros and Cons” is the structure used by most sources that we’ve seen, although our lists of course are more complete and correct than others’ …

This post on the other hand is like the first question of a decision tree.  Or like an online personality test.  This post consists of oversimplified if-then stuff that, despite the oversimplification, might float some important issues a bit closer to the surface for you.

To continue the personality test analogy, we have to acknowledge that any personality test worth its salt will produce conflicting feelings while you take it.  The happy secret in the analytics world is that it’s possible to use WebTrends software with both types of data, even within the same WebTrends license, without messing up licensing costs.  We’ll do a post soon about the so-called hybrid approach.

Are you ready for oversimplification and conflicting feelings?  Here’s our best shot at an if-then list for data collection method choices, if you are using the software. 

• Is owning and operating a dedicated server for SDC collection out of the question? Same for sharing somebody else’s SDC server? Then it’s server logs for you (or the On Demand service).  (Obviously I am putting the easy ones at the top of the list, but it’s surprising how often people go “what?  I have to have a server?”)
• Does your site rely on visitors crossing over to other domains that you don’t own? For example, is your check-out process hosted by a shopping service? If so, SDC may be your only way to get visit information all the way through to the receipt – if the service is willing and able to add your SDC tags to their checkout pages.
• Do you have no access to the site’s code, or no way to get the SDC tag onto the site pages? If it’s all out of the question, then server logs are your only resort.
• Is your site made up of more than one domain? Do your visitors often go to more than one of your domains during a visit?  And do you want to report on all those page views as one visit? Then you need the SDC server and tags which can magically give a visitor the same cookie no matter what domain they are on.
• Does your site use a lot of redirects that have to happen without pause yet need to be tracked, or does it use immediate meta-refreshes? For example, do you have a lot of vanity domain names that redirect to your main domain? Server logs are the only way to track these reliably.
• Is it important to have complete and correct path analysis? Then you’ll need SDC for several reasons. a) It collects every page viewed, including those that elude log files because they are served from a cache (example: back-button page views).  b) It collects clicks that jump off to other sites, form submittal steps, mailto steps, downloads, and other “invisible” things. c) SDC follows your visitor across every domain you’ve put your tag on. d) Finally, SDC cookie-matches a first-time visit’s initial hit to the rest of the visit, avoiding visit breakup in those cases where the IP address changes between the first and second hits. 
• Does your site push technology boundaries, causing you to want to know all about your audience’s screen resolution, Java version, and so forth? SDC is your answer.
• Are you worried about somebody pirating your pages and displaying them on their site? If they’re dumb enough to not remove the SDC tag code, then SDC will help you find them because the SDC beacon sends signals from wherever it may be.
• Do you get a lot of spider and bot traffic that you don’t care about, and the act of filtering it out is driving up your WebTrends page quota? Then SDC tagging could save you some WebTrends license money, because SDC logs usually don’t collect spider hits.
• On the other hand, do you really, really want to know about spiders and bots and what they are doing on your site?  SEO mavens for example want to know how quickly, recently, or thoroughly the various spiders have been around.  Techs care whether Cuil’s overenthusiastic bot was responsible for a recent server slowdown.  If so, server logs are your only way to track bot and spider requests (although too many of them disguise themselves too well).
• Is it difficult to get server logs from your hosting provider? SDC creates its own log, hopefully in a more accessible place for you.
• Do you lack confidence that your programmers will get the tag onto every page, including in the future as the site changes? No tag, no record, remember. Server logs on the other hand are basically automatic and will record every request.
• Is there much chance that your visitors will often click away from a page before it completely loads (and therefore before the SDC tag fires)? For example, does your site’s audience tend to be on really slow connections, or are your pages ultra-dense? Then server logs, which capture requests right when they happen, will be more reliable than SDC tags, which if installed at the end of the page won’t fire until the whole page has been received (not rendered, but received).
• Is it really important to know how quickly the server is responding to file requests? Server logs are your only choice. But only IIS server logs.  (Apache logs will record this info but WebTrends can’t cope with that log field.)
• Do you need fairly exact numbers for bandwidth use? Server logs will collect incoming and outgoing bandwidth use for every single request, including images. Given complete server logs, WebTrends will add everything together for you and give you hour-by-hour bandwidth consumption stats.
• Do you care about broken links to images, or to style sheets, scripts, and other miscellaneous files? Link-checking software is available, but server log files also collect this information and WebTrends has an error report that will give you a complete list.  SDC tags ignore calls to images etc entirely, whether broken or not.
• Do you feel technically up to the task of tracking Flash by placing calls within your Flash applications? If not, server logs will give you minimal Flash tracking automatically – by recording requests for the Flash .swf files.
• Do you want to look at historical data for your site?  Your old server logs are probably still there.

That it.  Are you conflicted?

If you’re not conflicted, we offer this.  The Outsider seems to always add little postscripts, so here we go.  It’s possible to trick server logs into collecting some or all of the specialized SDC information like screen size, because it all boils down to javascript code on your page.  It’s also possible to trick SDC into getting some of the unique server log information.  We acknowledge this, and wrote our little questions for the less technically adventurous.

Tags

Somewhat Related Posts