Search Engine APIs – Corporate Culture Runs Deep
|
Written By Reprise Media | May 16, 2006 | Share This
|
|
In the last year, we in the technology team at Reprise Media have integrated with more than 15 different search engine APIs as part of our campaign management platform development. Since we interact with the engine APIs holistically across the entire lifecycle of a campaign (from campaign creation and creative management, through reporting and optimization and finally to tear-down), and not just for simple bid-management, we have had somewhat of a unique opportunity to compare them and assess their relative strengths and weaknesses. An interesting take-away has been how prevalent corporate cultures are reflected in the software APIs the engines produce.
Take for example Google. Externally and justifiably, Google is perceived as a lot of really smart people writing really smart algorithms. Kind of like a graduate school full of search experts. (Although, when I was in graduate school none of us were Porsche-driving millionaires). The Google API brings to mind university software. Yes, it is an XML Web Service, definitely the current state-of-the-art technology with which to build an API. Yes, it provides all of the core functionality of the human web-based interface. And yes, they definitely have a cross platform mentality (examples come in PHP, Java, .NET, etc). However, documentation is sparse and reliability is…well…more on that later.
Then take Yahoo. I remember when I was Chief Architect at Lycos reading someone describe the Yahoo platform as “Messy-ware”. It was all homebrew technology derived originally from the FreeBSD UNIX platform and Apache Web Server (if I recall correctly). Apparently, all of the Yahoo features were in-house developed and custom built to task. Messy-ware is also how I would describe their API (editorial note: a new version was just released last week, so I’ll have to revisit this). It’s kind of a web service, but no WSDL (a high level specification language for web services) describing the interfaces and enabling third-party tools. It is a homebrew soup of XML-over-HTTP. Yes, you get a schema for each message, but you have to figure out how to encode and decode it yourself. Documentation consists of a single huge Acrobat pdf file that is maybe a little uneven in detail and lacking a good tutorial on the system’s architecture and use cases.
What about MSN? They know a little about APIs, right? To say that MSN drinks the Microsoft Kool-Aid regarding .NET and XML web services would not be an inaccurate statement. The version we worked with over the last couple of months has its glitches, but, as a framework, it was definitely developed by people who understand enterprise software. It does have a pretty ruthless allegiance to .NET (they might as well just send you Visual Studio .NET projects), but it obeys the standards enough for other platforms to interoperate. Documentation is outstanding. Complete with tutorials, examples, schemas, WSDL files, etc. More people probably wrote the documentation that wrote the entire system for some of the smaller engines.
On that note… the other engines. Ahhh… the best I can say is “thanks for playing and we hope you enjoy the home game”. Things in the third-tier (as we like to call them internally) range from obscure (“Messyware” would be a step up), to down right absurd (“undergraduate software” would be complimentary). I guess it wouldn’t be fair to not at least tip the hat to Looksmart. They came a long way with their recent 2.0 upgrade. The other smaller players should follow their lead. Generally, the “other” engines are functional but really bare bones. The APIs often amount to nothing more than an automated way of sending an Excel spread sheet describing your campaign. What you get in terms of performance data similarly lacks structure.
To get serious for a moment, there are a few overall observations worth making.
First, we are seeing a convergence in the functionality and services provided by the big players. MSN and Google look surprisingly alike. This probably isn’t a coincidence as MSN is likely looking to make it easy to move Google campaigns to MSN. The new revision of Yahoo (for which we just got the documentation) falls pretty much inline with the model Google and MSN are using. Maybe it is time for a standard? SEM-XML or SearchML anyone? What’s SEMPO up to these days?
Second, one thing that the engines could universally work on is reliability. Across the board, they are spotty about reliably delivering accurate data. It is not unusual to get different answers depending on when you pull data and not uncommon to get no answer at all. Even worse, you sometimes get partial data without an indication that it is partial. Making matters worse is that none of them have a mechanism in place to find out when things change and what changed. It makes producing accurate weekly/monthly reports for clients a pain and daily reporting a downright nightmare.
Third, we need more timely data. Availability of reporting data ranges from 24 hours to 3 days later (yes, I’m looking at you Ask.com). People talking about day-parting are getting ahead of themselves if they expect to have (near) real-time data to make real time decisions about creative optimization, etc.
Finally, my own pet-peeve…Quit charging me for my own damn data! Why do I have to pay you to use the API to set up a campaign and the later get my performance data out of your system? Aren’t I already paying you? It reminds me of the banks charging a fee for ATMs. Don’t the ATMs save them money by not hiring more tellers? Similarly, it would seem good APIs allow advertisers and agencies to run more campaigns more efficiently. Sounds like a good thing to me…
Vince Russo is Chief Technology Officer at Reprise Media
Topics: Featured Item, Google, Google: AdWords, Microsoft, Yahoo! |
You should look at this:
code-DOT-google-DOT-com/apis/ajaxsearch/