tee-bee-dak | digital analytics, data, marketing

The death of the web analytics implementation – part 3

For part three, I want to focus a bit on how we got here.

I’ve often been heavily involved with complex implementations, going through constant tagging iterations. I’ve observed the following challenges (including, but not limited to) :walking in circles

  1. There are interactions with content/customers that are not tracked. In the best situations, these interactions have been deemed “not important to the business”.
  2. Defining what to capture takes time ($$$).
  3. Transforming those requirements into actual collection takes time ($$$).

The challenges are experienced at varying degrees. A lot of folks are doing a great job. There are digital analytics teams who have much of their implementation work automated, whether through a tag management solution (TMS), via proprietary scripting, or through their CMS platform. There are data layer standards (!!!). There are teams out there working so closely with developers that the entire implementation is integrated with the development process.

There are a lot of teams, however, struggling with all three of these… and I expect that #1 affects any complex implementation whether fully automated or manually integrated every step of the way. This is one of two places I am coming from when I say that the web/digital analytics implementation will die. That “we’re doing things backwards” and should be collecting as much as possible.

Even if there isn’t an organizational feeling that more data would be helpful, I’m sure the following scenario is familiar to many:

  1. something that could have been captured was not being captured
  2. you started capturing it
  3. you wished you could have the data retroactively

From one organization to the next, there are variations on these themes. Some hold publishing for analytics. Some push to production, foregoing anything but base analytics until custom tags can be applied. Some don’t need to touch anything by virtue of their implementation, but may experience other limitations and missing data.


Where I think there is “danger” (you know, analytics danger!), is where time isn’t set aside to consider what could be missing.

“There wouldn’t be time to interpret other data; there isn’t time to interpret all of the data we have today.”

Watch out. The danger! Slippery slopes! Organizational bad habits!

“Everyone is so busy. We don’t use all the data we have, so why bother collecting more. It will just cost more money to collect more data that won’t be being used.”

There can be truth to it, but please read on… at a certain level, in certain markets especially, it becomes necessary to have more data to compete at a high level. (And don’t take it from me… please. Use your favorite search engine and search for some combination of data/analytics terms with the words proprietary, competitive, and advantage all thrown in the mix. This looks like a fantastic start.) While I find this quite compelling, and I hope you do, it’s not even the most compelling point to many.

The amount of time/effort(/$$$) being spent on collecting data is something I would quantify. Often, the results of this labor are thrown away, replaced with the next set. Would the time not be better spent focused on developing for analytics, and analytics development? Things that are lasting, that sit on top of the organization and the data? Tool-specific efforts are exactly that.

When the Gods of Web Analytics spake, they set forth a rule. You spend on people and process ahead of technology. 10/90 even. When talking about spending 90% on people… this isn’t what the Gods intended. Implementation is supposed to be included in the 10%. Compounding the problem, by defining requirements that impose on collection, and by not capturing data objectively, a level of bias is introduced the data being collected. This is where time should be set aside to consider what could be missing and how to bring it into the fold.

Your data is unique, and you are the only one who has it (insert NSA hilarity here). Your data provides a competitive edge, if you have the ability to find the appropriate signals. The ability comes from business intelligence, from data science. Eric Peterson, nearly four years ago, described the “coming bifurcation in web analytics tools”  where there is a need for low level access to some basic business reporting and also a need for sophistication (BI/data science) in digital analytics tools for the enterprise. Four years later, there are still plenty of organizations that are just dipping their toes into the waters of full data integration.

I understand that many are not involved in an intense competition. They’re just analyzing their web data. Those businesses can carry on with GA. As Eric noted, it’s great that they get a pretty in-depth solution for free in GA and can spend their money on people to make sense of that data.

For others, organizations already piping data from web analytics into a data warehouse, a marketing database, a centralized system of any name… if you don’t have data scientists complaining about data collection today, you will have data scientists complaining about data collection tomorrow. Today, it may just be enough to have that holistic view in place. Tomorrow, there will be questions.

In my coming predictions post, I will predict that Google will include this methodology in 1-2 years. You will be able to turn it on, capture everything, and sort it out later.  Out of the short list of predictions I am making for 2014, I feel that this one is nailed. Automatic event tagging already came to us in 2013. As data capture enhancements are made, more businesses will consider migrating to premium to get at all of the data. We’ll see more work in this direction in 2014, and by the end of 2015 Google Analytics will automatically integrate with every CMS and eCommerce platform via “capture everything”.

