Hub and Spoke: Building a Web Service in a Distributed World

With the expected opening of MySpace in about a month to third party developed applications, the atomization of the Web that began with widgets and was supercharged by the Facebook platform, is hitting its next major milestone.

Widgeteers have long talked about the importance of “fishing where the fish are” – putting your web content and web service in front of users where they are, as opposed to making them find your domain. 

Cut and paste Flash widgets offered an early look at how this distributed strategy can enable people can help spread your content around the Web.  Then Facebook came along, and instead of widgets spreading one by one from one MySpace profile to another, they started spreading from one profile to twenty (or more) via Facebook’s newly exposed social graph.  Not only that, but instead of small badges displaying content, there was the possibility of tacking on full, multi page, web applications to Facebook.com, a development that has important implications on monetization.  Widget publisher RockYou estimates that apps on Facebook spread seven times as quickly as widgets on MySpace, all things considered and all other things being equal.  I would guess that the monetization rates are similarly skewed towards apps.

It would appear that the financial markets are starting to notice that there might be a new model with which Internet publishers can thrive – social gaming company Zynga was recently funded without even having a destination website, Slide just got a half a billion dollar valuation (and not from intra industry kool aid drinkers), the Venture world’s heavy hitters continue to re-up on their widget investments, and even AOL is getting into the act by buying widget platform YourMinis.

So what does this new distributed model look like? 

Different companies are trying different things.  The aforementioned Zynga is entirely distributed.  Gaming happens within the networks of friends that exist on the host social network.  What I find interesting is the cross domain aspect.  Says the Union Square Ventures blog:

Building and supporting games across all of the major social net apis is a costly endeavor but one that we all believe will pay off as game players can access their friends wherever they are at that moment in time.

Yelp is keeping the focus on its brand and destination site.  Via Beacon, notifications of a new review posted on Yelp.com can be shared on Facebook – however, to see the good stuff – in this case local business reviews - you have to click through to Yelp.com.

Renkoo launched a Facebook App called BoozeMail that was only mildly related to its core business of event planning.  When BoozeMail took off, they launched a destination site to support it.

Flixster and iLike were able to port functionality and content from what were healthy destination sites.  As Facebook growth soon dwarfed traffic to their respective destination sites, these companies began focusing almost exclusively on their SNS apps.  These companies have stayed focused on their respective verticals however; movies and music respectively.

Companies like Slide, RockYou, and Hungry Machine are taking a more hedged approach.   These companies are less about ownership of an application / feature niche, and more about doing whatever it takes to expand reach.  In the world of ad networks, those with the largest reach can command the highest rates.  As Slide and RockYou battle to build a next generation advertising network, they are firing out a diverse set of seemingly unrelated apps – supporting the ones that grow, and abandoning the ones that don’t.

And the smart guys over at Chipin / Sprout decided to lay off the “drug” that is unrelated Facebook apps completely, and focus on their core business – a multimedia presentation widget that can be pushed out to any social net.

So what’s the right model?  Fully distributed like Zynga or a focus on a core community with only marginal outreach to the SNS like Yelp?  And how should you manage your various user bases?  Should a user on one SNS be able to interact with a user of another SNS via your app (Zynga)?  Or should the user bases be kept separate (iLike and Flixster)?  And what should be the ultimate goal of your distributed business?  Reach or feature ownership?  And what brings a higher chance of success – porting an existing web service to the social networks (Flixster), or building something native (Renkoo)?

It’s unlikely that one size will fit all.  But I have come to some conclusions in regards to my own company.

It’s called Hub and Spoke.

Hub and Spoke

The hub and spoke model for user generated content web services is one in which a home base destination site works in tandem with the distributed apps and widgets associated with the service.

A single login is maintained across the entire web service’s footprint.  Logging into the destination web site automatically logs you into all of the web service’s widgets and apps and vice versa.  Content contributions and reputation points are preserved across domains.  If you post content via a MySpace app, the default scenario would make that content available on the related Facebook app. 

