Facebook screws app developers on notifications

jamiemchale on February 21 2013


Favorite   Tweet    Share

Facebook is screwing developers of FB-integrated applications, wiping out their value overnight.

There are two main channels that a Facebook app can use to communicate with users - the Requests Dialogue and the Notifications API.

Notifications allows an app to send a message to be picked up in the notifications jewel by users that have installed their app. These notifications can be generated by the application itself.

Requests are initiated by a user, using Facebook UI Dialogs, and can be sent as invitations to non-users of the app. Requests also show up in the notifications jewel.

Facebook has turned off the Requests functionality for apps that are not labelled as games, breaking many live apps.

This means that an app that is built primarily on the Facebook platform for friendship and notifications functionality cannot now notify a potential user that their friend has invited them to that app.

Many developers use Facebook as an easy way to easily inject social functionality into their applications. Many apps rely on these Requests to grow their user-base. The apps are crippled without Requests.

Facebook want to encourage an eco-system of developers - but when one of the primary functions of a social interaction is yanked with no notice then many developers will question whether the risks of developing on the Facebook platform are too high.

The first bug reports were submitted to Facebook over a week ago - Facebook's response was to mark the changes as by design, saying:

At Facebook we run lots of tests to determine how information can best surface to users.

Our current tests are looking at the impact of reducing the number of notifications we spend for app requests to non-game canvas apps. No other app types are impacted right now. We are close to concluding these tests and then we need to make some decisions. If we have a change that will permanently impact these apps, we will make sure to give everyone a heads up with enough warning.

For these test there was no warning. Advertising campaigns have had to be suspended. Many apps are now effectively useless.

So this is a warning - develop for the Facebook platform and run the risk of your business losing its whole value over-night.

Engagement

Total View Count11764
Times favorited0

Responses (0)

+ Write a Response

More by jamiemchale

Comments (5)     + Write  a Comment

1
douglaspurdy | reply
I work on Facebook Platform. In fact, I wrote the bug response you quote above. One of the key things I want to stress, is that we never "turned off the Requests functionality for apps that are not labelled as games, breaking many live apps." We never turned off requests. We never broke a single app.

What we did do was test the impact of issuing a notification for a new app request for several categories of apps. The sending and delivering of requests still worked through this test and nothing broke. Users could still send requests and they could receive them on Facebook.

The key thing to bear in mind is that our APIs often express "intent", not specific UX actions on Facebook.com or our mobile apps. We are always testing new user experiences to see what the best experience is for a given intent from an app. Such was the case with this test.

Again, no apps were broken, we were simply testing if/when/how we should surface notifications for app requests to users.

We have concluded this particularly set of tests and if we are going to make some permanent changes, we will make sure to inform our developer community.
0
jamiemchale | reply
Thanks for your reply Douglas.

The reason I was so frustrated is that the change did have an impact on our app. Although not totally broken, the app was crippled. The notifications in the jewel are significantly more noticeable than those in the app centre.

Our app is careful not to spam people.

Our interpretation was that User-generated requests signalled an intent that was greater than app generated requests. We understand that App generated requests can be hidden by the user, and were subject to spam controls. The requests generated via FB User Dialogs were our way of growing our product and involving new people. We are building a messaging platform - and when a new user is invited that is because their friend has sent them a message.

Without some degree of reliability in notifications our app simply cannot be integrated with Facebook to the level that we hope it could be. Users need to trust that if they use our system to send a message to a friend, then that friend will receive a notification that they have a message.

It would have been great to involve app developers in these tests and provide some fore-warning of the temporary changes. I did feel a little screwed (hence the title), and we're now working to decouple our core functionality from Facebook. It's sad, as I genuinely want to use the platform as it's an excellent product!


0
BIDevAdventures | reply
This is the risk you run when using any API published in the world. I'm not happy about it but the fact is that BigCompanyA is out for only one thing, BigCompanyA, and your usage of their API benefits them first with a happy side-effect that it benefits you, as well. I suggest taking this as a bigger warning to inspect your reliance on external APIs and if the benefit outweighs the risks, which may be the case with the largest social network exposing your app to their user base, go for it.


0
scottjgalvin | reply
I'm sorry to hear this change is ruining your day, and negatively impacting your app. Is there any way you can escape from the walled garden that is Facebook and migrate your idea to a stand alone website?
0
jamiemchale | reply
Thanks for your comment Scott - yes, this weekend we're moving the stuff over to email login and changing the way people are notified. This was in the medium-term plan, as we had hoped to use Facebook features in the short term - but now it's an essential step!


Responses (0)     + Write a Response

No one has written a response to this article. Be the First!