Understanding Cocktail Rating Distribution

Something interesting with my facebook application is that in the past week I have gathered >1000 ratings on the cocktails in my database from 745 unique users of my cocktail making application. This is a fairly small number for data analysis but 3 things stood out:

The most votes were given in the bucket of "10" - people seem to tend to vote on the cocktails they like.

The cocktails that were rated 10 tended to get more votes in general i.e. 3 votes per cocktail and not the average 1.5

When looking just at the users who gave a ten and what % of each voting bucket they made up it became clear that these users were pretty much all or nothing guys relative to the crowd, either they gave a cocktail a 10 or they gave it nothing.

More to come on user voting behaviour over time I am sure and also on the most popular cocktails, cocktail ingredients, favourite cocktails lists and so on... I now have far too much data to work through and that is great!

In the Facebook Directory

So I have been working on my facebook cocktail application for a little over a week now having started it on the memorial day weekend. It allows you to do everything my cocktail site does and a little bit more including recommending a cocktail to a friend and seeing the most recently popular cocktails and the top 12 users yesterday. I actually have a bunch more ideas of what it could do like little graphs of the popularity of the cocktail over time and so on.

What is exciting is that in 3hrs I have added 300users to the application, now obviously rates won't stay that high but realistically most of the east cost wasn't browsing facebook when the app was approved and neither was the UK. It will be really interesting to see how things go over the next 24hrs.

The best news is I have log files tracking everything going on so I will be able to note down and describe what the growth of a facebook application looks like!

More posts to come down the line but I want to leave you with a thought. For my cocktail recommendations engine I now have a track... at a user level... of every cocktail viewed and rated, and at what level (pretty much tied to demographic too if I can get my ass in gear and pull that data). This recommendation engine can get much, much smarter :D

How to use the Typepad Widget API with PHP

The Typepad Widget API is awesome. The concept is that you have a great widget you want users to add to their sidebar. Typepad want this to be a small self contained piece of DHTML code and want to be able to do all the verification of the user on their side without giving the widget owner any access to the user's account.

Browser based authentication used at both the eBay and Yahoo! developer programs (and explained beautifully in diagram form on the Yahoo! site) simply won't work for this since it gives the programmer access to your eBay/Yahoo/Typepad account (were they to use it). So Typepad found a solution to the problem that is really simple and elegant.

All data is sent to the API in a POST command along with redirecting the user themselves (rather than just a server to server POST call). Typepad's Widget API requires fields identifying you as a developer, your application, what it is called, verifying you are who you say you are (with a token) and finally containing the FULL HTML you want inserted in the user's sidebar to be sent to them through the POST command.

The user then lands at a Typepad log in page and all the data is carried through with them to a page where they can effectively suggest whether or not to keep the Typepad widget. GREAT!

I love this method, it's secure, clever, simple and behaves exactly as you would expect... Having worked with Google AdWords/Base/Adsense APIs, Yahoo! APIs, eBay APIs and a fair few others I have to say this Typepad Widget API has been the simplest yet. Well done Typepad!

Releasing an API can make you more money

So facebook have released an API earlier this week (surprise surprise I'd already signed up within 6hrs of launch, more to come), I just can't see the revenue upside for them in this esp. given their generous call limits. This confusing facebook API is a neat segway into the flipside of the post I made earlier this week saying natural search APIs are poorly supported due to the lack of revenue upside. For me the power of a lot of sites is in the platform they offer and the fact that this platform is their revenue base. APIs that enable use of a platform to make the API owner more money are the best supported tools out there. Let's look at 2 examples: the eBay API, and the typepad API.

Starting with the first last I am writing this post through the typepad api using the great windows live blogging tool and you know what? Typepad simply don't care since I pay them for using their platform. Switching costs are pretty low for me on blogs. I have written my own blog software based off a database which I still own and works pretty well, I can use wordpress or blogger too and Typepad allows me to download all my listings in a datafile. My domain name is actually hosted by namesco (who I love but that's another story) and just DNS mapped to this namespace (easy to change), basically apart from a few small technical hurdles I could move my blog over night. I don't however because the typepad system is great and they keep on making it easier for me to use them with the blogging tool as an extension of their platform through the API being a key example. Offering out their API is helping to keep me a loyal customer by allowing anyone to develop for me the tools I need/want and they must know this since the API is free.

eBay's API is awesome. I love it and I keep saying it (much to the embarrassment of my colleagues). Without the eBay API such companies as channeladvisor and marketworks probably wouldn't exist and the new startup I read about today certainly would not. The beauty of this API is simple, eBay makes money wherever and however users buy and list so long as they use the eBay platform to do it. There are more and more examples of how eBay is cropping up all over the web wherever people might partake in e-commerce. This API strengthens the core platform and hence is totally free to use up to 1.5million calls a day if you certify (which is also free).

