Comments Off on Presentation : NPR API Usage and Metrics

By daniel_jacobson, April 19, 2010 1:38 pm

I originally published this post to the Inside NPR.org blog on April 19, 2010

Daniel Jacobson’s Presentation on NPR API Usage and Metrics

It has been more than a year since my last post about API usage, so this is long overdue.  Needless to say, the NPR API has grown tremendously since its launch in 2008.  The biggest consumer of the API is still NPR by a long shot.  That said, member stations, partners and the general public have been making extensive use of the API. 

Below are metrics on the API followed by a suite of examples of how it is being used.  But first, here are a few qualifiers to the statistics:

– These statistics are about requests to the API, not necessarily what was consumed by or presented to users.

– These numbers were obtained through server logs.  Although we believe they are largely accurate, it is possible that these numbers are off by a couple percentage points in either direction.

– A request to the API can mean many things.  For example, on the NPR News iPhone app, the Top Stories section is populated by one request to the API – that one request returns many stories.  The Flash Player on NPR.org, when playing a single piece of audio, represents one request to the API for exactly one story.  Meanwhile, some requests (such as a story page on WBUR.org) get exactly one story, but because they get cached result in many page views for that one request.  As a result, metrics around requests are imperfect.  That said, they do offer some information about usage and consumption, even if not the whole story.

The big jump in total API requests from July to August are due to the launch of many new products in July.  Among them are the new NPR.org, the NPR.org Flash Player, the NPR News iPhone app, WBUR’s new web site, and Minnesota Public Radio’s new site. Since then  an increasing number of applications have been implemented on the API, including the NPR mobile site and other station sites (like KQED and KPCC), accounting for the steady growth over the last few months.

The total number of stories requested is a new metric that we started tracking in October, 2009.  This is the number of stories requested, not the number necessarily delivered or consumed by a user.  This metric is based on the numResults parameter (or lack thereof) in the API request.  And to be clear, in March, 2010, the API did deliver over 1.1 billion stories!  Since tracking this metric six months ago, the API has handled almost 5 billion story requests.

Overwhelmingly, NPRML is the dominant output format delivered by the API.  That said, most of the requests are from NPR and related products.  In the past, prior to NPR building out the new site, iPhone app, etc., the distribution was slightly less NPRML-heavy.  Those models had a distribution of NPRML at about 55% and RSS at about 25%, with MediaRSS, JS and HTML getting reasonable traffic but significantly less than RSS.

As you can see from this chart, the non-NPRML formats have grown a bit over time, especially the JavaScript Widget in recent months.  Prior to August, 2009, NPRML was still very dominant, but it its use was substantially closer to the use of the other formats.

Abstracting away NPRML, it is much clearer how the other formats have grown over time.  RSS and the JavaScript Widget have really grown tremendously over the last year.  Mix-Your-Own-Podcast launched in December, 2008 and took a while to start its growth. 

To get a sense as to what is creating all of this traffic, I have created a presentation that shows a range of examples on how the NPR API is getting used.  The following presentation is probably missing some interesting and heavily-accessed examples, but it should give you an idea as to how pervasive the API has become. 

Given the growth charts above, along with the introduction of the API to station sites and the launch of the iPad and other upcoming tablets and portable devices, we expect these numbers to continue to climb.

Finally, if you are aware of some interesting implementations using the NPR API, please let us know in the comments here or by emailing us at techcenter at npr dot org.

Comments Off on Presentation : NPR API Usage and Metrics

By daniel_jacobson, April 7, 2010 10:23 am

I original published this presentation on April 7, 2010 to demonstrate some of the usage and metrics of the NPR API. In addition to the flow of an NPR story from creation to distribution, I also tried to provide a reasonable sampling of the more popular or interesting implementations.

NPR API Usage and Metrics from Daniel Jacobson

Comments Off on Presentation : NPR Examples of COPE

By daniel_jacobson, October 5, 2009 8:03 pm

This presentation was first published to my Slideshare account on October 5, 2009 and was used in different forms to demonstrate the power of the COPE model in content management and API development. It shows the same NPR story displayed in a wide range of platforms. The content, through the principles of COPE, is pushed out to all of these destinations through the NPR API. Each destination, meanwhile, uses the appropriate content for that presentation layer.

