There have been a lot of search engine optimization-related session recaps in the past few days, but this time we get a pay per click one. Look excited. Or at least awake.
Anne Kennedy is moderating this morning’s Search APIs session with panelists David Flesh (SEMDirector), Dan Boberg (Yahoo!), Julienne Thompson Hood (Advertising.com) and Jon Diorio (Google).
First up is Jon Diorio to talk about the AdWords API.
The AdWords API enables four main areas of functionality: Account management, campaign management, reporting, and traffic estimation.
By using the AdWords API, users are able to manage more accounts and campaigns faster with fewer people, and can more accurately manage the processes that require frequent and/or massive changes.
Other benefits include being able to automate the regular generation and retrieval of custom reports, automate cumbersome bid management processes, automate complex inventory control processes that pause campaigns, as well as the generation and expansion of keyword lists.
The AdWords API was launched in 2005 and was designed to be a do-it-yourself program. There are plenty of readily available resources like a developer’s guide, developer’s sandbox, AdWords API blog/forum/email notification list, FAQ, sample code and SOAP Toolkits.
They offer 9 different services including campaign service, AdGroup service, Traffic estimation, report service, criterion service, ad service, info service, keyword tool service and one more that I missed. Sorry.
Batches of new information are released every few months. They balance the need for new functions with the overhead of frequent release, meaning they stagger releases so they’re not coming out every week. The goal is to reach feature parity with the Web front-end. Older versions of the API are maintained for four months after the latest version is released. Version "diff" information is available via Release Notes.
The AdWords API utilizes a unit-based system. Each operation performed on an AdWords account consumes a certain number of API units.
While some types of operations may consume a single unit, others may consume more. On a regular basis, each developer will be billed $.25 per thousand API units consumed. Note that some advertisers who develop proprietary applications to promote their own businesses may be eligible for limited free quote allocations.
To get started, head to google.com/apis/adwords. You’ll need a My Client Center login and password.
Next is Dan Boberg from Yahoo.
He starts off talking about the Yahoo Developer Network, which includes a host of services for users to take advantage of. You can find REST-based services, desktop-based environments, RSS feeds, presentation libraries, developer centers, applications gallery and events.
Current YSM API Programs:
Advertiser Program: Supports advertisers in integrating their system with YSM marketplace.
Developer Program: Open access and online support to encourage creation of innovation new applications.
Commercial Program: Enterprise Class support for 3rd parties that have built a business on the Yahoo platform.
New YSM Commercial Program: Completely rebuilt to be robust, reliable and scaleable. It’s designed to meet the needs for developers, agencies, and technologies companies at any stage in their life cycle. There are no fees for API access. It’s an open and transparent program with commercial-grade technical and marketing support and a massively scalable production platform.
Programs goals include innovation, accelerating commercial success and building an ecosystem of mutually beneficial commercial partnerships. The program addresses the specific needs of reliability, scalability and support.
David Flesh is next.
David lists of all the engines that have a claim to APIs, including Ask, Google, LookSmart, Lycos, MSN, Ingenio, Business.com, Yahoo, SortPrice, Miva and others I can’t make out.
The lifecycle of an API is 6-9 months at most. If you want to stay current then you’re looking at a pretty rapid development cycle. If you’re going to adopt an API program, there is a cost involved.
- Upgrade deadlines to new version are too aggressive. Legacy version support doesn’t late long enough.
- There is no common data schema standard across search engines.
- Organic API data is either non-existent or offers little value to sophisticated SEO/SEM companies.
- Occasional inconsistencies between cost data reported through the APIs and what is billed to the client.
- Challenges to metrics that are reported are not called out in the API, therefore it comes necessary to implement checksums to make sure historical values are consistent from week to week.
- Large clients = large polling efforts = quota usage
- Ability to increase quota limits is cumbersome and reactive.
- Lack of special character support from some APIs strip out meaningful data required by clients.
- Deleted campaigns are not always noted. Matching performance metrics with account structure is difficult.
In terms of documentation and support, it exists but unique needs are slow to be addressed. Inquiries to reps are ignored, passed off.
[All the lights just went off. Heh.
Okay, they’re back on now.]
Roadmap requests: Organic search APIs, increased quota limits, provide percentage of clicks seen at varying average position, provide the number of queries for keyword, more detailed demographic data, improve Sandbox capabilities.
Going forward with APIs in the future we need industry driven and vendor agnostic standards with common metrics. There should be common ontology or schema to present a unified approach to describing the data.
Last but not least is Julienne Thompson Hood.
The API provides access 24/7 to information. Campaigns are managed across multiple engines on a portfolio basis. Manual bidding is generally impossible due to a large number of terms. Frequent bid challenges required because of strong TOD, DOW or season trends. Intelligent bidding is necessary to improve ROI.
Julienne listed some best practices for using APIs including designing a multi-tiered architecture for engine integration systems to allow for scale and introduction of new applications; developing core applications that can translate your data into the appropriate format for each search engine; identifying the most important business needs to help you decide which API feature to take advantage of; writing applications to compile and provide meaningful reports on data elements like cost, bid updates, etc; testing new features before implementation and use sandboxes and monitor backward compatibility. Last but not least, utilize user forums to obtain information and answer questions from peers and engine resources.
Search Engine APIs Tips and Tricks:
- Feature parity among engines
- Yearly release among products
- Development lead team
- Data visibility
- API usage costs