SemAngel

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...

Building an Omniture API Application

At last year’s Omniture Summit – yes the 2008 version – one of the most interesting announcements was the release of a Reporting API for SiteCatalyst. Like red wine, technology announcements generally require a certain amount of time to age into a respectable level of maturity and the Omniture Reporting API was no exception. But late last year, after playing on-and-off with the API, we at Semphonic decided it had reached a level of maturity where it could be successfully used.  It’s early days – the API is still beta and its deployment model still a little fuzzy – but you can work with it reliably and produce interesting products.  In my first blog on this topic, I provided an overview of what an API is and some basic information on the Omniture APIs. In the second and third posts, I took up the topic of the Token System (which controls how much you can use the API and how expensive it is). In today’s post, I’m going to talk about the basic elements of an API application. I’m going to wrap up next week with some thoughts on when using the API is likely to be a good option for your business.

Today’s post is going to be moderately technical – but I’m going to try and keep the discussion appropriate for non-programmers. What I want to do is give you a feel for how the API works and what it can accomplish.

First, it’s important to realize that the Omniture API is really six or seven different APIs. The oldest, and in some ways least developed is the Data Insertion API. This API is really just a method of sending XML post requests to Omniture in lieu of firing a tag. It can be pretty handy in certain circumstances, but it’s really not even appropriate to call it an API. The other APIs fall into three basic buckets: administration, job submittal, and reporting.

The administration API is quite full featured and allows you to both access and update pretty much any administrative setting that is available in SiteCatalyst. Why would this be useful? Well, if you are working with a large number of report suites, it can be time-consuming to check or set an attribute on many tens, hundreds or even thousands of report suites. If you need to do that, it’s probably worth investing the effort into an application that will do it for you.

The job submittal APIs are interfaces into the data warehouse and SAINT. They provide a mechanism for you to create and check on data warehouse requests or to create and submit SAINT requests. These job submittal APIs are very simple – often having only a few methods and relatively little potential for customization.

The reporting APIs are the richest and most interesting. There is the base Reporting API (which is what I’m going to talk about today) and there is another, fairly similar, API for Discover. These APIs provide access to most of the same data you’d be able to access – respectively - with SiteCatalyst or Discover.

Using the Reporting API typically involves six major steps:

I’m going to quickly cover each.

Authentication is the process by which you tell Omniture via the API who you are and prove that you have a right to access the information. You don’t use your standard login to authenticate with the API. You have to be setup in SiteCatalyst as an API user and you must use SiteCatalyst to generate a SecretWord that you will attach to your requests. There’s nothing particularly unusual or difficult about this. A word of warning, however. The authentication model Omniture has chosen is quite a bit more complex than many other web service APIs and is not well supported in Windows. So if you are a Windows shop (which Semphonic is), instead of trying to figure it out yourself, I strongly urge you to use the Sample Code that is provided on the Developer Web Site. I’d recommend the Daily Time Parting App as a good starting point for authentication code.

Request Definition is the next step and it’s one of the most important. This is a place where it really helps to have some good SiteCatalyst knowledge to complement your programming staff. The Report Definition phase works very much like SiteCatalyst (almost identically when it comes to understanding what metrics are available, how trended reports work, stuff like that) – but instead of having multiple types of reports (one for paid search, one for natural search, one for referring sites, etc.), there are only a few basic types (ranked, trended) which you flesh out by specifying which metrics you want. It’s really a nice way to manage the system, and it makes report definition pretty straightforward.

Here’s a tiny snippet of Sample Code that will get the visit count for a Paid Search Report:

// Start Report Definition
           reportDescription rd = new reportDescription();
// Set the Date Range
            rd.dateFrom = oDate.StartDate;
            rd.dateTo = oDate.StopDate;
// Set the Report Suite
            rd.reportSuiteID = reportSuiteID;

// Create a list of reporting elements
   reportDefinitionElement[] rdDefElements = new reportDefinitionElement[1];
// Set what type of report we want – in this case searchenginePaid
            rdDefElements[0] = new reportDefinitionElement();
            rdDefElements[0].id = "searchEnginePaid";
// Set how many rows we want returned and where to start
            rdDefElements[0].top = 200;
            rdDefElements[0].startingWith = 1;
