jump to navigation

Business models for apps and widgets November 16, 2007

Posted by jeremyliew in ad networks, advertising, business models, facebook, myspace, open social, platforms, self espression, social media, social networks, user generated content, widgets.
9 comments

This afternoon I spoke to the Stanford class on Creating Engaging Facebook Apps.

As I said at Web 2.0 expo, building big businesses online is hard work. While it isn’t hard to start an app company, especially as a single developer ($250k in revenue) or even to support a small team ($2.5m in revenue), it gets quite hard to scale revenues to $25m/yr.

Assuming a 5% daily active rate and 3 pageviews per visit, an app developer with a $0.50 RPM would need to get to 926m installs to get to $25m run rate. Compare that to the app with the most installs on Facebook – Slide’s Superwall which has around 20-21m installs. Clearly, broad reach app developers need to develop (i) multiple (ii) high engagement apps [ie higher active rates and pageviews/visit than these assumptions] (iii) across multiple social networks to be able to get close to this revenue target. (RPMs will likely be higher for companies with a direct sales force as well, so the target isn’t quite as high, but you get the point).

Under the same activity and pageview assumptions, an app developer with a $10 RPM would need 46m installs to get to $25m in revenue. Apps with endemic advertising opportunities can easily realize this level of RPM but will still need to be in multiple social networks to get to those levels of installs. It doesn’t make sense to limit your world to being a Facebook app. Social network platforms are avenues for distribution, and app developers should be taking advantage of all of them.

One of Lightspeed‘s portfolio companies, Rockyou, is taking the former approach. Another, Flixster, is taking the latter. Both seem to be working so far.

I also did a similar analysis for digital goods business models in the presentation. Here is a link: Stanford Facebook Class presentation

Social Design Best Practices November 5, 2007

Posted by jeremyliew in business models, facebook, game mechanics, google, myspace, open social, product management, social media, social networks, viral, viral marketing, web 2.0, web design.
add a comment

Bokardo notes a set of social design best practices as recommended by the Google OpenSocial team:

1. Engage Quickly – (my interpretation: provide value within 30 seconds)
2. Mimic Look and Feel – (make your widget look like the page it is in)
3. Enable Self Expression – (let people personalize their widgets)
4. Make it Dynamic – (keep showing new stuff)
5. Expose Friend Activity – (show what friends are doing)
6. Browse the Graph – (let people explore their friends and friends of friends)
7. Drive Communication – (provide commenting features)
8. Build Communities – (expose different axes of similarity)
9. Solve Real World Tasks Р(leverage people’s social connections to solve real problems)

Worth reading the full text from OpenSocial

Why did Myspace join OpenSocial? November 2, 2007

Posted by jeremyliew in business models, distribution, facebook, myspace, open social, platforms, social media, social networks, startup, strategy.
6 comments

Yesterday was a very good day for app developers with the official launch of Open Social. A particularly good day for Flixster (a Lightspeed company) which was on stage with MySpace, Google, Ning and others for the launch, and was the sample app used in many of the demos.

With so many platforms opening up, resource constraints are the key problem for many app developers. There are plenty of great opportunities, but they don’t have enough people to pursue them all. They are forced to make choices and prioritize.

Open Social helps a lot in that you can “learn once, run anywhere”. While it isn’t “write once, run anywhere”, the resource commitments required to support multiple social networks are much lower. As Andreessen notes:

As an app developer, you have three options:

* You can write purely to the Open Social API. If you do this cleanly enough, your app will run unchanged in any compliant Open Social container. (Google is actually not making this claim — they’re calling Open Social “learn once, write anywhere”, which is not the same as “write once, run anywhere”. But in practice, the API is simple enough that “write once, run anywhere” should work just fine.)

* You can write an app that is specific to one container. For example, there may be some apps that make sense only in LinkedIn — business-related apps, say. There may be other apps that make sense only in Ning — apps that presume that users are creating their own social networks, say. And there may be yet other apps that only make sense in Salesforce.com, which will also be an Open Social container. In those cases, you are targeting your app to one specific container, and so using whatever additional APIs that particular container provides, in addition to the Open Social APIs, is a no-brainer.

* Finally, you can write an app that behaves differently depending on which of several containers it’s running in. Your app just discovers which container it’s running in, and then does whatever it wants on a per-container basis.

No standard can possibly anticipate all of the different use cases and scenarios people will think up. Standards that try to anticipate all of the different use cases fail, because they are too complex and generally impossible to implement. Standards that standardize behavior that is clearly standard, while leaving open the ability to innovate on top, succeed. The history of this kind of thing is quite clear, and Open Social is on the right side.

For smaller social networks, joining Open Social is a no brainer. But MySpace is big enough that app developers would have written for its platform regardless of whether or not it was part of Open Social. So why did they join?

It comes down to the competition for app developer’s time and resources. In the few months since Facebook opened up its platform, Myspace has seen its lead eroded from being 3x as big to just 2x as big. Facebook was winning more users, and more share of user time, because app developers were adding new features to the Facebook experience much faster than Myspace could do on its own.

If Myspace had stayed out of Open Social, there would have been three platforms competing for developer time. By joining, there are now only two, and one (Open Social) provides potential access to far more users than the other. More developer time would be spent on Open Social, and MySpace would benefit more from the improved rate of innovation.

MySpace also knows that it can win more developer mindshare relative to other participants in Open Social if they help the developers make more money. It has a better developed sales force and ad network than many of the other participants, and if it opens up access to that salesforce to app developers, then you’ll see even more developers focusing even more of their time on Myspace (at the expense of Facebook and the other Open Social participants). If they were to go so far as to guarantee a minimum CPM for “canvas pages” on Myspace, then they’d see a surge of developer interest.

This will require a significant mindshift for Myspace which has traditionally not wanted other companies to monetize pageviews within Myspace, let alone helping them monetize. If they make the shift, MySpace will not have given anything up by joining Open Social. Rather, they will have gained something. They will be the place that app developers can make the most money, and hence be their first priority. The increased stickiness and loyalty to Myspace will accrue to Myspace alone.