How to decommission a web analytics solution

There comes a time in every analyst’s life when an organization decides to change up the game and move from one web analytics solution to another.  Transitioning the reporting data isn’t usually that painful, if done correctly; it’s decommissioning the old solution that is most challenging.  Having survived a number of these transitions already, I came up with a brief list of best practices when decommissioning most paid web analytics solutions.

  1. Audit URLs to be migrated.
    The one thing any analytics solution will be good at will be to output a list of URLs that are tracked.  Use this as your dashboard every day, to ensure these URLs go dark.
  2. Audit JavaScript file locations.
    Think your JS file is centrally hosted?  Think again.  In my experience, very few organizations with multiple web properties keep a centrally-hosted instance of their analytics JS file.
  3. Audit custom event tagging.
    Keep in mind that server hits (and I do meant hits) can be generated asynchronously (onClick, onLoad, embedded in redirects, in frames, etc), that may account for a significant portion of important business goals.  If your only goal is to turn off analytics to a particular vendor, feel free to remove these and forget they ever happened.  If you want some continuity in reporting from one solution to another, you will want a record custom events and prioritize their inclusion in the new solution so that you don’t lose sight of important metrics.
  4. Decommission the JavaScript library at least 30 days before end of contract.
    Browser caching is a royal PITA, but most busy sites will see a drop-off of cached JavaScript tags within a week.  Users however, do all kinds of crazy nonsense with webpages; some will actually save your homepage to their desktop and use it as a bookmark.  Leaving at least thirty days to sort out your odd user behavior and factors beyond your control leaves enough time to take affirmative action to kill server hits.
  5. Audit remaining URLs sending hits to the analytics log server.
    Using the list you generated in the first step, hone in on wayward pages that may still contain JavaScript, server-side code, or web services that are still logging hits.  In one implementation, I discovered a web service – long forgotten – uploading classification data to a vendor on a daily basis.  In another implementation, “no script” tags were still being triggered on redirect pages.
  6. Decommission any DNS entries supporting the old solution. (optional)
    Most self-respecting web analytics solutions will offer the ability to customize an implementation to support first-party cookies.  This is most commonly achieved through the use of a CNAME (DNS) entry on your primary domain, and may involve maintenance of a SSL certificate for secure areas of your site.  If you have the luxury of a CNAME, decommissioning is easy as pie; you kill the CNAME, you pretty much kill all server calls to your vendor’s analytics log server.

Know of any better solutions?  Feel free to share tactics you may have used on previous decommissioning efforts below.  I would love to hear from you.

One thought on “How to decommission a web analytics solution”

Leave a Reply

Your email address will not be published. Required fields are marked *