DSC01838 small For some reason there is so much on this blog about the “business side” of things but not much technical stuff. So to make up for that this post covers some of the “technical” best practices around tracking with your web analytics tools, especially if you are using JavaScript tags.

Often the job of implementation is left to the friendly neighborhood IT person and your web analytics vendor. Yet there are numerous business decisions that need to me made during the course of implementation, many of which have huge data implications. Hence it is imperative that Web Analysts and Website Owners and Decision Makers are actively involved during the implementation process. It bears repeating that a successful web analytics implementation is not just the IT guy / Vendor’s job.

It is important to point out that this post is written with the business side user in mind and not the deep technical expert God (to those of you in that category perhaps the nine recommendations below will be rather obvious). My hope is to make our business brethren just a smidgen smarter about implementation issues (javascript tags or otherwise) and attempt to share with the technical amongst you a few critical decisions you should expect your busienss folk to make (and how perhaps sometimes technical sexiness can be a data collection hurdle!).

As always your individual vendor will be the best source for unique implementation guidelines. Please do not overlook that important resource, while keeping in mind that they don't know your site or your business hence you'll have to bring that "expertise" to the table.

Summary: Here are some implementation best practices, in no apparent order of importance….

    # 1: Tag all your pages.
    # 2: Tags go last (customers come first :).
    # 3: Tags should be inline.
    # 4: What’s your unique page definition?
    # 5: Use cookies intelligently (they are delicious).
    # 6: Javascript wrapped links might be a issue.
    # 7: Redirects, be aware of them.
    # 8: Validate data is being captured correctly.
    # 9: Don’t forget Flash, Flex, RIA, RSS, Videos etc.

Here are the best practices in all their gory details……

# 1: Tag all your pages.

    Seems fairly straight forward. :) You should tag all your pages simply because with javascript tags, more than with other methodologies, if your page is not tagged you have no data and you have no way of going back and finding it (short of looking in your web log files which can be a non-trivial challenge).

    In the past I have recommended Web Link Validator from REL Software as something we have had a positive experience with. It can do a lot more than check missing tags, see the website for all the features, so all around a good piece of software to have. It runs between $95 – $795. I am not affiliated in any way this this company and do not benefit in any way from recommending them.

    Best practice is to run this nice little program, or your own equivalent, once a week and send a report to your web development team with a list of pages missing the tags.

# 2: Tags go last (customers come first :).

    In many web analytics implementations on the web you’ll see the tag right at top or in the header or before the <body> tag. This is sub optimal. Your javascript tag should go as close to the </body> tag as possible. The simple reason for this is that the tag should be the last thing to load on the page. In case your analytics server is slow in responding, or has simply died (less likely), then atleast the webpage and the content will load quickly.

    Our websites are there for customers and secondarily for us to collect data from. : )

    Update: The only exception to the above rule is if your web analytics vendor has a async version of the JavaScript tag. If so the tag will be placed at the bottom of the [HEAD] section of your page. The async code loads, well, asynchronously, which means that it does not impact your user experience (even if the vendor's servers are dead). Another cool benefit is that the async code collects more data, more accurately.

    At the moment Google Analytics is the only vendor to provide this type of improved tracking. You can learn more about it here: What is the Google Analytics Asynchronous Tracking Code? If you use GA, run and switch to async now!

# 3: Tags should be inline.

    This one often comes back to bite many implementations. Golden rule: javascript tags should be inline. They should not be placed in delightful places such as inside tables or frames and such things. It will greatly impact your ability to collect data accurately. Enough said.

# 4: What’s your unique page definition?

    Increasingly websites are becoming dynamic in how they react to customers and how they personalize content and how they “re-leverage” the same .html (or .jhtml or .asp or .jsp etc) page to do different things. What this means is that you can no longer rely on the product-name.html to define a unique page identity.

    Javascript tags, and perhaps all other methods, collect that entire url along with all the parameters in the stem. During implementation (and indeed if you evolve your site often) you will have to make sure that you “teach” your web analytics tool which combination of file name and parameters identifies a page.

    For example for this blog, which is a static site, here is a random url:

    http://www.kaushik.net/avinash/2006/10/ten-minutes-with-
    brett-crosby-google-analytics.html

    the .html simply identifies a unique page.

    But for the Best Buy website:

    http://www.bestbuy.com/site/olspage.jsp?skuId=7686998&type=
    product&cmp=++&id=1134704163586

    it is olspage.jsp AND the parameter skuId that possibly define a unique page. If in this case you plonked a web analytics tool without identifying what makes a page unique you would obviously get wrong numbers.

    Cute example of how hard this can be here’s a real url from website, can you guess what identifies the unique page? :)

    http://removed.un-named.site.com/cgi-bin/removed.cfg/php/enduser/

    std_adp.php?p_faqid=1165&p_created=1137444477&
    p_sid=k1lMDYoi&p_accessibility=&p_lva=&
    p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19
    jbnQ9NjYwJnBfcHJvZHM9JnBfY2F0cz0mcF9wdj0xLjUxMiZwX2N2PSZwX
    3NlYXJjaF90eXBlPWFuc3dlcnMuc2VhcmNoX25sJnBfcGFnZT0xJnBfc2Vh
    cmNoX3RleHQ9ZGVsdXhl&p_li=

