Shopdiggity.com:  API monitoring for user experience and monetization »

Need to compare prices for a blueray DVD ?  Or baby car seats?

Shopdiggity.com offers a streamlined comparison online shopping experience across hundreds of product categories and brands.

Shopdiggity has a fast, clean UI that makes browsing Shopzilla's massive product catalog more approachable.   It's a great example of an app that adds value and monetizes a publisher API and affiliate marketing program.

Christopher, Shopdiggity's owner, uses Apigee to monitor performance and response times from Shopzilla's API.

Some great feedback from Christopher -  we need to add more email alerts so that developers can respond to changes in API behavior.  For example, if the Shopzilla API has slow response time, an alert would help him adjust ad campaigns to balance between user experience and monetization.

Thanks to Christopher for the great example and the feedback on Apigee.   If anyone has more,  please hit us on Apigee's Get Satisfaction forum.

Show me the money: API Monetization »

(Next in our series on API roadmap considerations and following our last entry on "API business models")

At some point most API product managers are on the hook to demonstrate how the API results in downstream revenue.

And even if you never intend to charge for your API, you may be surprised by unexpected opportunities.

I used to be responsible for a number of ‘free open, take-it-or-leave-it APIs’ at a large Web portal. After a few months, the team was surprised to get a ton of calls from big companies that wanted to pay (a lot) for use of the API within their commercial products. 

One small detail -  they expected that the API could support some of the basic business terms of any commercial deal.  For example – could we:

• Meter service and give them a bill every month?
• Enforce a special rate limit give them an “SLA” (service level agreement)?
• Insert extra data fields if they were willing to pay for more licensed content?

We also needed some other basics:

• SOX compliant audit logs for each deal.
• Reporting on the cost of the data served by the API. (because we were licensing it from another company)
• The means to enforce similar terms on a ‘package’ of multiple APIs together in one deal

Unfortunately, all of these needed to be coded as they came up, so it was a big strain on development, PM and BD to tough to lock down and execute deals in time.

So – even if your API business model is already covered and baked in your API – you may want at least the option to support a slightly tailored or customized relationship.   You may need to quickly tailor the APIs syntax, protocol, priority, or content to a specific opportunity.

Once you have partners using an API, your business managers and partners will put your team under a lot of pressure - dollars are lost each day a business policy change takes to make.

So consider if you’ll ever need to abstract these policies – the difference between the API content and features that and the commercial business and operational terms of each deal – in an a separate API policy layer that you can manage quickly and independently of development cycles.  Or to make a single change across multiple APIs. (here's a case study on an API policy layer.)

Therefore, some questions to ask for your API roadmap might include:

General business and partner model questions:

• How is your business and revenue model supported by your API?  (are you looking for distribution and awareness only? Does the API drive a monetized transaction?  Will you ever charge for ‘pay by the API drink’?)
• How are your costs reflected in your API?  Do you pay for any of the data you are serving up?  If so, how do you keep track of this for the business and partner?
• Will large partners or deals surface where your team will need to change the API content, SLA, protocol or content?   Is there a partner that might want to pay enough and who is large enough to drive your team to move a way from “one size fits all?”
• Will you need to create ‘service tiers”?

Enforcing unique business and operational terms

• How will you meter service like a utility, so that you can bill partners and report data costs?
• What regulatory compliance will you need to support?  Do you need SOX-compliant audit trails by partner?  HIPPA?  PCI?
• How would you create and enforce a partner specific SLA, rate limit, or offer ‘priority access’ to a priority partner?
• If the partner wants any change in the API protocol or content – do you need to support a different API code-base?   Is there a way to create a transformation layer to handle and scale this?
• Do you need to buffer up or queue incoming requests?

Next time: API User management and onboarding

(and thanks to unhinderedbytalent for the photo - check out the detail on the full pic..)

API Business Models and Monetization »

Even with the success of APIs like Twitter, Amazon and Facebook, it can still be a struggle to articulate the value of opening an API to execs and other business folks whose support is needed. (Maybe this is why so many APIs are launched as skunkworks projects.) But we can start by identifying the business model.  Common ones with open APIs are:
 
APIs as a marketing channel

Kipp Bodnar argues than any CMO should consider an API to extend brand awareness and consumers’ perception by letting developers write applications to distribute your content. And this might be at a fraction of your online marketing budget. To measure ROI, you could start by looking at the number of interactions you are getting through APIs or by tracking the traffic boost to your website.  
 
APIs as distribution channel for your content

If your company has some valuable content or data, APIs are a natural way to increase syndication. Indeed data accessible through APIs is easy to retrieve and can be embedded in other websites and applications. Many consumer web products, such as Google's many search API products, use this effectively to distribute content all over the web, which in turn drives their main advertising business model.
 
APIs are the cheapest and fastest way to build applications

You would love to build applications on all the different platforms your customers use - iPhone, Blackberry, Pre, Facebook, MySpace..the list goes on.  While it may never be possible to cover every platform, with an open API developers can help you create applications much faster than your team might.  For example, Twitter has no shortage of apps for every platform. 
 
APIs to distribute services

SaaS companies often use an API to distribute additional services. Your API could be either free because it's part of their existing subscription (a great way to differentiate service from competitors) or as an 'add-on' service for incremental revenue. SpinVox Announced last week 600 Registrations for SpinVox API which converts voice to text. They charge 35c for a 30 second message. Apparently their pricing did not discourage developers.
 
APIs to let third-parties extend your product

The same way than you would not be able to build all type of clients for different platforms, you might not be able to build specialized solutions for each market segment and vertical. By opening APIs you might create an ecosystem of partners and developers that augment your core offering with specialized solutions and innovative ideas. This makes your offering much stronger for your customers. Saleforce does this well - Force.com and the App Exchange cover a rich spectrum of specialized solutions they might not be able to provide otherwise.
 
APIs make your business more sticky

There is no secret than in the enterprise industry software integration projects are expensive and once in place, integration code rarely changes. SaaS vendors and services providers that managed to get deeply integrated in their customers IT stack tend to stick. 
 
So, what is your API business model?

Up next:  Roadmap and technical considerations for API monetization.