15: Analytics Tools

The closing chapter focuses on selecting analytics tools and vendors, and underscores that it is important for companies to first understand what they are doing before seeking out the tools to do it. A common practice, which is incidentally the worst possible practice, is simply to buy a piece of software and install it. Tools--no matter how sophisticated--can't ensure success without a plan.

When to Choose an Analytics Tool

A company is not ready to begin evaluating analytics tools until they can answer the following questions:

After that, the author carps a bit more about companies that buy boxed software without knowing what they need to do with it. The problem with Web analytics isn't the need for a better tool, but for the proper approach. A nice bit: if you can't write a book with a pen, you'll not be able to write one with the latest version of Microsoft Word, either.

Methodology for Selecting a Tool

The author suggests a methodology for selecting an analytics tool. (EN: it seems overly meticulous an unnecessarily complex - while such investments shouldn't be made on a whim, my sense is he swings too far toward the opposite extreme.)

First, determine your requirements in terms of the kinds of analysis you need to perform. This should not be done after looking at various tools and deciding which features are attractive or impressive: it should be done beforehand to ensure you define the qualities you actually need - so you do not end up buying useless functionality while failing to get what you really need.

Second, involve others in the organization who will have responsibility: the IT department can provide technical requirements for the solution, as well as information about other systems with which it must interface.

Put this information together into an RFP for vendors to bid. Depending on your budget and the complexity of your needs, you might also seek to get the vendors to present their solutions and be available to answer questions.

The overall timeline for a sizable project would give vendors about three weeks to prepare a presentation, one week of presentations to the team, two weeks for the team to make its decision, and anywhere from a week to a month of contract negotiation.

(EN: All of this is very large-scale, for a company making a seven-figure investment in a solution. Smaller firms should still develop requirements, but will have to do the information gathering on their own and purchase an off-the-rack solution, as it's not worth a vendor's time to respond to RFPs and deliver presentations for a small sale.)

Criteria to Review and Select Vendors

The author presents a random array of questions to answer about a vendor - these should be covered by their response to the RFP, their presentation, or they may have to be asked. While the list, itself, is some what scattered, a few important points are implied: you should seek to ensure the tool provides the analysis you need, that it is stable and works with your systems, and that the company provides good after-sale service.

(EN: I'm not preserving it, because its' a grab bag of random things that is not comprehensive, not particularly well organized or explained, and probably not relevant to all projects. There are better sources for information on how to select and manage vendors for IT projects.)