# 5: Use cookies intelligently (they are delicious).

    Use first party cookies as much as possible and not third party. There are a billion words about this topic so I’ll stop here. Ok one last time, use first party cookies! :)

    There are three types of information you will collect, source attributes, page attributes and “user” attributes (non-PII please).

    Source attributes: where do people come from (websites, campaigns, search engines etc etc).

    Page attributes: what do they see, how often, where, from where to where, page grouping in all your content etc.

    User attributes: who is this “person” (persistent anonymous id’s, has a login or not, are they in a test, and more).

    Usually, stress usually, Source and Page attributes are best captured via URL’s and Parameters. User attributes, again stress on non-PII (please be careful about this and disclose in your Privacy Policies explicitly what you collect), are best stored in cookies.

    User attributes, those identifiers (non-PII) that are persistent pan session are best stored in cookies. They will stay in the browser and can be easily read by your tags without have to stuff your URL’s and make them fat.

    Sometimes User Attributes, like anonymous cookie value or your login to Times Select say on the nytimes.com website, tend to be held post session initiation on the server. If this is the case then please be aware that your javascript tags are blind to that data.

    One last thing on cookies, please be aware that IE 6 limits the number of cookies to 20 per domain. After that it starts blowing away your first cookie and then the next etc. Not nice. There are ways to get around this like consolidating cookies or by using sub domains. Please check how many cookies you are setting In Total from all things that are on your website and work with your developers to address the issues, if you have any.

# 6: Javascript wrapped links might be a issue.

    There are often links on the website that are wrapped in javascript. Usually pop-ups, but could be for other purposes. For example this one:

    javascript:var x=window.open('http://qqq.links.ppp.com/pages/prices.asp?)

    Be aware that if you are going to be using reports like Site Overlay (Click Density) that these links might not show the number of clicks in that report due to the javascript “wrapper”. This is not a issue with all vendors but with enough of them that you should be aware of it.

    The recommendation is to use javascript “wrappers” on links when you absolutely need it. Remember this is not just a problem for web analytics but also for search engine Robots / Spiders. They don’t follow javascript links (or execute javascript) so they will also not reach or index that valuable piece of content you have wrapped in javascript (so bad for SEO).

# 7: Redirects, be aware of them. 

    Redirects are nifty little things, they can direct traffic in a nice way in case links change or if your SEM / Ad / Whatever agency can track data or, in the good old days of web logs, you wanted to capture clicks where you send data off to other websites (domains). But redirects can also mess up your web analytics data collection in a big way if not done right (and it will also, like above, possibly mess up your indexing quality by search robots). Let’s cover two instances to outline the data collection challenge:

    If you have “internal redirects” (redirects that simply lead from one page of your site to another) then this can be sub optimal. Look at this link from microsoft.com…..

    http: //g.msn.com/mh_mshp/98765?09769308&http://www.microsoft.com/down loads/search.aspx&&HL=Downloads&CM=Navigation&CE=Resources

    This goes from the home page to a sub directory on the same site. Not sure if MSFT is doing this to overcome any challenges with their web analytics tool but it is quite unnecessary, an extra hop for the data and it can cause a issue, so you have to make your tool smarter that from the home page, www.microsoft.com, people not going to g.msn.com but rather they are going to www.microsoft.com/downloads, , and that is logic that you have to maintain over time (which can get complex as the site changes), you also have to capture and store extra data and this can potentially cause problems when you are deep into segmenting the data.

    It is important to stress that it is quite likely that microsoft.com is doing this because they have figured all this out and it works for them. The core point is that with this illustration you should be aware of the complexity it can pose in measuring and you should go into it with your eyes open (and support of your website IT folks who might have implemented these things).

    Another instance of using redirects is while linking to other websites, outside your own….

    http: //www.removed.eliminated.com/Navigate.asp?Category=238
    &AppID=859&rDirURL=http://www.removed-solutions.com/
    application-for-payment-solution.htm&UType=6

     A final example of using redirects is as a part of campaigns (banner ads, search marketing, affiliates etc).

    http://ypn-120.overture.com/d/sr/?xargs=s0O0U7A8C4rk9M27-8w3mbaL1o7n8
    tRIM1MKG15yaTTYqt10IMC4KGO52LQGe8M8pF5dUjnquXOOoAHgzREB8exjcMUu16v
    lVN0xyLosI_NEvRbc4c55SJBlZNeL2GUFuP7dvj7_pkBvrWPmMV7wISkNgJ-y8sy_4OHc-
    xsvj1MeEj5UfOBmhfe67YJFqKl1OxNjJrlmQaC1QdUlNazUZM2DUyVaBmZI28GqX46fE9E
    EIPPIyYc1GDR_FI0dj59ZPUEh-v7Djt2yBtkx6TYdilGh1XUyi1hEXX4A2D3q34lAacTLynn
    9-4f8TLjxABMw

    goes to:

    http://srch.atdmt.com/search/18957/SRCH56zxfyaj5r/DEFAULT/
    ysmronpremium/content/.search?ovchn=OVR&ovcpn=ron&
    ovcrn=ysmronpremium&ovtac=PPC

    ends up at:

    https://www.removed.com/servlet/LMBServlet?the_action=NavigateHomeLoansAppFirstStep
    &TAG_ID=D778E3D4BFA722E4B48F537701A0F06F1165968367230
    &sourceid=seogtolre121405r1&moid=4793&q=

    So one click causes two hops (where data is collected by someone else outside your company at each hop) and the customer ends up at your site. Does your web analytics application have any knowledge that the user came from an Overture ad? If this was not proactively thought through the answer is usually No.

    There are two important things to consider here to ensure you can report and analyze data accurately:

    1) Work with your agency (or internal resource) to ensure that there is atleast one parameter that gets passed from one hop to the next hop to you so that you can track accurately the campaign, it could be the parameter “sourceid� above

    2) Please ensure that everyone is using 301 Permanent Redirects where possible. This will help ensure that the original referrer is passed on to your web analytics website (else your referrers report, your search engine and keywords report and a bunch others will be completely wrong).

