What will Google do next with Google Analytics?

So I’m a little late with my obligatory post-E-metrics blog post; my excuse is that I flew straight from San Francisco to Mexico for a vacation, and have just made it back.

A fixed presence at E-metrics summits these days is our good friend, Google – in fact, this year, both Google Analytics and Google Website Optimizer were sponsoring the show (possibly a somewhat inefficient use of marketing dollars, but there you go). In terms of sheer numbers of customers, Google Analytics is the 500 lb gorilla of web analytics, as anyone reading this blog will doubtless know. But where next for the two and a half-year-old wunderkind of web analytics?

One of my favorite things to do at E-metrics is to catch up with friends from the industry, and Google evangelist Avinash Kaushik and I had a very pleasant coffee where we discussed just this topic. Just to be clear, Avinash didn’t reveal anything about Google’s future plans for GA, but it became clear to me (from that discussion and others) that Google is scratching its head a little about how (or whether) to provide GA to enterprise clients (i.e. big companies). A lot of people are expecting it to, but for all GA’s success, it remains a relatively simple analytics package, incapable of the detailed reports that you can pull with Omniture or even Webtrends. And it doesn’t really seem to be in Google’s DNA to provide a very feature-rich application stack like these other companies provide. In many ways they’re the Microsoft Office to Google’s Docs & Spreadsheets. So how to square the circle?

Whilst I was sunning myself in Mexico, I had a chance to reflect on how Google could address this challenge and here are my thoughts. As you know, I like to make predictions, just for the fun of sparking a bit of debate, so feel free to use the comments box to let me know precisely what banned substance it is that I’m smoking.

 

Prediction 1: Google will release a comprehensive mid-tier API for GA

I’m hardly going out on a limb with this prediction – it’s been something that Google-watchers have been crying out for for some time (and some people have taken unilateral action to fix). But most talk about APIs has been to provide a programmatic way of pulling existing GA reports – i.e. a “front-end” API. What I’m talking about here (hence the use of the term “mid-tier”) is an API into GA’s data store that allows pretty much any data set to be extracted to a third-party system and then processed into a report.

Google would have to be very careful not to overwhelm their systems by providing such an API, of course; it would be all too easy to write a call which asked for all the data for a very busy site; but those eventualities could be predicted and prevented fairly easily. Note that I’m also not saying that Google will provide this API for free; there’s no reason that it might not choose to charge for access to such a comprehensive data service.

You might be thinking, why would Google release an Analytics API at all? After all, isn’t the point of GA to encourage people to use Google’s tools to optimize their campaigns, and therefore spend more money with Google? Well, only partially. The main benefit to Google in the deployment of GA is the huge amount of data that it gives them access to. In an API scenario, Google would still control instrumentation of the site and collection of the data, and would therefore still accrue the same benefits from it as they do currently.

Prediction 1a: Related Google products will use the Google Behavior Data API

I’ve decided to give the new API a name – the Google Behavior Data API – to distinguish it from Google Analytics itself.

If they don’t already, Google’s various behavior data-consuming products (principally, Analytics and Website Optimizer) will use the same API for data access. You probably won’t see any visible change in the products as a result of this. This might already have happened behind the scenes.

Prediction 1b: The Google data collection .js tag will become a “universal” tag

If Google opens up the mid-tier of their system, they’ll also (eventually) need to open up the data collection part, making it possible to collect any custom variable or event you want, and subsequently being able to access this through the API. This will require new functionality in the JavaScript tag to support customizable data collection. The importance of this ability will become clear in predictions 2 and 3, below.

 

Prediction 2: The Google Behavior Data API will create a new industry of “third-party” web analytics tools

I’ve railed before against new entrants to the web analytics business, asking what value they can possibly add at this stage in the game. But one of the reasons I’ve been so skeptical in the past is that most of these folks building these kinds of new tools just don’t appreciate how much effort has to go into collecting and storing the data in a format that makes it easy to deliver reports, and easy to expand functionality in the future.

A mid-tier Data API would mean that such companies could rely on Google for all the basic data collection, primary processing and warehousing, and just focus on developing interesting new reports. As long as the underlying platform is flexible, this frees up these companies to innovate at the front-end without having to worry about the back-end.

The upshot of this is that you may see web analytics functionality popping up in all sorts of places that it might not otherwise, especially in the SMB market, such as CMS/blog tools, e-commerce systems, sales automation systems and the like. Some of these systems already provide integration with Google Checkout, for example, so using Google’s Data API for reporting & analytics would be a logical next step.

 

Prediction 3: Eventually, even the big guys will use the Behavior Data API

This is the big one, of course, and the most contentious. Why would a company like Omniture or Webtrends, or CoreMetrics hand over data collection to Google? Omniture, for example, has put a lot of effort behind its Universal Tag architecture, and data is as useful to them (or will be, ultimately) as it is to Google.

One chief reason is switching costs. If an Enterprise web analytics vendor wants to convert a GA customer onto their platform, then offering a “no reinstrumentation” proposition is going to be attractive. It is true that the different beacon code provided by different vendors capture different (unique) things, but there would be value in being able to say to a customer “just give us your API key and we’ll do the rest”, even if it did mean offering a reduced set of reports (although a universal tag with custom variables would offset this issue).

Another reason, however, is cost. It costs web analytics vendors a lot of money to host the servers for data capture and initial processing, and is one of the things that contributes to the rose-tinged bottom line of these companies. It costs Google money too, of course, but Google can probably provision servers more cheaply than anyone else on the planet (except, perhaps, our good selves), and is able to leverage the benefit of having access to the data to offset the cost.

This eventuality also neatly solves the problem of “GA in the enterprise”. With the API in place, Google is free to reach agreements with the bigger web analytics vendors that preserves those v
endors’ positions with their customers whilst allowing GA to get in and get access to the data. “Maverick” implementation of GA by outlying departments of big companies is an increasing problem faced by the major Enterprise vendors. Being able to consume this data in their own tools would decrease the vendors’ need to charge for every last byte of data they’re collecting, and would enable them to say “Sure! Instrument with GA, and you’ll see the aggregate numbers in our tool, too”.

 

So, those are my predictions. Feel free to add yours below.