Hungry Machine Blog

UPDATE: Animoto just raised a round of investment from Amazon! Congrats Guys!

Animoto is a great idea. They take your photos and create a production quality video to the music of your choice. Its the end of those boring slide shows, for good.

We had the pleasure to work with the Animoto guys to launch their Facebook application, "Animoto Videos", which leveraged all of the existing photos on Facebook. The growth was amazing.

(From a recent AllFacebook article here)

Scaling an application from a few hundred users to over a million in just a few days isnt easy, but we had a great team. Their backend rendering farm lived in Amazon's Cloud, and the growth was so impressive, Jeff Bezos even spoke about them at Y Combinator’s Startup School just a few weeks ago. From 50 EC2 instances to over 4k in only a few days. See the video below.

It was a pleasure working with the entire team from Animoto, RightScale, and Amazon. See their blog posts about the application here, here, and here.

I'm sure I'll cross paths with many of you at RailsConf. First round of beers is on me.

One of the challenges with writing a Facebook or Bebo application is staying within a limit it gives you to respond with data before it shows the Application Did Not Respond page to a user. Having a content reach application calling external APIs, like Amazon or YouTube, with response times beyond your control, forces you to keep such calls short to allow extra time for processing. We usually wrap them in aggressive timeouts with a retry. As an example is this code from the Ruby Amazon E-Commerce REST Service API gem rewritten to limit a single call attempt to two seconds with one more retry.

module Amazon  
  class Ecs

    def self.send_request(opts)
      request_url = prepare_url(opts)

      res = Net::HTTP.get_response(URI::parse(request_url))
      unless res.kind_of? Net::HTTPSuccess
        raise Amazon::RequestError, "HTTP Response: #{res.code} #{res.message}"
      end
      Response.new(res.body)
    end

  end
end

module Amazon  
  class Ecs

    class EmptyResponse
      def items; []; end
      def total_pages; 0; end
    end

    def self.send_request(opts)

      res = timed_try(request_url, 2) do |url|

        uri = URI::parse(url)
        req = Net::HTTP.new(uri.host, uri.port)

        # Agressive timeouts
        req.open_timeout = 1
        req.read_timeout = 2

        req.start { |http| http.request_get(url) }

      end

      res.kind_of?(Net::HTTPSuccess) ? Response.new(res.body) : EmptyResponse.new

    end

private

     def timed_try(url, attempts, &block)

       attempt = 1
       begin
         block.call(url)
       rescue Timeout::Error
         if attempt >= attempts
           RAILS_DEFAULT_LOGGER.warn "[amazon_api] gave up after attempt ##{ attempt } to get data from #{ url }"
           nil
         else
           RAILS_DEFAULT_LOGGER.warn "[amazon_api] attempt ##{ attempt } timed out on getting data from #{ url }"
           attempt += 1
           retry
         end
       end

     end

  end
end

We just got back from several conferences around the social media space. CommunityNext was a developer-centric event that allowed for many interactions and trading of best practices with several top Facebook developers. GraphingSocial was a slightly larger gathering that brought together an impressive list of speakers including Reid Hoffman, Michael Arrington, Danny Sullivan and others. It was a great opportunity to network, see some of the latest Facebook applications, and just generally talk shop with investors and developers in the social media space. Sometimes at these events it's so easy to get lost in the shuffle, that it is tough to talk with the people you want to talk to. We did, however, have what we determined to be a strategic advantage: Eye Candy

Here's how it went down:

Step 1: Several weeks before event ~ Randomly sign up for booth and to be a conference sponsor without really having a plan other than "A booth seems like a good idea. We can talk to people. And stuff."

Step 2: 7 days and 3 minutes before event ~ Contemplate whether "Hungry Machine Hula Hoops" send the right message.

Step 3: 7 days and 2 minutes before event ~ Return to fetal position in corner

Step 4: 3 days before event ~ Eureka! An idea is born. Everybody loves Twittervision and everybody loves money - let's combine the two!

Step 5: 2 days before the event ~ Begin building application that shows the geographic distribution of impressions and clicks within the Hungry Machine ad network (pic below)

