Reality checked

Reality checked

A lot of people have asked us why we built Superfeedr or what is the relationship to Notifixious. Here are a few hints.

A little over a year we launched Notifixious. The idea behind it was to allow any internet user to receive real-time updates from his favorite websites. We would send these updates either by email, SMS or Instant Messaging. For example, a user might subscribe to a blog to receive the last updates, or to a newspaper site. A user could also subscribe to a Craigslist search to be the first to know about a new place to move in, or to Simply Hired to get the last jobs in his field of expertise.

Earlier this year, we did an extensive analysis of our user base and found out 2 patterns.

  1. About 60% of our users would select email to receive their notifications. On average they would subscribe to 1 single website and most of the time it was a blog. These users have clearly been acquired through our widget. We were very disappointed : email is not real-time and the email user-experience is usually bad : spam, phishing… etc. We asked those people why they chose email and the answer was clear : they are scared by information overload and have no idea how to deal with an incoming stream of notifications which is very stressful, because they know they wanted to receive these notifications.
  2. A dozen of our users had, on the other hand, subscribed to more than 500 feeds. Oddly enough they were all using our XMPP api or a jabber account to receive these notifications. This behavior was very interesting compared to the first group. We contacted most of them and understood that they were actually using notifixious as a middleware for their own application or service. In a nutshell, they were using Notifixious as an on-demand feed parsing service. That was a very insightful discovery since some of them even said they would pay for our service. The idea to extract Superfeedr out of Notifixious was born.

We still haven’t identified how to deal with the first group, except that real-time services will need to find a way to avoid that information overload (or at least the sensation of it). However, by observing and understanding the behavior of a very small set of users, we’ve been able to identify some of the value of our service.

We even believe that this very small subset of our user base carried the biggest of the value our service provided. By continuously looping the feedback with this small user base, we think we can provide a great service!

Liked this post? Read the archive or

Previously, on the Superfeedr blog: Federating PubSubHubbub.