Why Apple Game Center is a Fail

The other day, our team was checking out the new game center features and did a quick integration with one of our games just to see how well it worked. Real time, check. Asynchronous, check. Worked beautifully. So why does no one use it? Why are we still cramming the Open Feint SDK into our games?

First of all, the funnel is broken. To ask a user to create a second identity on top of their existing Apple account is a problem. 80% (perhaps higher) of people will probably not get past this step. It is much more beneficial to use Facebook connect (which will also have a huge drop-off, but at least the user doesn't have to create a new identity and has the benefit of a large social graph.)

The baffling part here is why the user needs to create a new identity at all. I don't like to rant without also proposing solutions, so here it goes.

1. Don't make the user create a new identity.
2. Give them a one-step process to make up a public-facing name, and maybe a few privacy options. Send them an email and save the bells and whistles for an always-visible settings button somewhere.

Second, the experience of actually using Game Center is jarring. Games are by design an immersive experience, whose primary goal is to bring a user into a state of "flow", or as the film industry calls it "the suspension of disbelief". The user demands consistency to remain in this state, and that green poker table pop-up will ruin the experience for pretty much anyone. The solution here is simple:

1. Don't provide a standardized look and feel, or standard interface. Make the developers do the work of integrating the leaderboards and achievements into their games directly. If it isn't integrated into the core game experience it might as well not be implemented.

App discovery is something that has never really worked for Game Center, or really any other platform for that matter. If anyone has the highest chances of solving it, it is someone with access to good data on how users use apps. Ideal solution:

1. Make the first page in the app store like the first page on Amazon, and suggest things that are highly relevant to the user. There is absolutely no reason that this experience should not be next to perfect. A list of top apps is possibly the last thing anyone needs to see.

Overall: Privacy is a big concern these days, but it  shouldn't stop us from creating personalized experiences for users. Instead of going to one extreme, compromise and come up with real solutions.

Facebook Credits and Premium Currency - Overstepping Bounds?

 At the end of the day, Facebook is a platform. They have every right to control what happens within their walls, and should be expected to profit off it. Facebook Credits, which will soon be mandatory, are essentially a 30% tax on all transactions that happen on the platform. Although on the surface level this is a reasonable proposition, there are some drawbacks which I hope to expose in this post.

Problem: Alternate-Payment Accessibility
Not everyone can pay through the methods provided by Facebook. In some countries paying by phone is the way to go, and to have the user jump through multiple steps before even arriving at an alternate payment option is guaranteed to lose users, and lose payments. Facebook needs to do a better job at providing payment options and offers for all markets. Unless they can effectively cover all the options previously offered by the competing payment providers they are shutting down, it is bad for the ecosystem

Solution: Allow At Least Two Competing Alternate-Payment Providers
Allow multiple payment providers to compete on the platform. Currently, TrialPay is the only alternate payment system available on the platform. They enjoy staggering volume regardless of whether or not they give good payouts to the developer, an optimized user flow, or optimized offer wall. Allowing at least one other alternate-payment provider, and allowing the developers to choose it would create healthy competition that would be good for everyone.

Problem: Free Credits
A major problem with Facebook credits, is that the market is flooded with "0-value" credits. This means that the user can trade in credits which they did not pay for, for virtual goods that the developer is expecting to receive real money for. At the end of the day the developer might find out that 50% of the money they thought they were receiving is in fact worth nothing. Upon first glance, you might think this isn't a big deal since the virtual goods don't cost the developer anything. In reality though, there are some very significant costs that go into selling virtual goods.

1. The cost of building a game world which is what gives the virtual goods real value in the first place. (This can cost from hundreds of thousands to millions of dollars - yes, even for a seemingly simple game like FarmVille)
2. The cost of maintaining a game. (Engineers, Artists, Managers, Servers, Bandwidth, etc.) For a small studio running a single game, this can easily run in the hundred-thousand dollar range each month.
3. The cost of marketing the game. (Advertising, Press, etc.)

Solution: Trade in Fake Credits For Marketing Credits
Allow developers to trade in the free credits for an equal value in marketing credits. This will at least avoid the issue of devaluing the investment in buying Facebook ads. It is up to the developer to offset the other costs, but by purchasing advertising at-cost, and being forced to accept a fake currency as payment is an unreasonable business relationship.

Problem: Credits as The ONLY Premium Currency
The concept of premium currency has been around since the beginning of games on Facebook. Mob Wars Favor Points, FarmVille Cash, etc. Generally, the only way to earn premium currency is by spending real money in a game, or by completing a rare task such as leveling up. Facebook essentially wants to take away this type of currency from the developers. They are carefully offering incentives to developers that conform to this request. Their goal is to make sure users keep a balance on Facebook, NOT inside of games. This could potentially increase the value users place on credits, while making it harder for developers to collect bulk payments.

Problem: Loss of Developer Control
Every game is different: pacing, incentives, etc. all play into how the game is played. By taking away the ability for developers to seed their users with premium currency, the experience for the user will inevitably end up less-than-optimized.

Solution: Stop Being Greedy
Focus on building the ad platform and payments platform, and not on overreaching policies. Get rid of the incentives for games that integrate credits as a premium currency. Incentives are already aligned with the developers, no need to push it. The idea of keeping a balance on Facebook vs inside of games is a poorly thought-out and greedy policy that will end up making everyone less money overall. Let the games run free and reap the benefits.

Facebook Requests - Incentivizing Apps to Create Bad User Experience

It's no secret. Users love gifts. But they hate navigating between page after page just to accept all of them. This post describes our unfortunate journey to improve this experience for users, only to find that the current API allows only a mediocre compromise.

Status-Quo Flow
Currently the process for accepting and receiving requests looks something like this:

1. User receives requests from friends
2. User visits Facebook Requests page and clicks "Accept"
3. If more requests remain, repeat step 2

This may not look bad, but repeating this process even a few times in one sitting can be both frustrating and time consuming. The fact is, this happens tens of millions of times each day by users across the planet, wasting millions of hours of human productivity, not to mention the increased energy cost of running the thousands of servers required to support this inefficient process. So why do apps do it? Because Facebook gives them a strong incentive to.

Every time a user clicks "Accept", Facebook marks this as a positive response towards the application. Ignore or block, and they get a negative mark. The number of total requests an app can send per day is limited by the ratio of (total accepts) / (total accepts + total ignores). So the incentive for app developers is clear: Get as many users to click "Accept" as possible, by sending existing users things that they are highly likely to click "Accept" on, such as free gifts.


A New Hope
Facebook recently released a new API call which allowed developers to "Delete All Pending Requests". This is great we thought, no more tedious accepting for each request! We then gave our users a single page where they could mange all outstanding requests with a single click. Our users overwhelmingly loved and adopted this method, and it looks like this:

1. User receives requests from friends
2. User visits a single landing page which shows ALL gifts and invites on one page, with a checkbox to accept or ignore any given request
   
3. User clicks "Accept Selected", and all corresponding requests are accepted in the game, and all Facebook requests are deleted as promised. No return to the Facebook requests page is needed.

On the day we released this, our accept count was twice the size of our biggest day EVER. And we released it at around 6pm PST. And we did it with about 4x less load on Facebook's servers.

Shattered Dreams
To our horror the following day, we noticed an immediate and substantial negative effect on our allocation limits. Because our most active users no longer needed to accept each and every request, our total accept count fell dramatically. Our total ignore count stayed about  the same, because users who click ignore generally do not visit the app either way.

Our goal has always been to align ourselves with Facebook by offering the best user experience possible. In this case, creating a hands-down awesome experience had a clear and significant negative effect on our application. We now receive daily complaints about our request limits being so low, and getting them back is an uphill battle.

Proposed Solution
Separate accept rates of users into the following buckets:

• Bucket A - Existing Users (app already installed)
• Bucket B - New Users (app is not installed)

Bucket A will have an accept rate of around 90%, because users who understand the game are much more likely to accept the requests.

Bucket B will have an accept rate of around 5-15%, because the only incentive to accept a request is the new user's interest in the application.

The current system lumps together both of these requests into a single bucket. Currently, developers are incentivized to send huge volumes of requests that fall under Bucket A, to "mask" the negative low accept rate of Bucket B.

This could be easily solved by setting request limits based purely on Bucket B. The new solution would create an environment that favored user interest over masked incentives.