Mapping out your API Strategy: Webinar slides and recording »

Thanks to everyone that attended yesterday's API Strategy Workshop Webinar (and thanks to our presenters @sramji and @landlessness)

The slides are below and here is the full recorded webinar. 

Join our next API webinar, "Pragmatic REST:API Design Fu", May 5th at 11am PST.  You can sign up here. 

Moving the needle: Example API metrics »

It's an old cliche, but it's been said that you can't move the needle if you can't *see* the needle.  So frequently we're asked "what are good metrics to measure an API program?" 

While individual metrics are important - it might be as much about the 'process around metrics.'  Or..how metrics are evangelized and used to drive specific parts of the API product development pipeline.  Specifically:

1. Get early buy-in on the 'top 3'  -  strong API product managers often focus in on 1-3 top level 'strategic' metrics and get early, wide agreement from all parts of the extended team - the sponsoring exec, PM, engineering, BD, and operations. If different stakeholders are measuring success with different metrics (say number of developer sign-ups vs. API traffic vs. revenue) this can pull resources in different directions.  

2. Track against realistic projections.   Set expectations early by modeling anticipated results and then track actuals against this estimate. For example, pick a 'comparable' or competitor's API to guess developer portal traffic, then model the expected developer sign-ups and conversions  (for example, 10% of visitors might ask for a key, 20% of them might built an app, 10% of those apps might drive ongoing traffic, each of those apps might drive a certain volume of traffic, and so on... )  

3. Publish a weekly dashboard, religiously.  Proactively call out how product updates and community activities do or don't move the needle so you can quickly adjust tactics and think of new ideas that might move the needle.

4. Create a metrics 'pipeline' -  How do different metrics diagnose how each stage of the customer conversion process is working?  For example, developer portal traffic might be a good metric to measure the marketing guys. (that is, they might be responsible for getting developers *to* the portal.)  But whether or not a developer converts to ask for a key and then converts into an active API user might be a measure of how effective the PM process is working to create a product that developers want to use.  User experienced bugs can measure development and product QA effectiveness, and so on..

Here is an example of a metrics pipeline that we recently discussed with a customer.

(Thanks to seenoevil for the photo)

How do content and transactional APIs differ? »

Recently, during one of our our RAW (Rapid API Workshops) with a retail customer, a great question came up - what are the major differences between a content and transactional API?

Probably not a complete list, but in general:

Content APIs are more likely to be open, without sensitive information. Think of a search, media, or mapping API.    While the provider might want to track identity through API keys, these APIs often need no authentication, authorization, or encryption.    Search results may be highly cachable, which might be helpful to support high concurrency for bursts of demand for popular content.    Content APIs are also more likely to need throttling to protect the back-end and quotas to measure consumption - think about that grad student downloading your entire database one API call at a time.   Users might have some tolerance of downtime for free content that can easily be requested again.      Success for content APIs might be measured in terms of usage or engagement. (usage per consumer), so having  API usage analytics might be important.   If you can, make content APIs simple and easy to adopt with standards like REST.   

Transactional APIs  have sensitive data and therefore security needs go beyond identity and developer key level tracking  to include API authentication and authorization.   The data might need encryption and XML or API specific threat protection.    Instead of quotas, the back-end business logic might already contain all the controls you need to measure consumption and monetization.    There is probably no tolerance for downtime or lost transactions.   And of course success for transactional APIs can be measured in existing financial terms.

What's your experience in the difference between content and transactional APis?