Reputation points accumulated on one domain would translate through to another.  For example, a user earning points on one domain (helpful votes, pokes, hugs, coins, post totals, thumbs’ up, etc.) gets the benefit of those points on the service’s destination site, and on any of the service’s other spokes which they participate.

Just like a Facebook App offers publishers more functionality and monetization options than a Flash badge, ownership of a core domain offers additional advantages not available via either apps or widgets.

The way I see it, both the hub (destination site) and the spokes (widgets, apps) provide complementary benefits to the publisher.

The Hub (yourdomain.com)

The core roles that should be provided by the Hub of your distributed Web service are as follows:

Monetization

Social network traffic is notoriously hard to monetize.  Whether it’s because SNS users tend to be cash poor and time rich, or whether the ad networks have just not found the right technique to reach these sorts of users is inconsequential.  Presumably, if you have a destination site, you have some way to monetize it that is better than the industry averages for social network traffic.

Furthermore, maintaining a functioning revenue model at home base protects you from rule changes on the SNS.  Just a few days ago, Google missed revenue due to lower than expected performance from its SNS inventory.  Isn’t it possible that as FB and other mega properties start to enter a realm of higher financial expectations that they might need to feel the need to tax the higher performing apps – especially if they are unsure about their own ability to monetize?

Community / Brand

Experience has taught me to never underestimate the importance of community in building (or harming) a web business.  When I saw the Yelp founders speak at the Commonwealth Club a few months back, their explanation for why they don’t have a more sophisticated Facebook app was that they have a small dev team, and they just hadn’t gotten to it yet.

I don’t buy it.

I think the real reason that’s Yelp’s focus has remained on its destination site is that Yelp is a formidable community in its own right, and that the company worries that making its content and functionality fully available on Facebook would serve to undermine their hard earned community, and build Facebook’s.

Whether or not they could maintain their strong community while providing a more robust app remains an unanswered question.

And Yelp is not alone in thinking like this – I haven’t seen a Craigslist App for Facebook, a MySpace App for Facebook, or a WebmasterWorld App for Facebook.

Furthermore, if valuation is at all important to you – either for raising funding or selling your business – it pays to invest in your brand.  Branding is a lot more straightforward on your own domain than it is on those that belong to other people.  I wouldn’t be surprised if a significant percentage of Facebook app users believe that everything they interact with on Facebook is owned by Facebook.

Staging

Another benefit of maintaining a home base for your web service is the ability to test the effectiveness of features on your own community before rolling them out to Facebook, Bebo, or MySpace.  Flixster founder Joe Greenstein said on a panel that this was exactly the way they prioritized which features to port from Flixster.com to Facebook.  Those that do well on Flixster.com get on the fast track to showing up on the Flixster Facebook app.

Widget / App Distribution

App distribution on Facebook is very fluid.  In effort to combat app spam, Facebook is continuously tightening the rules and changing the feeds required to distribute an app.

It’s a bit more straightforward on your own domain.  If you have an active community and good destination site traffic, it should be fairly easy to seed your SNS apps with users from your own site – and, you can be as aggressive as you’d like in encouraging your users to install SNS apps.   

SEO: Unique Content

If your SNS apps and widgets are collecting content, it is most likely hidden from the Search Engines inside Flash (on blogs), or behind a login (on SNS).

This is good news.

It means that for the purposes of SEO, this content remains “unique.”  You can display it back at home base, and have it serve as search engine fodder.  This is a pretty big deal.

So this covers the hub of your distributed web service.  Now we move on to...

The Spokes

The core aspects of the Spokes are:

User Acquisition

Dropping your Web service into millions of existing networks of people can supercharge its distribution.  This has been written about ad nauseam.  It’s beyond debate.

Content Acquisition

If monetization is a weak point of SNS traffic, content generation is a strength.  When RateItAll ran a trial push of its FB app, we saw massive engagement numbers – 3X ratings per user and pv’s per user than what we saw on our destination site.