I am a passionate fan of forward thinking corporations/companies who use API's to their advantage. I think it makes the most sense when the companies have a really useful platform and they make revenue from that platform detached from their pure website. In summary if you want to make money from an API for your really useful website make sure it's users interacting with the platform that's valuable for you and not visitors to your website.

I really wanted to shout about the Adwords and AdSense API's here today and Yahoo's upcoming Panama but there just wasn't enough room. Another post coming soon.

Why do search companies offer these Map APIs?

Now maps is a really interesting area for looking at the offerings of the large web companies, i.e. Google, Yahoo and MSN (not eBay who don't offer anything in this area but do offer APIs which produce cool maps mashups with eBay listings).

I truly don't understand the strategy here from these big internet companies. They offer out their maps API for free and get thousands of users developing and adding maps to their site showing high traffic roads, apartments for rent, used cars for sale, real estate for sale and a whole bunch more. These resources developed by developers are fab for me as a user but I simply don't understand the value they offer for the search giants. Are they intending to monetize with adverts in future, do they just want to stay friendly with geeks, who knows?

I do have one suggestion for why it's good that the search engines are offering these APIs out, perhaps they are trying to capture the future of search. Offering out map's APIs for free gives them a huge R&D network. Let's say they have 1000 developers each using their maps (a gross understatement but hey ho) and each of those spends a 3 weeks of late nights working on their cool mashup (that would comfortably add up to 40hrs a week for me as a geek who loves this stuff :) ) that gives them 120 000 hours of free developer time from people near the cutting edge and not constrained by corporate concerns. Even at just a $10 an hour wage for engineers at their company that would be $1.2million of free R&D without factoring in all the savings by not actually employing someone (a really expensive task). The numbers I have given above are all low balls, I could comfortably be 2orders of magnitude low in that $1.2million!

Certainly geo-location and local search are important and will be of bigger and bigger importance as time goes on.

  1. Being seen as the provider of choice thanks to all the geeks using and exposing your product
  2. having 1000 applications in test to see which ones take off and you can copy, improve upon and release with huge traffic driven from your user base is actually quite a good idea.

Heaven forfend but potentially these big search companies aren't just having a random altruistic brain fart and pointless API arms race but are being very canny about capturing a future search channel.

In my next post in this series (there may be other posts inbetween) I am going to chat about paid/free user Platform APIs. Specifically eBay, del.icio.us and Flickr but potentially more.

Search APIs offered by the largest engines

APIs are a topic dear to my heart and part of the fun of moving to California and silicon valley is that I have been able to really start to see and understand the actions of some of the bigger internet companies a little better. Something that I have never understood is why a company would build an API, only allow developers a couple of thousand calls a day (which believe me is pathetically small) and then leave those API's out there relatively unsupported for a significant amount of time.

A quick analysis shows all pure natural search APIs are highly restricted... eg. Google and Yahoo with only a few thousand calls a day each. Why is this?

As I see it the question is one of upside for the search engine. What can we do if you or me have access to their algorithmic data on a large scale. A non-exhaustive list of negative suggestions for the search engines include back engineering their algorithm or tracking SEO performance by seeing which sites perform well for which terms and what variables are true for those sites, producing copernicus and dogpile tools (speaking of which why does dogpile still exist???) which don't monetize with their adverts and finally competitors finding ways to compare and improve their rankings. These all carry significant risk. Conversely I don't see many uses which give benefits to the search engines: syndication onto people's sites in conjunction with contextual adverts is certainly one, cool analytical tools which attract positive PR in general and in their recruitment pool is another and reducing the incidence of scraping of their results is another example.

The search engines do not support their natural search APIs well at all and since there is significant risk and little opportunity to exposing them I don't see this changing in the near future. The same cannot be said for their revenue driving tools. Panama by Yahoo is a really significant tool that they say they have spent years developing and which will have major support. It plugs an API straight into their paid search advertising... this drives revenue... this is good. SImilar can be true for the adwords API and adsense API.

I think it is clear that search engines promote and support the APIs that offer them more revenue however there are certainly areas where this is not true... look at the unseemly battle over maps, look at geocoding and more. In the next post I will explore why companies would offer these random Web 2.0, bandwidth eating, non-revenue generating tools to grow successfully.

My Photo

Recent Posts

Blog powered by TypePad

my flickr tag cloud