// Now set what we want back
            reportDefinitionMetric[] metrics = new reportDefinitionMetric[1];
            metrics[0] = new reportDefinitionMetric();
// In this case, visits
            metrics[0].id = "visits";
            rd.metrics = metrics;
// Add the list of elements to the report
            rd.elements = rdDefElements;

That’s pretty much it. This will request the top 200 elements in the Paid Search Engine report and return a visit count for each.

Once you’ve built a report definition, you send it to Omniture. You have a choice of methods here depending on whether you want to just wait for the report or you want to queue it. Normally, you’ll always want to queue reports so you don’t completely lock up the interface. And requests can take a bit of time to process. On the whole, it’s not much different (though a bit slower) than doing the same actions in SiteCatalyst.

Here’s a sample:

   

//request the report

            reportQueueResponse response = ws.ReportQueueRanked(rd);

Once you’ve submitted a request, you need wait and periodically check for it to finish. I wrote about a big gothcha in this process in my last post – and I’ll just leave you to check out the code samples given there.

Once the report is ready, you get the returned results. It’s really just one line of code that gets the results for a specific report (based on the reportID). Remember not to call this request until you’ve made sure that the report is actually ready by checking its status:

reportR = ws.ReportGetReport(response.reportID);

Finally, you can loop through the returned data and process it or save it as you desire. Here’s a bit of sample code that shows this process for the Paid Search visit count report defined above:

// We are going to loop through the returned data and process every row
            for (int i = 0; i < reportR.report.data.Length; i++)
            {
// This field will contain the dimension name - here the Paid Search Engine
                metricval = reportR.report.data[i].name;
// This field will contain the metric - here the visit count
                visitCount = reportR.report.data[i].counts[0];
// Here we save these values in our own array for processing
                rS.addValue(metricval, (int)visitCount);
            }

Once you’ve gotten all the results, you can do whatever else you need to do with them. One of the big advantages of an API application kicks in at this point. You can start to really apply matching and logic to the results you get back. Using the Excel Integration, we often build reports that match the key dimension (like referring site or search keyword) to it’s values over time. But while Excel has functions that facilitate this, they are a bit clumsy and can’t handle any fancy wildcard matching and don’t let you do much logic around what to do with unmatched or multi-matched records. In a program, you can handle such issues easily – making it possible to produce much more robust reports.

You can also add in additional information from other sources without having any manual steps. And, of course, you can do fancier logic than would be practical in Excel.

At Semphonic, we’ve been working on taking our Excel Traffic Models and using the API to source them. The Traffic Model looks at many different possible sources of traffic (referrals, direct repeats, direct new, PPC, SEO, campaigns, etc.) and analyzes how they are changing over time.

One of the really nice aspects of using the API is that the model can incorporate predictive models (the red line in the chart below which is based on seasonalality) and measures of statistical significance. Note that two of the identified changes in the model are tagged as not being significant given the level of variation observed in that particular measure:

 

We call this style of reporting Analytic reporting because it is designed to build our analytic models directly into the reporting. The idea is to make sure that the report consumer is only shown what’s important and is protected from making many of the interpretation mistakes that are all-too-common in web analytics.

The API is a great vehicle for this type of reporting. By saving all of the information taken from each request, the model is instantly displayed when the time period has been run previously. And since previous months are saved, only new API requests are issued. This also makes it faster than most of our Excel models where we usually end up just re-generating the entire report. And, of course, the level of potential customization is much higher. In addition, the model can be seamlessly pointed at different report suites. You don't have to redo your Excel requests for each site.

Naturally, this comes with a price. It’s still quite a bit harder for us to customize an API application than an Excel worksheet. Over time, as we build up a library of code, I expect that difference to narrow. And the API is not free – which hearkens back to the issues in my previous post on the Token system. But the opportunity for going creative and powerful applications is definitely there.
In my next (and final) post on the API, I’m going to try and give you a sense of when it would be appropriate to use the API and how much work you should expect it to be.

Avoiding the Great Token Gotcha : More on the Omniture API

In my next post, I’m going to dive down and talk in more detail how the API actually works and show pieces of a real application.

But before I go there, I wanted to touch one more time on tokens and give any programmers out there a heads-up on the “Great Token Gotcha.”