This, is the “time rich” factor coming into play again.  Hub and Spoke allows you to use each node to its potential – content and user acquisition from the SNS, and monetization and brand at your domain.

SEO: Inbound Links

This is pretty much restricted to blog widgets (although the FB App landing page is exposed to the SE’s).  As discussed earlier on this blog, a bare HTML link below a Flash widget that pulls dynamic, relevant anchor text is a beautiful thing in the world of SEO.  Link dev tends to be a painful and mind numbing process – if you can trade inbound links for cool functionality via a blog widget, you’re on to something.

There you have it – Hub & Spoke.  If folks have interesting examples of companies pursuing related, distributed web service strategies, I’d love to hear about them in the comments.

Photo Credit: Hofstra

Comments

[Ming]

Wouldn't hub and spokes equal a wheel? ;)

Great post and great example based on RateItAll.

There is definitely a lot of movement in this area and each company will need to find the right model that fits their business.

[lawrence]

Yes Ming, I believe it would. BTW, Shelfari is another site that I believe is trying to provide a unified service across domains.

[Ming]

There are several sites that are using the hub and spoke approach to varying degrees. As you pointed out, if you want to go big and resources aside, the hub and spoke is generally the best approach. Increase your reach, protect yourself from the actions of companies who don't have your best interest at heart and maintain control over your brand.

People shouldn't be afraid of the spoke and hub. A well architected system really isn't that much more work to modify and deploy across multiple domains and platforms. For example, I've personally deployed flash widgets, javascript widgets, standalone web tools, facebook app, and WordPress widget/plugin for a site. They were all relatively easy since they were all build on the same set of APIs and web services.

[Business plan]

Great consolidated report. Your suggestion would surely provoke new thoughts and decisions.

Thanks for the selected topic.

[lawrence]

I agree Ming - if OpenSocial and the FB platform end up reaching most SNS users (which it appears that they will), it should be manageable to support the vast majority of end users on the sites they frequent.

As an aside, there's an interesting bit of blog spam in the comment above - I'll leave it up for now.

I'm fascinated by UGC sites whose users take on their SEO / Linkdev for them. I've only seen this behavior from users of two sites; Squidoo and Gather. Both revenue sharing, obviously.

Don't get me wrong, blog spam is the lowest of the low - the bottom feeders of the SEO world.

However, if someone could teach the gentleman above the principles of white hat SEO, there's plenty of above board things he could be doing to drive traffic to his article, and in the process, improve Gather's overall search engine rankings.

I think I'm going to write a post on "teaching your users SEO."

[Chris DeVore]

It's a pretty modest version of the idea as you've described it, but I'm experimenting with a hub and spoke model with a prototype blog Q&A widget called Askablogr (http://askablogr.com). The basic idea is "Yahoo Answers meets MyBlogLog", where a distributed network of blog widget "spokes" (including HTML links back to Askablogr.com) trigger reader / blogger Q&A exchanges that create content and tags for the "hub" (while also publishing them automagically as structured posts on the host blog). Any and all feedback would be more than welcome...

[lawrence]

Chris, sounds very cool. I think Q&A has great potential as a distributed service. I hope to play around with your service this weekend.

[lawrence]

Hey Chris, I tried to try your widget, but I never got my confirmation email (I checked my spam filter, and white listed your domain - still nothing).

[Facebook vs Orkut]

Creating profiles in Facebook.com, orkut.com & such websites for my http://www.alexa.com/data/details/traffic_details/fortunehotels.in/hotel_kolkata.aspx business hotels, http://www.alexa.com/data/details/main?url=www.fortunehotels.in/hotel_chennai.aspx budget hotels, http://www.alexa.com/data/details/traffic_details/fortunehotels.in/hotel_jaipur.aspx holiday packages is happening good in http://www.alexa.com/data/details/main?url=www.fortunehotels.in Alexa traffic details.

[virtual assistant]

reading the this article helps me gain new information about hub and spoke. i think this will really help me.