When to Use the Omniture API

Let’s face it, building an API application isn’t like making a SiteCatalyst request and it isn’t like creating an Excel integration. When you use the API, you are writing a real program. And with the API come all the baggage associated with software development - the attendant hassles, risks and problems. Testing, maintenance, debugging, and reliability suddenly become very real issues when you create an API application – not to mention cost.

It’s one thing if you are a vendor like Semphonic and you can potentially leverage an application across multiple clients. That may make the rewards more likely to be commensurate with the hassles and risks. But if you are an enterprise, you may not get the same leverage from an application. And not every decision about what and how to tackle a problem is made all that rationally. I’ve seen plenty of cases where IT teams pursued solutions like the API to address some problem mainly because the developers wanted to. I’ve seen plenty cases where Semphonic did the same thing because I wanted to.

There’s no sense pretending that every decision we make is going to be rational - but if you're a Project Manager evaluating different approaches to solving some measurement problem, there are a few simple things to keep in mind:

• Any software development is a significant investment.
• The hardest application is the first one - if your staff has experience with the API it's much more likely to go smoothly and it's much more likely that their scoping will be accurate.
• For a first application, understand that many small issues are likely to slow development. Things like making an initial connection can take a long time when developers are first trying them.
• On the whole, the Omniture API is a pretty straightforward system to use - once you've got that initial application under your belt additional apps may be quite inexpensive to roll-out

What all this adds up to is that if you have only one likely need for the API, then it had better be a doozy because the first application is always the hardest and most expensive. If you have a couple reasonable uses for the API, it's much more likely that the time you invest in development learning will be paid back. But make sure you give your development team plenty of time to work out the kinks the first time through.

As a simple rule of thumb (and it is nothing more than that), I’d discourage organizations from tackling a single API application – even a really simple one – unless the payback to the organization in time saved or analysis gained is at least on the order of 20K or so. It’s not that you’d necessarily spend 20k writing a really simple Omniture API application. It’s just that by the time you get done with the all the likely problems, risks, training issues, Token system accounting hassles, and general frustration you should expect with ANY application, you better we getting at least that much in payback to make it plausibly worthwhile.

I'm pulling that 20K number out of black-hat - I know it's a really rough rule of thumb. And it doesn’t mean that any application that drives 20K or more in value is worth doing, because some applications will take much, much more effort than that to build. I just mean it to give you some guidance as to the minimum level of baggage you should expect with any API project.

Also keep in mind that you shouldn’t be trying to re-create SiteCatalyst with the API. If you are an enterprise and you’re thinking that your API application should do more than one thing, you’re probably not thinking about it right. You’re looking for a small, point application that, if you implement it, will save or make you a decent amount of money.

What’s likely to fit the bill?

I think the single most likely class of systems to make sense for an enterprise to custom develop are those where you are already moving (or know you’d really like to move) web analytics data to another system on either a very regular basis or on an event driven basis.

There are three common reasons why this happens. In most large enterprises, web analytics data gets more and more combined the higher-up and the more widely it moves across an organization. It gets blended with additional data from other online systems, offline marketing efforts, operational systems, call-center systems, budgets and plan data, and more. Combining that data can take a fair amount of human cycles – often fairly expensive human cycles. If you can move that data pretty easily and make it automatic, you can create a classic IT automation benefit within the organization.

Web Analytics data can also be used to drive real-world operational decisions on the web site and elsewhere. Automating information transfers of this sort can make it possible to support information driven decisions that simply wouldn’t be possible otherwise. You may want to change your offer strategy on the web based on what happened the day before. True, you could buy some fancy technology to do that, but you could also build a fairly straightforward “point” solution that used the API to drive a specific optimization.

Finally, and I think this will turn out to be one of the more common uses for the API, you may need to drive information out to partners. There are a surprising number of web sites that support large numbers of partners. Music sites, templatized professional services sites (dentists, doctors,etc.), franchise sites, many media sites, ponzi schemes…, well you get the idea. Supporting partner reporting in Omniture using Excel integration can be royal pain. The basic tools simply aren’t there to easily automate and support lots of partners with a customized, turnkey reporting solution. But the API could make such a solution very practical.

You’ll notice that I haven’t really listed any big uses for the API that are very analytical.

There are two big reasons for that. First, the API doesn’t give you access to information that you can’t already get from SiteCatalyst or Discover – so it doesn’t open up lots of new applications the way getting the Omniture Data Feed does. It’s also my sense that most analytic opportunities aren’t all the repeatable – and you’d rarely get enough of a bang from a single use of the API to make it worthwhile.

Automation savings in both time and money are exactly the kind of thing companies are looking for these days. If you can find a way to reduce human cycles copying, moving or distributing web analytics information, you've got a potential winner of an API application. There are even companies who have built up significant warehousing infrastructure to help create or distribute partner reports. With the Omniture API, you may have opportunity to bring that functionality back into the web analytics tool and save yourself a good bit of money!

Summing Up
The Omniture API may be a bigger win for companies like Semphonic than it will prove to be for the average enterprise. Perhaps companies like ours will be able drive real value with small applications that do thing SiteCatalyst and Discover just don't. But the API does open up some real opportunities for automation, data-driven decisioning and partner reporting at the enterprise-level that really haven’t existed until now. If any of those opportunities seem to fit your organization, I’d encourage you to give the API a serious look. After a slow and somewhat rocky start, it’s become a much more robust tool and Omniture seems strongly committed to its ongoing development. If they nail the Token system, I have high hopes that the Omniture API will become an integral part of our web analytics arsenal.

I know that this is a highly technical topic and this series as barely scratched the surface of what you might use the API for and how you go about building API applications. If you have questions about the API or would like to find out if Semphonic can help you build or design an application, drop me line...

Comments

[Adam Crutchfield]

Awesome post. My company is in the midst of beginning the report automation process design and its proving to be a daunting task. But, as you stated for a large organization it will be worth the time analysts like myself will save as well as the quick insight the upper-management can constantly get to change or re-adjust strategies. I wish there was more information or an example for how to code it all though.

[Local Builders]

Agree with Adam here. Awesome post. Unlike Adam though I think you've convinced me that the time and money simply isn't going to be worth the effort and integration. Thanks again for the great post

[Gunjan]

Great Post!!! I am about to start on project of data extraction through Omniture API.

[Phil]

Well written, Thanks for breaking it down for an ordinary fox like me to understand it. I have more understanding of API now than when I read on wikipedia.