In the last post of this blog series on being successful with digital analytics, I showed how you could use the newly created requirements driven SDR to identify the development work needed to address your highest priority requirements. Many of those items will require new data points to be added to your implementation. In this post and the next one, I will offer some advice in adding new items to your existing implementation.

While I have been a consultant in the area of digital analytics, one of the things I have learned is that most organizations don’t implement things correctly in their analytics tool. The problem stems from the fact that implementations are primarily driven by 1-2 people within an organization or from outside consultancies. Unfortunately, there are very few established best practices on how to translate business requirements to analytics tools. For example, if I asked five different people of varying levels of expertise in Adobe or Google Analytics how to tag on-site search tracking, I would likely get at least four different tool-based solution architectural approaches. This is compounded even further when taken to the next step of determining how to implement the tool-based solution in code, data layers and website events.

In general, if I am working with someone who has been part of many Adobe or Google Analytics implementations, the odds go up that the solution will be viable, but at most organizations, the people architecting the solution have only been part of their own implementation or likely very few. This problem is exacerbated by the fact that many organizations haven’t invested enough time and money into learning how to implement the tool in which they have invested a large portion of their analytics budget.

I saw this often in my “Wolf” role at Omniture. As mentioned in the inaugural post of this series, I often saw organizations blame the tool for their problems, when, in fact, the problem was their usage of the tool. There is a story about this that I often tell when presenting at conferences. I was once in New York City at a large Omniture customer who berated me for about an hour about how all of their problems were due to the tool. In a rare moment of me losing my cool, I asked this client to get the person who knew the Omniture product the best to come to the conference room. They grabbed their main development architect and I threw down a challenge to the guy. I took out my checkbook (we still used those back then!) and offered him $5,000 from my bank account if he could tell me the best way to implement three different scenarios I would provide. But the catch was that he (or his company) would have to pay me the same $5,000 if he didn’t know how to provide the solution. The look on this poor guy’s face was priceless as he sluggishly declined to partake in my bet. I then asked the company how it could be possible that they had spent over two-million dollars on Omniture tools over the past few years, but didn’t have anyone who knew the tool well enough to take on a relatively simple challenge?

If your organization doesn’t take the time to fully understand the ins and outs of your digital analytics tool, it runs the risk of wasting all of the hard work you have put into identifying your business requirements and earning the trust of your stakeholders. If you don’t collect the right data, you can sometimes do more harm than good by sharing data that is inaccurate. While you can rely on outside consultants for help at times, you still need to have people within your organization who know the right way to translate business requirements into your chosen analytics tool.

Your task for this post is to take some time to assess your current internal level of tool implementation sophistication. While this is a longer-term action item list, I suggest you do the following:

In the next post, I will show how you can add new implementation items to your implementation and newly created SDR.

Adam Greco
greco@hey.com

P.S. Have something you want to discuss about this post? Email me at greco@hey.com.