In my last post, I described Omniture’s token system – the basic metering systems that controls how many API requests you can make and how they cost. In essence, each API request you make costs you a token. And to use the reporting API, you have to submit a request and then you have to get the report. So you typically use two tokens per request.

Simple?

It is, but there is a big gotcha out there.

Here’s how it works.

To make a request to the API, you build up a report object that tells Omniture what data you want to retrieve and what time period you are looking for. When you’ve defined everything, you submit your report.

So far so good.

Now here comes the tricky part. Most Omniture Sample code works the same way. After the request is submitted, you go into a wait loop. You pause your program for a second or two, request the report object to see if it’s finished. If it’s done, you are good to go. If it’s not done, you wait for another second or two and check again.

Here’s some heavily commented code (this whole post is really for programmers so feel free to skip if your interest in the API is more on the business site):

//request the report
reportQueueResponse response = glob.ws.ReportQueueRanked(rd);

// Wait for 1000 milliseconds or 1 second
System.Threading.Thread.Sleep(1000);

// Grab report
reportResponse reportR = glob.ws.ReportGetReport(response.reportID);

// If the report is not ready then wait and check to see if it is ready
while (reportR.status != "done")
{
// Wait another second
            System.Threading.Thread.Sleep(1000);
// Check the report again
      reportR = glob.ws.ReportGetReport(response.reportID)

// Keep checking (go back to the while until the reportR.status is done
}

This is a simple, obvious way to manage your code. There are others, but this is the way most of the Omniture examples on their dev site are built and it makes perfect sense.

It’s also terribly wrong and the reason isn’t programmatic. What is hidden in the system is that Omniture will dock you a token for each and every time you make the:

      reportR = glob.ws.ReportGetReport(response.reportID);

request to see if the report is ready. Yes, you will be charged a token! And since reports often take ten, fifteen, even forty seconds to run, you can burn up your entire token allowance of 2000 a month with just a few short requests. And, of course, the irony of this is that the worse Omniture’s system is performing, the more expensive the system is. It’s brutal, and until we realized that this call docked us a token, we were in constant danger on every request of running out of tokens and having to cease development for a month.

Is there another way?

Indeed there is, but I’m not sure everyone always realizes the difference - I know I didn't.

Instead of the GetReport call, you need to make the GetStatus call – this will return the status of the report without dinging you a token. This call didn’t even exist in earlier versions of the API – so it’s easy to overlook or to miss its significance!

So if you’ve been using (or are about to use) the API, and you didn’t realize this little problem, I believe I’ve saved you a world of grief and confusion – at least if my own experiences are any guide. And I’m pretty sure that this little gotcha is responsible for a good deal of the confusion surrounding token policies and the reason many programmers believe that each request to the API uses multiple tokens depending on how complex it is. That’s sure what it looks like until you realize that it’s requesting the report (not running it) that you are being dinged for!

In my next post on the API, I’m going to describe the basics of building an API application and show some samples of our work to give you a feel for what can be done.

The Omniture API : A Token for Your Thoughts

I was going to blog on the Omniture Reporting API and how it works, but since Omniture’s Chris Wareham took up and commented on the topic of token’s that I mentioned in passing (as the biggest issue with the API), I thought I’d skip ahead and tackle that directly. When I attended the break-out session on the API at the Omniture Summit, virtually every question asked was about the Token system. And when the winner of Omniture’s API Development Contest bravely demoed her program live, she first remarked: “I hope I’m not out of tokens!” In this post, I’m going to explain why tokens are such a big topic right now and where (I hope) Omniture is heading with them.

So what is a token?

Tokens are the currency of usage in the Omniture API. Each request you make has a certain token cost. When you are out of tokens, you need to buy more. Token systems are common as a metering device on APIs to prevent out-of-control usage. And metering is necessary for an API because while it’s possible that some measurement monk could sit in front of SiteCatalyst all day and bang out request after request, it’s fairly unlikely. And even a true measurement black-belt couldn’t possibly pump out a thousandth of the requests that a computer program could easily make.

So while tokens are probably a necessary part of life, Token systems range from the extremely generous to the quite onerous.

Here’s Chris Wareham describing how the Omniture Token system works:

“To get started, each login company gets 2000 monthly tokens for free. Omniture customers can contact their account representatives to purchase more if needed. Those 2000 tokens are 'use them or lose them' on a monthly basis; we don't currently offer 'rollover' tokens, but it's something we're looking at.

In terms of API consumption, whenever a single API "call" is made to Omniture's Reporting, Admin, SAINT, Discover, Data Warehouse, or Data Sources APIs, 1 token is charged. Most generic *Reporting API* requests will require 2 tokens; queueing the request for the data will consume 1 token, and the receipt of the data itself will consume 1 token.

In our other APIs, most transactions will consume only 1 token. As we enrich the kinds of data available via the APIs, it's possible that we'll increase the token charge for certain calls, but for now each single API call consumes only 1 token.”

This is a pretty clear statement of how tokens are assessed. But it does still leave quite a few questions unanswered.

Since each company gets 2000 free tokens, then you could run 1000 requests a month on the API before you had to pay anything.

That seems fairly generous – 1000 reports feels like a lot of reports. But that isn’t exactly the way things always work out. Let me give you an example.

Semphonic has been developing a Traffic Model using the API. We currently run the Traffic Model using Excel Integration (for free no matter how many times it’s refreshed or against however many report suites it’s run). The Traffic Model looks at sources of Traffic over a 6 month period of time and what’s driving change. To do this, it needs to request six months of referring site traffic. Each month needs to be a separate request given the way the API is structured. That means 6 Referring Traffic Requests x 2 Tokens each for 12 tokens. But we don’t just use Referring Site reports for the Traffic Model. We also have to request the Campaign Report, the Natural Search Keywords Report and the Paid Search Keywords Report. So that comes to (6x2)+(6x2)+(6x2)+(6x2) or 48 tokens.

So every time I want to run single a Traffic Model I will expend roughly 50 tokens. That means I could run 40 traffic models a month before I had to start paying. Reasonable? Maybe, except that if you are an organization with 50 report suites, you could not run even a single Traffic Model against each report suite before you had to pay since tokens are company not report suite specific. That starts to feel pretty onerous - especially when compared to Excel Integration where our clients routinely exceed this load.

But if the number of free tokens currently allocated feels a bit small, there’s a much more serious problem with the Token system and it’s a simple and obvious one. Uncertainty.

All currency systems rely on a basic understanding that you can control how much you spend because you can control your own usage and you understand the price. With that in mind, here are the basic questions I asked Chris at Omniture:

1.    Is there a published price for tokens (if so what is it)?
2.    Is there a discount for buying in bulk?
3.    Is the price committed to for some period of time?
4.    Are tokens that you purchase additionally also on a one month expiry? If not, how do you know when they’ll expire?
5.    Can tokens be purchased by an application vendor instead of a client? Will there be a mechanism for an application vendor to use their tokens on a client report suite?

Knowing the answer to these questions is essential before it would make sense for a company like Semphonic to commit significant resources to a software development project using the API. In fact, knowing the answer is actually more important than the exact nature of the answer. Depending on the price of tokens, I might decide that only applications with relatively high-value to the client or that chew up very few requests actually make sense. But I can’t decide that unless I know the true price.

Omniture does have formal pricing for API consumption, but you need to contact your rep to get it.

On the other hand, that price isn’t fixed in stone right now and there’s a pretty high likelihood of it changing. Ditto for issues like expiry, where Omniture would like the certainty of token usage for expiry planning but customers would prefer the simplicity of an unlimited time horizon. So you can get a price right now (you just have to ask your Rep) – but it’s hard to know if that’s a price you can or should commit to.

Omniture’s current model is focused on charging the customer for API consumption (they haven’t opened the API up for pure 3rd party developers yet; you need a SiteCatalyst login to be able to get documentation and configure and access to the APIs).  If they really want to see this grow, they’re going to have to figure out a way for 3rd party application vendors to purchase tokens that can be used to run a service without having the end-customer’s tokens consumed.

Until pretty recently, none of this has been a very big issue. It’s only in the last few months that the API has become robust enough and well enough supported to make development tempting. But now, there simply is no bigger issue than price. Regardless of whether you’re a potential vendor (like Semphonic) or an Omniture client looking to automate reporting tasks, investing in software development when you don’t have a firm grasp of the cost is just too risky.

So here’s what I’d like to see from the Token system in addition to the much needed and already promised Developers Test Environment (Sandbox).

First and most important, I’d like to see cost certainty. The simple fact is that any known cost is better than uncertainty – at least with a known cost I can decide if an application makes sense for my clients or not. This is a psychological barrier more than anything else. Omniture just needs to let people know when or if the price is nailed in stone. If that’s already been done and the current price is what we should expect going forward, then it’s simply a matter of communication. If it hasn’t, then deciding on and nailing that price in stone should be the top priority for the API.

Personally, I think Omniture should not just set but publish (this really is a different case from standard contracts) the prices for tokens in various bulk quantities. I also think that Omniture needs to commit to that price for some fairly significant period of time. Transparency – whatever the cost – is the ultimate goal.

What else would I like Omniture to do?

This is minor, but I would eliminate the token cost for queuing and getting data. That just makes token usage harder to calculate and provides no real benefit to anyone. Why would you queue a request and not get it? I’d do a flat-rate for queuing or making an asynch request.

Second, I would significantly increase the number of free tokens and/or make tokens report suite specific. The goal should be to prevent abuse not discourage use. For many token systems, the enforcement mechanism is a daily meter or a time-based throttle. With a daily meter, you get X requests a day you can’t exceed. This lets you do regular tasks without worrying about exceeding total thresholds and without stressing the system. Another common technique is a time-based throttle that simply slows your requests if you are making too many. This can be hard to work with since it means unknown performance hits in the application (especially since someone else’s application may be causing the problem) – but at least it provides cost certainty and stress protection. The best system isn’t obvious and there are always trade-offs. If I had my druthers (other than totally free and I know that’s not happening), I’d opt for a system with a free daily meter and the ability to purchase up to higher-level plans on the daily meter. When requests exceeded the daily meter, I’d throttle them instead of killing them. A system like this would encourage numerous small simple apps that would essentially be free to deploy. It would also make reasonable pricing for more commercial efforts practical. As a part of this, I think that the API should allow for the direct purchase of tokens – so that a properly authorized application can actually allocate additional tokens in real-time.

Third, I would build a mechanism whereby software developers could use their own tokens for client requests and manage billing/metering on their own. This way, clients who buy my application wouldn’t have to manage a separate billing process with Omniture. As I mentioned, this alone would kill most deals for any inexpensive tools (and inexpensive tools are what makes the most sense for the API). This may not be high on most Omniture client wishlists, but as a potential vendor its right up there with cost transparency as an essential requirement.

Fourth and last, I would make sure tokens don’t expire since it makes the purchase process extraordinarily complex. I just can’t ask clients to purchase tokens every month to run my application and Bill’s application and Joe’s application and not have them know, at any given moment, how many tokens they will have on March 21st as opposed to March 22nd or April 1st. Even if I was running an internal system, I’d be afraid that half my software development effort would be dedicated to token management.

In a way, it’s a good thing that the Token System has become important to the API. It means the API has reached a level of maturity where serious use can be made of it. I’m hoping that Omniture will nail out the Token system in short-order and that it will be a system that truly encourages development. I know from my perspective, I’d love to be a part of that.

And I’d like to give a special thanks to Chris for taking the time to answer my questions and for pushing in the right directions!

Waiting for Answers and Thinking Outside the Box

I was going to blog on the Omniture API Token system this week (and I did write a draft) but I decided it would make more sense to give Omniture’s Chris Wareham a chance to answer my questions before I bothered to post them. I figured that would spare you having to read my questions and then Omniture’s answers as a comment since I could just consolidate them into a (I hope informative) post.

But that means I have to wait for answers, and I can hardly expect them on a Sunday afternoon. So instead I’ll just mention a blog by CableOrganizer’s Paul Holstein that I read with particular interest. Paul is an unusually interesting thinker –his perspectives are always his own – never just the standard “off-the-shelf” ideas enjoying a moment of currency.

In his post, Paul dismantles the idea that single-minded pursuit of goals is necessarily a good business strategy and his argument echoes ones I have made many times concerning the undesirability of treating individual KPIs as immediately actionable. That may not be too surprising since many of my ideas on the subject crystallized and grew out of a conversation with Paul.

The world is not a simple place and when we try to make it so, we tend to trivialize it.

I doubt that Paul or I will ever write a pithy, self-help business book (well, I’ll probably never write ANYTHING pithy). But the world should not regret the lack.

The blog is well worth reading – check it out!