This has been the third part in a series related to the future of web analytics vendors. The clickbait title up to now stuck to a “web analytics implementation is dead” theme, which is funny because I insist that I am not a fan of the meme. We’re also talking about more than the web, and more than implementation. I chose “web” as not to declare the digital analytics implementation as dead. There is already a dichotomy in mobile data collection. Event streams are not really a new concept for gaming and app analytics — it just costs more to store more, and so tailored implementations do happen out of necessity. For web analytics, however, “implementation” means something pretty specific most of the time.

The web is no longer so unwieldy that we can’t capture full event streams.

This is the death of the “death of the web analytics implementation” series, though the related topics will live on. I hope you will come with me… thanks for reading!


Thanks for stopping by. This "web/digital analytics implementation death" thing became a series. There were four posts:


This will continue to be a theme of my analytics hygiene posts, and presentations at eMetrics Chicago and... (Boston?)... and...?
  • michelejkiss

    So I’m a little late to the party here… but wanted to float some ideas.

    To me, there’s an ROI calculation that’s not being done in this proposed methodology. The math that is being done seems to be (Time spent on tagging) vs. (Cheap storage), but there’s a third element at work.

    Currently, analysts definitely spend an inordinate amount of time defining tagging requirements. But in those proposed “capture everything” method, would this effort not simply shift to after the data collection takes place? You note that “yes, there would be work to sort out the data”, but I would argue there is MORE work involved there. Why? You’d be capturing absolutely everything. Currently, the work is in defining requirements for what it is important to the business. In this scenario everything, no matter how useless, would have to be sorted out, for meaningful data.

    The ROI equation then becomes:
    – What is the value of the additional data you would have “missed” (aka not realised to capture when implementing)
    – The additional work (IMHO) of making sense of every possible data point

    If the additional data you’d capture is of such value, it might make sense. But arguably, if you wouldn’t have bothered tagging it, can it really have been that important to justify that work (which you would be doing forever, so you’d need one of those hidden, valuable gems frequently – a one-off likely wouldn’t tip the ROI equation.)

    There’s also the bias argument. The argument is that tagging requirements are biased, but seems to assume that organisation of the data would be totally unbiased. I would argue that anything that involves humans is going to have bias. It’s simply how our brains work.

    I have actually worked with a number of custom GA implementations that literally tracked everything. (Every single click, every outbound link, every button, even the XY co-ordinate of the mouse location when the click was made!) And yes, there was nothing we couldn’t get insight into, but it was a mess to sort out, because we were completely at the whim of the developer who named elements on the page, etc. I understand the point of “Well that’s when you would take the data and clean it up to be more readable” but that’s the large effort I refer to above, that I’m just not sure is outweighed by the value of the additional data.

    This really has me thinking and I’m definitely curious to see how the industry evolves. It certainly will, I’m just not sure it’s an all-or-nothing. My guess is, we will evolve to somewhere in the middle of the current scenario and what you are proposing. Thanks for the food for thought :-)

    • toddbdac


      Michele! Thank you for your food for thought on my food for thought!

      I completely agree that there is a cost analysis that needs to be done, and for many it is a non-starter. There are those who operate well under the conditions we are currently in. There are others who are in a constant cycle of waste, where the effort would be better spent training developers on naming conventions conducive to downstream analysis… and on that downstream analysis. Then there are many in the middle… most will be fine with what they have (insert hated pie chart showing most folks being fine with what they have, which is GA), but some will find that alternative platforms can make more sense to both traditional marketing analytics teams, and burgeoning data science teams… reducing some overhead and risk involved in what many experience during implementation cycles, bringing more detailed data around their customers or visitors than they’d otherwise be able to tie into the rest of their data.

      My favorite side benefit of the methodology is that it has the potential to reinforce good conventions for analytics in development. The “web analytics implementation” effort is not really obliterated, it is transferred.

      The time will be not right for the mainstream web until Google introduces it in 2015 (just a guess!) … but there are already app development platforms that require no layer of analytics development to capture everything.

      I know that we can learn from things that we don’t even think about collecting today. The organization, most importantly, has to be set up to make use of the data in order for it to matter, and many aren’t and perhaps shouldn’t be (all goes back to your dirty ROI statement)… but regardless, I think we will see the technology move ahead of us, and we’ll be capturing everything before we’re done with tagging, etc. I’m looking forward to the ride!