# 8: Validate data is being captured correctly.

    Some web analytics tools use one standard tag to collect data. Other vendors have a custom tag all over the place (so your website could be tagged with 25 different tags for your vendors on different pages because your vendor needs lots of data to be place in customised variables up front for post data collection analysis or they are capturing various pieces of data like order / lead information).

    I won’t pontificate on which approach is better (there is no such thing, both have pro’s and con’s). But it is important that you validate in QA and production that your 25 customised tags are each capturing exactly what they are supposed to.

    I know that Omniture has a nifty utility that you can use to validate and review that data is being collected by Omniture tags as it should be. This is really nice and helpful and I do like it very much. Please ask your vendor if they have something like this (and they probably do).

    It is recommended that you check your tags and data collection once a month to validate that normal site releases have not messed something up.

# 9: Don’t forget Flash, Flex, RIA, RSS, Videos etc.

    “Normal” javascript tags won’t work with these rich media experiences. If you have lots of rich experiences you’ll have to have a completely different and deeper (and more painful) strategy to collect data. You will have to use custom tag or standard tags in custom ways or different data capture mechanisms like “event logs” to collect this data.

    I won’t go into lots of detail except to say that during implementation you should think way up front in terms of tracking rich media. For some recommendations on how you can track and what to track please check out the podcasts I had recently done with the Web Analytics Association.

    Tracking rich web experiences requires a lot of deliberate planning and implementation up front before anything gets released to ensure that via you web analytics tool or via a custom solution you are able to track some semblance of success.

I am positive that all the technical complexity in this section causes heads to hurt, especially if you are on the business side. It is complicated, it seems really hard and in your spiffy vendor presentations many of these things were not highlighted. But there is simply no other way of ensuring that you are collecting data accurately other than looking at each of these items (and others that you might be doing that are unique to your website) in a very deliberate manner and doing so up front.

It is important for you to personally understand these issues so that you can ask the technical folks (yours and your vendors) the right questions and after you get your first data check to make sure some of these things have been done right so that you can have confidence in the data.

It would be wonderful to get some of your own tips and best practices from your experiences. Please share your best practices, or just your war stories, via comments. Thanks.

[Like this post? For more posts like this please click here.]

Social Bookmarks:

  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite