By Andrew Edwards on June 10, 2011

Revamp in 30 days? I can almost hear the readers say to themselves: "How can that be possible?"

The reasons why not are many -- they are the keys to understanding why rapid analytics development almost never takes place. However, once we have identified the why nots, we are already on our way to removing them as roadblocks because it really is possible to revamp analytics quickly if you proceed with due speed and deliberation.

The first and most important step in revamping analytics is to remove unnecessary barriers. Some of them are structural, some of them technological, some of them psychological -- as we shall see.

Common roadblocks to rapid deployment
The most common misstep taken by companies looking to revamp analytics is a particularly time-consuming one: Companies believe the tool is at fault and that choosing a new one will relieve them of most of their analytics problems. They spend a great deal of time reviewing other toolkits yet, in almost every case, they don't need to. The guidance here is, assuming you've got an up-to-date tool or service, stick with the one you've got. It can do the job -- you just need to properly deploy it.

Another misconception is that analytics must be deployed almost universally and that its results must be available to all comers. Studies have shown that focusing analytics where it counts, and limiting data access to those who will really do something with it, almost always drives analytics success. Focused deployment also saves time.

The most important and most time-consuming roadblock to speedy analytics is in the tag development and deployment cycle. The art and science of writing proper tags and placing them where they belong is little understood by most -- and that's OK, because you can bring in specialists to perform this kind of work. Too often, unqualified agencies and individuals get involved in this phase and their self-serving mantra is broadcast to anyone within earshot: "This is hard." "This will take a really long time." "This won't work with our systems." None of these are necessarily true. Based on a new understanding, it makes sense to keep developers and agencies from standing in the way. Very few measurement tasks are impossible or "very difficult" to tag, as long as the tag-makers and tag-placers view this task as part of their profession and not as part of their secondary or tertiary responsibility.

We have identified the negatives and the land-mines. Let's move on to what will constitute positive action towards a 30 day revamp.

Days 1-3: Key stakeholders
The first positive step is to locate and convene your stakeholders. One hopes this will not take 28 out of the 30 days. If it does, count forward from the meeting you'll convene! Sometimes it is hard to get busy people into a room, but in this case it makes sense to try. The participants should include digital marketers who need to make content and design decisions; a web analytics "analyst" who clearly understands statistics, marketing, and what reports mean to the company; and a web analytics specialist or team that understands the analytics tool thoroughly from a technology point of view and who understands the web analytics landscape at large (the better to avoid non-obvious cliffs and swamps).

Often the measurement requirements determined at this meeting are characterized as key performance indicators (KPIs). These form the bedrock of a focused, rapid deployment.

Days 4-8: Reporting design
Your web analytics tagging and technology experts now come into play -- they should take no more than a few days to come up with a robust reporting design for approval. The report design should include all relevant report layers, and each report must supply data to a defined marketing requirement. Just as important, it should make a note of the current reports, profiles, and tags that are no longer needed. A streamlined reporting set is much more effective than a cobbled, Rube Goldberg contraption that has somehow accrued over time. The marketer's job is to make sure the new, streamlined reporting design meets requirements and, if so, to get buy-in quickly from stakeholders. Turnaround time on report design approval should be closely monitored, as any lag at this point can throw off your 30-day schedule very badly.

Days 9-12: Tag creation
Your web analytics tagging and technology experts must now create a tagging schema to maximize insight into your site's user behavior patterns. Creating a plan that utilizes as much standard code as possible, they must also create custom tags that will allow your reporting to become a tailored fit for your company's needs. Avoid any suggestion that "out of the box" tags should simply be deployed across the entire site, as this will not end up matching reports to requirements.

Days 13-18: Tag deployment
In this phase, tags are deployed. It is not as simple as it sounds. Since most analytics teams don't touch the organization's HTML, the developers of the HTML must become involved. This can often cause friction. What happens here is that developers are being asked to put code on their pages that will measure (via neutral third party) the success of what the developers have developed. Is it any wonder that developers drag their feet in deployment? We have seen projects disappear for six months or more as developers "put it in queue" until such time as they have grown tired of watching reruns of "The Office."

Developers, however, do report to the organization. Put them on notice that tag placement is in fact on the project Gantt chart -- since it is only copying and pasting some lines of code into the page as instructed by the analytics experts, it must not take more than a few days to perform this purely functionary task.

Days 19-23: Quality assurance (QA)
Let us assume your developers have stuck to the timeframe in the Gantt chart. Now it's time for your analytics technology experts to perform QA on tag placement. They will go through each tagged page carefully to make sure the tags work, are properly placed on the page, and are properly integrated into your content management system. At the end of this review, developers might need a day or two to go through an iterative process of fine tuning with the guidance of analytics technology experts. Now the right data is being collected.

Days 24-27: Report configuration
In this phase the analytics technology experts go into your analytics tool and configure the reporting structure so that it uses the specialized tag-based data that has been collected. This key step involves a very thorough knowledge of all the basics and all the bells and whistles inside the analytics tool being deployed. Chances are, if you have targeted the effort properly, this will result in a relatively small set of key performance reports, certain carefully constructed dashboards, and perhaps the facilitation of an extract for a spreadsheet or two such that some data can be matched with non-web customer data. The analytics experts who have configured the tool will also perform a reporting QA to make sure data is coming through as expected.

Days 28-30: Knowledge transfer, documentation, and turnover
Here we bring back the original stakeholders for approval of the reports. If everyone has stayed on track and the report definition (above) has been followed by all concerned, the reports should meet with approval. If some tweaking is needed, this can be accomplished in a day or so. At the end of the process, a half day or so of "knowledge transfer" should take place -- the analytics technology experts in this phase educate end-users and analysts about what they should expect to see, where to find it, and, should it seem confusing, what some of it means. Finally, all documentation and materials used in development should be turned over to the team's leadership so it can be kept on file for future reference.

After the revamp
Thirty days have passed. If all the above steps are followed, your analytics function is indeed revamped. Does it mean you will find analytics nirvana on day 31? It does not. Does it mean you will never need help again as sites and requirements change, or as turnover takes place inside the organization? It does not. In fact, a healthy way to proceed after the initial 30 days is to make sure you have engaged with a team of analytics experts that can support you as needed going forward -- perhaps a day here and a day there, designed to keep analytics healthy and pointed in the right direction. That is, until the next big revamp is needed -- and then you may want to start that 30-day clock again.