Step 6: 1 day before event ~ Take break from building application because In & Out Burger is just too damn good.

Step 7: Later in that day ~ Eat 3rd double double

Step 8: Day of event ~ Deploy application; set up Apple 30 inch monitor that seems to emit a radioactive hue. Notice third arm grow out of small child as he passes monitor

Step 9: Booth now open for business! Potential clients, partners and just plain interesting folks start to roll in. They cannot resist the lure that is a 30 inch monitor with people's heads popping up on a world map.

In all seriousness, the above process was only slightly embellished, but really did serve a purpose in how successful and how much we got out of the GraphingSocial conference. Having an initial, built-in talking point is a great way to break the ice with people you are interested in talking with, and generally helps reveal someone's area of interest within the first minute or two of conversation. We would not have had nearly as successful of a conference without a little extra pizzazz.

In the good ol’ days of, let’s say…. three months ago, life was simple. The birds chirped a bit louder, the grass was a little greener, and, best of all, you could build an app on Facebook, submit it to the directory, tag it with a category or two, and see it nestle in among a smattering of other applications and watch your traffic grow at an obscene pace. Those days are over. Kuput. Finito. Building an app on Facebook and letting it “do its thing” is an increasingly difficult, if not impossible thing to do. The good news is that there are a host of traditional and non-traditional ways to gather good, quality traffic for your application. The bad news is that, very likely, it’s going to cost you:

Buy an initial seed number of users: If you can generate 10/20/30 thousand users on your app, your installed user base should be large enough at that point in time to see if it sinks or swims. You’ll likely have crossed a wide-demographic range by that point in time and have been able to see if you’ve built your app to properly leverage the viral touch points and social graph.

Generate “off-Facebook” buzz: Sure, Facebook pages aren’t crawlable. And sure, your app can’t live outside of Facebook. But that doesn’t mean there isn’t a universe (you know that thing… what’s it called… that’s right, the world wide web) that does still exist outside of Facebook. If you issue a web-based press release, it could get picked up by a variety of news sources who could reference it and Google will definitely crawl it. If you know any bloggers that would have an interest in your application, reach out to them and give them a sneak peak under the hood. If you have an existing destination site, leverage it! 40+ish million people are on Facebook, which means there is a reasonable chance the viewer of your destination site is also a Facebook member.

It’s in the name: This is certainly just a hypothesis, but I think a very reasonable one. If someone sends me an app, and I can immediately understand the concept of the app pre-install, I can make a decision point prior to installation about whether or not I think the app would be useful. I may not install it, but at least there is a chance that I will. If I don’t immediately grok how the app will work prior to install, there is no chance I will install it – what is it going to ask of me? Will I have to go out of Facebook to register for a site?

Just a few thoughts to consider when figuring out how to make your app go from 0 to 60(thousand users, that is) in 5 seconds flat.

The Wall Street Journal had a nice article yesterday about the rush to build apps in the Facebook space, in which they were kind enough to mention Hungry Machine. One of the points Riva touched on was around the different rationales for building an app. I wanted to elaborate a bit more on a few of the biggest reasons some of our partners seem to be entering the space.

1. Drive traffic to existing properties: Probably far and away the biggest reason most businesses are building apps – a traffic driving distribution play from Facebook to an existing entity is something that could drive traffic at a considerably lower CPA than many sites are currently spending
2. Create brand awareness: Facebook is a whole new space and many of the concepts that came to fruition in the mid-late 90’s are being replicated within the FB platform. Companies that are in a particular vertical and have not been successful in penetrating that market against established players are on a level playing field. Building a successful app that does nothing more (at least initially) than providing users with a great experience within the Facebook platform is enough to build some serious brand equity to be leveraged at a later point in time.
3. Creating a new revenue stream: This is generally the primary consideration for the single-man shops, or the smallest of the small companies. Facebook apps have evolving monetization concepts that can be shaped by the early innovators, but are a bit risky for a more established company to bank on and plug into revenue forecasts. Ad networks are springing up left and right, so if you can create an even moderately successful app (50k daily PVs), it can generally be worth your while.
4. Playing the me-too: Facebook is hot and if you don’t have an app on your product plan or roadmap, well, you’re probably behind some of your competitors already. If you believe Facebook will continue to become THE social platform (as the market basically indicates), chances are you or your boss are trying to figure out the best way to get something out, and you’ll figure out how it best helps your business later.