Comments Off on Presentation : NPR at Wolfram Data Summit 2010

By daniel_jacobson, September 8, 2009 11:24 pm

This presentation was given at the Wolfram Data Summit in September of 2010, focusing on content management, APIs and COPE.

Comments Off on ProgrammableWeb : How to Make Money With Your API

By daniel_jacobson, September 5, 2009 9:18 pm

This post (originally appearing in ProgrammableWeb.com, which is now defunct) comes from Daniel Jacobson, Director of Application Development for NPR. Daniel leads NPR’s content management solutions, is the creator of the NPR API and is a frequent contributor to the Inside NPR.org blog.

One of the questions that I am most frequently asked regarding content APIs is “how can I make money with my API?” Before answering that question, however, it is important to ask for whom the API is designed. After all, the audiences for your API will determine what business opportunities exist.

The most common target audience for APIs is the developer community. While that audience is an interesting and potentially important one, it is not where the greatest value can be realized.

When we launched the NPR API in 2008, we established four target audiences, each of which were important. The target audiences were (and still are):

• NPR: NPR is of highest importance because as we build all of our systems, mobile apps, etc., it was important to be as nimble and efficient as possible. We have adopted this so deeply that the API is the foundation of everything that we do, including acting as the content source to NPR.org.
• NPR member stations: NPR member stations are a critical aspect of the NPR mission and business model. Offering the stations a new, more effective way to get NPR content in a robust way better serves the stations and their communities, as well as NPR.
• NPR partners: Having the API quickly became a more effective way to interact with content aggregators, business partners and other commercial entities with whom we established relationships. In fact, the API became a business development tool where some external organizations approached us because we had a robust API.
• the general public: Finally, as part of our public service mission, it was and is important for NPR to share our content with the world. Exposing it to the developer community is a natural extension of this effort. But when we launched the API, we fully expected this to be where true innovation took place with the API. In fact, the day after our launched, I told CNet that the community of “developers will come up with a lot of brilliant ideas.”

With the API live for a full two years, I decided to look more closely at how effectively the API has been serving these four audiences. Although I am not surprised by the results, you may be…

The following charts show the distribution of how many API keys are registered by each of our four audiences. That metric is then compared to the consumption of the API (as measured by API requests) by the four audiences:

Obviously, there are many more API keys registered to the general public than the others. In fact, our API currently has over 10 times more public keys than all other keys in the system combined.

Despite the disparity between public keys and those used by other audiences, the dominant group from a request perspective is overwhelmingly NPR, responsible for more than 92% of the total number of requests. That means that the remaining 8% of requests are coming from all three other target audiences combined.

When considering this distribution in requests by audience relative to the key distribution by audience, it is clear that NPR has by far been the most effective user of the API. So, given the incredible amount of consumption by NPR, how has that translated into revenue opportunities? Below is a chart detailing the growth in total page views across all NPR platforms over a twelve-month span:

By the end of the twelve months, NPR’s total page view growth has increased by more than 100%. How were we able to add that many page views in such a short amount of time? The API. Not directly. But the API did enable NPR product owners to quickly, efficiently and independently build specialized apps in various new platforms. As a result, what we have seen is primarily additive growth. In other words, in addition to NPR.org’s growth (by about 19%), we have been able to add the NPR News iPhone app, the improved mobile site, the Android app, the iPad app, etc., each of which adds page views. From our analysis, adding these new platforms is generating new traffic and is not cannibalizing page views from NPR.org in a substantive way. These new page views create new sponsorship/advertising inventory that create new revenue opportunities.

So, when asked the question “how can I make money with my content API?”, the answer should always be based on your target audiences. And from NPR’s experience, the best way to make money is to focus on how the API can improve your internal processes. Of course, it is still important to maintain a solid support and growth model for the other audiences as well, but we cannot all be Google, Netflix, Twitter, etc. Unless you are planning to spend a lot of money on community engagement, you are better served by making sure you can liberate your product owners and grow your business more quickly, efficiently and independently.

In other words, don’t assume that the API’s primary audience is the developer community. Question that default position and do the introspection that will enable you to get the maximum value out of your API.