With our own apps, we’re pretty excited about helping to shape the revenue model for apps on Facebook. Figuring out what ads work and what don’t. What levers can you pull that will bring a higher click through rate? How can you best partner with folks to leverage more users for better rates? All things we’re working on and hope to continue to innovate on for our own purposes and for our partners.

We've been helping partners promote their applications via sponsored cross-linking for a while now. I recently had an idea that has been converting very well. I encourage you to give it a try, whether it's with us or with somebody else.

It's simple: combine a positive review from your application's review wall, your 75x75 directory icon, and the facebook install button. The sample we've provided is for the neat My Music application by our friends at Qloud.

On the publisher side, you should redirect clicks through a 'reflector' so that you can track the clicks you're generating.

On the advertiser's side, you should provide a link to the publisher with a spot for the publisher to fill in the current user's UID. The target of the link should log the clicking user and then redirect the user to the application. Later on, you can reconcile the referred users with your installed userbase to ascertain a conversion rate (and thus an eCPI--effective cost per install).

Developing applications for Facebook is a pain. The tunnel approach helps a lot to ease that pain but even then I prefer to start a FB app as a regular application, polish the logic, and then convert it to the Facebook one by adding FBML and such. At the early stages of the development I have the mocked parameter in config/facebook.yml set to true and keep this code in config/initializers/facebook.rb:

PERSON_PROFILE_URL = "http://www.facebook.com/profile.php"

FACEBOOK_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/facebook.yml")[RAILS_ENV] || {}

if FACEBOOK_CONFIG['mocked']

  class Facebook::FBMLController

    require 'ostruct'
    FB_SESSION = OpenStruct.new(:session_user_id => 1, :session_key => "12345", :is_valid? => true)

    def fbsession; FB_SESSION; end

    def require_facebook_install; true; end

    def redirect_to(url); super; end

    def url_for(*params); super; end

  end

  module Facebook::Acts::FbUser
    module InstanceMethods
      def friends
        (self.class.find(:all) - [ self ]).collect(&:uid)
      end
    end
  end 

end

It mocks out just enough of Facebook on Rails functionality to use FBMLController and acts_as_fb_user from the beginning without Facebook backend.

Some facebook applications might have multiple entries. For example, a user might be adding an application (action – new) or replying to an invitation (action – reply, param – id). Since the UI for Facebook application configuration allows to provide only static Post-Add URL it might seem like there is no way to route users back to the original action if they tried to reach when the application has not been installed for them. Luckily, we have full control on the destination via the next paramater of the post install URL. All we need is to build a URL using the incoming call parameters with the exclusion of Facebook-specific ones.

This is an example for Facebook on Rails based code that might go to the application controller:

class ApplicationController < Facebook::FBMLController

protected

  before_filter :require_facebook_install 

  def require_facebook_install    
    if in_canvas? && !fbsession.is_valid?
      redirect_to fbsession.get_install_url(:next => url_for(post_install_params))
      false
    end
  end

  def post_install_params
    params.merge(:init => true).delete_if { |k, v| k.starts_with?('fb_sig') }
  end

end

Notice that the code sets the init parameter so it can be used to identify a post install call

Sometimes it is useful to do some action on a Facebook user right after your application has been installed by the user. For example, you might want to push some default FBML to user’s profile in case he does not complete the action you expect him to do after installation. Facebook application configuration allows to provide Post-Add URL to route users to the destination url after the application install. It could be a dedicated post_add action or, in case of a default action where you have some code in the controller and since Facebook limits amount of redirects you can use, it could be a parameter to the url, like &init=true, used to identify that it was a post-install action and execute on it.