Since Facebook recently started testing its new Facebook Credits payment system with three applications, there’s been a lot of interest from developers in trying out the new service. Although Facebook isn’t taking signups at the moment, last night Facebook put out a notice letting developers know that they can go to this form to express their interest in participating in future tests.

We’ve heard a lot of developers are interested in learning more about the current Facebook Credits alpha test.  At the moment we are not accepting additional partners into the alpha, but we are collecting names of interested parties for potential future beta tests of this feature. If we test this feature further, we’ll be testing it with applications of varying user bases, business models, and functionalities – there is not one particular kind of application we would be looking for.

Please sign up here to register your interest: http://facebookcredits.questionpro.com/

Thanks,
The Facebook Platform Team

However, Facebook doesn’t make any indications of when exactly the test may open up to more developers in a closed “beta,” or when we will see a fully open launch.

As for the survey itself, most of the questions aren’t particularly revealing about the direction the system might be headed. However, the last does make a note about terminology:

Do you currently use the term “credits” in any of the applications you listed?

Facebook has been very strict about the use of terms that they see as linked to core features in an effort to limit the confusion of users between the site and applications that run on the platform. “Wall” and “poke”, for example, are forbidden terms and there are restrictions even on more common terms such as “message”, “status” and even “friend.” Could we see “credits” added to this list in the future? It seems possible, and developers of games with virtual currency systems may want to make a note of it.

For performance advertisers, unexplainable differences in delivery rates happen all the time – and have a big impact on the bottom line. However, today, Facebook has issued a note to advertisers in the Facebook Ads campaign management dashboard letting them know to expect lower traffic today. Advertisers may be seeing the following notification:

There is a large targeted campaign running 6/8/2009 that may impact your delivery for this one day if you are targeting the same users. We advise that you do not drastically change your bidding behavior.

There’s no mention of who the campaign might be for, or what the targeting segments are that it will affect, but the message is interesting and helpful nonetheless. A large campaign like the one Facebook describes is likely to push up the minimum cost-per-click (CPC) bid that any other advertisers with campaigns affecting the target segment would need to enter in order to ensure that their ads are shown. As a result, many advertisers may see lower impressions and clicks today.

It’s particularly interesting that the notification has been put out as it’s not necessarily something Facebook is duty-bound to communicate. Without it advertisers would likely interpret a drop in impressions during the day as a need to up their CPC bids. The one-day spike would result in a short-term financial gain for Facebook, as bids across the board would rise, but may have resulted in advertisers eventually decreasing their spend if advertising suddenly become less cost-effective.

The notice should help advertisers to interpret any traffic dip as a one-day event and reassure them that Facebook is likely to be open about future events that may affect them.

It seems that the programmers at Facebook have embedded a small Easter egg into the site. (An Easter egg is a secret embedded by the developers.) To find it:

1. Log in and go to the homepage (although many other pages seem to work this one’s certain)
2. On the keyboard press: up-up-down-down-left-right-left-right-b-a-(enter)
3. Click anywhere on the page, and you should see a lens-flare effect

The effect works in Internet Explorer, Firefox and Chrome but doesn’t appear to be supported by Safari. Once the effect’s working, try typing into a comment box to get a more persistant flare.

Is this just one of many yet to be discovered?

There were two sides to the stream APIs that Facebook released yesterday: getting data, which we’ve looked at, and publishing and updating. The latter has the potential to really open up Facebook to external sites, and although it’s only available to application developers at the moment it’s worth taking a look at how it works.

Trying to entice a user to give you permission to update their stream via your application or Connect site is as simple as it is for reading: there’s a simple piece of FBML which can be presented as a text link, button or other HTML element that prompts the user to grant an extended permission:

<fb:prompt-permission perms=”publish_stream”>Grant permission to publish to my stream</fb:prompt-permission>

Clicking on this brings up a similar dialogue to the one that granted permission to read but with the direction arrows representing the flow of information reversed to indicate information will be flowing from the application:

As before, this is fairly clear and shouldn’t cause too many users to turn back at this point (assuming this permission is something that they want to give). The proportion of users that will be happy to grant this permission will obviously depend on the application in question. As always, there’s a value exchange and users are unlikely to grant access without concrete benefits.

Should there be wide-scale misuses by applications, as there have been with other Facebook Platform features, then there’s also the danger that permission granting will be controlled by users as much as story publishing is currently – i.e. they’ll refuse/disable it wherever they can. It’s up to developers to make sure the power it provides is used to add value to the Facebook experience and isn’t discredited through abuse.

The ideal end-game for developers will be that the permission is granted by default as part of initially authorizing an application. Although this is unlikely to happen to this degree it will be interesting to see if valid uses of the feature prompt Facebook to raise its prominence e.g. by making it an up-front, but still opt-in, option when authorizing an application.

Once a user has granted permission the level of control available over the stream is quite powerful. Facebook provides a number of key interaction points:

• Publish to the stream. This is very much the same as the current stories that appear when a user chooses to publish from within an application. This is equivalent to the user granting permanent permission to publish feed stories so in itself is not a new interaction point.
• Remove items from the stream. Users can control of their own stream by removing items that they themselves have published, but only with the application they’re currently using. These will then disappear from both their own and their friends news feeds. The limitation to the calling application may restrict the usefulness of this call.
• Add comments to existing items. This is done by retrieving a unique ID for each post in the stream and simply making an API call with the comment and the post’s ID. It appears instantly in the owner’s stream, whether it’s the original user’s or one of their friends or even a Facebook Page
• “Like” existing stream items. As above, this is just the same as if the user had performed the action directly and inserts a “like” next to any specified item in the stream
• Remove comments and likes. Only the user’s own comments and likes can be removed, for obvious reasons.

The stream publishing API is one of the more powerful features that Facebook has released since the start of the platform. It will be interesting to see whether users grant applications with the permission that’s required to make use of it, and whether new and innovative uses beyond simple re-styling of the stream or porting to an external website (which are obvious first steps) start to appear.

While the publish feature is still in beta, there’s no date on when it will be generally available beyond a note on the Wiki stating “This method will be available soon.” More technical information can be found on publishing to the stream can be found on the Facebook Developer’s Wiki.

The new stream APIs that Facebook announced today appear to offer a rich level of data interaction between Facebook, applications, and external sites. So how does it actually work, and how do you go about implementing it?

The first step is to persuade your users to grant extended permissions to your application. Previously the extended permissions covered more abstract topics such as allowing an application to access a user’s data online (which may mean little to most users) or to allow e-mails to be sent (which users may be reluctant to grant). The stream, however, offers a lot more benefit to the end user and so could bring this feature of the Facebook Platform into more regular use.

Getting the special permission to be able to read a user’s stream data is as simple as persuading them to click on a link. The FBML tag is as follows:

<fb:prompt-permission perms=”read_stream”>Grant permission to read from my stream</fb:prompt-permission>

and can be styled as the developer wishes i.e. as a button, or possibly even a graphic. This pops up the dialogue box below, which not only describes what this means to the user but has a helpful illustration of the direction data moves in, and some example posts from the user’s own feed:

Although ideally (from a developer’s point of view) this would be the default setting and all applications could read from the stream once authorized – it is a possibility that this will be the case in the future – if given sufficient incentive to click on the link, users who start this process shouldn’t be too confused as to what they’re agreeing to.

Now you have all the permissions you need to read the stream, what can you pull back? So far, it looks like very little is off-limits. Not only links, posts and status messages are available but also feed stories from other applications – the first time this kind of cross-application data-sharing has been possible. I generated a story using the Living Social “Top 5″ application and immediately this item appeared in my stream.get API request, complete with links to all of the media in the story, it’s text, the name of the application and comments and “likes” from friends. In theory, I could take this feed story and re-present it in my own application, styled in a way of my own choosing.

As well as just pulling back all the most recent data, the stream can be queried on a number of data levels:

• The user the feed item belongs to.
• The user, or even Facebook Page, that generated the content. (The stream contains user and Page information and treats them equally.)
• The type of content, which may be an application story or link. Stories from only particular sources can be retrieved, allowing the generation of filters by application or content type
• Date and time information. Stream items can be queried between particular dates, or just retrieve the top 20, 50 or more

Once the call is made a large set of data is returned, including:

• The user the story appeared to
• The story content including links to files, attachments and images
• The publisher of the content (whether user or Page)
• Comments attached to the story (although only a selection are shown)
• The number of “likes”

There are a host of other data points transferred and this is certainly more complex than many of Facebook’s other feeds, although the documentation is relatively complete already. The data above, and more, could be put to a number of users including creating more subtle or sophisticated filters than Facebook offers, showing general feed content in applications, filtering the stream by application type, and of course to display the Facebook stream on external sites or in external desktop applications. The potential is here not just for existing Connect sites and Facebook applications but for a whole new set of applications to be developed.

The Facebook Platform Team appears to have banned an unruly developer from the Platform by disabling all of their applications.

Users started noticing that “Elven Blood” and other games by Patrick Shyu (who built apps under the moniker Royal East India Trading Company) had stopped working over the past few days. The Facebook page for Elven Blood is still live, but the game itself looks to be gone for good.

There are no confirmed reasons as to why the applications have been taken down. However, other application developers have previously complained about Facebook Platform terms of service breaches, like cross-promotion of applications through notifications. Prior to the application’s removal “Elven Blood” had around 240,000 monthly active users according to AppData (see this review from Inside Social Games last fall).

Although action has been taken against applications in the past, either through temporary or permanent removal, this may be the first time that such action has been taken against a set of applications, especially ones with such large numbers of users.

The Facebook Platform Team also appears to be keen to track down any more applications by the same developer:

“If you have evidence of any apps still available on Platform that are operated by Patrick Shyu, then please let us know.

To reiterate an earlier post, there are more enforcements on Platform than you are aware of, since Facebook does not publicize enforcement actions.”

The London Facebook Developer Garage is taking place tonight, Wednesday April 8th, at 45 King William Street, London. The doors open at 6pm and there’s free beer and pizza provided by Sun. Tickets cost £7.50 (£4.50 for students) and are available from EventBrite or at the door.

This month the event includes talks on social games and Facebook Connect for iPhone, as well as a panel on application monetization. Speakers include:

• Hidden Pixel (authors of PetPupz) and Kramaley Games on their experience of monetising their apps
• Clara Shih, author of new book, “The Facebook Era“
• Dan Borthwick, Head of Multi-Platform Technology at Playfish, speaking about the new Facebook Connect for iPhone
• Representatives from OfferPal Media, Social Cash and AdKnowledge on how to make money from applications

The talks will be followed by a 20 minute Q&A session, plus there’s the usual time for networking. Info can also be found on the Facebook event page.

Facebook’s Gareth Davis said at the GamesBeat conference in San Francisco yesterday that the company is “looking at” a virtual currency system of its own, according to the LA Times. However, despite what the LA Times suggests, it may be a little premature to assume what that means exactly, given that the company has been “looking at” doing a Platform payment system since late 2007 that has yet to launch.

Universal virtual currency, however, could make a lot of sense for Facebook, especially given the recent “virtual credits” system that was introduced in Facebook’s own virtual gifting system. In this scenario, users would buy blocks of Facebook virtual currency directly, and then be able to use them in various ways in both Facebook’s own virtual gifts store or in third party applications. Hi5 announced a similar universal virtual currency program two weeks ago for developers on the hi5 Platform.

A large virtual currency and payment ecosystem has been growing on the Facebook Platform over the last two years. Many games and other applications are already monetizing well through their own virtual currencies, either through offer providers such as OfferPal, Super Rewards, Peanut Labs, and Gambit, direct credit card or Paypal/Amazon/Google payments through providers like Jambool and Spare Change, or mobile payments through providers like Zong and Paymo.

The opportunity to plug into a virtual currency system that would be available to every Facebook user would certainly be interesting to many developers. However, neither building a global payments platform nor managing a universal virtual currency are small tasks.

Should Facebook launch a virtual currency system, the dynamics of how it would affect existing monetization systems would heavily depend on the implementation – both from a user experience and a technical integration perspective.  However, ultimately, things will simply come down to whichever option can make the best returns for a given application’s user base.

Facebook has recently started mixing more recommended Facebook content based on friend profiles in with the Social Ads that appear on the right hand side of application pages and many other pages within the site.

“Suggestions” that appear (see right) include Groups that friends are members of, Pages that a friend may be a fan of, or even Events that friends are attending. Friend suggestions can sometimes appear here too.

The suggested content is interleaved with Social Ads on a fairly random basis. It’s fair to say that it makes the whole area much more attention-grabbing, especially since the name of the friend that is a fan of a page or a member of the group being recommended is shown.

The advertisements shown below recommended content are labeled “Sponsored” in the bottom right hand corner of each one, but other than that it’s hard to distinguish between ads and real social data. The presentation is reminiscent of some of the ways Google used to interleave sponsored results in with natural search while they were trying to arrive at a definitive approach.

This is likely one of the many tests Facebook is conducting to increase engagement and ad performance on the site. Yesterday, Facebook announced it is also testing a new in-house ad network for developers.

The first Facebook Developer Garage of 2009 is taking place in London on Wednesday evening at 45 King William Street, London. The doors open at 6pm and there’s free beer and pizza provided by Sun. Tickets cost £7 (£4 for students) and are available from EventBrite or at the door.

There’s a busy line up of speakers and networking sessions as usual, including:

• Cat Burton from Moshi Monsters will talk about their experience with Facebook applications
• The latest on the MySpace platform from Chris Thorpe
• Huddle will discuss their experience on the LinkedIn platform, and how this compares to Facebook
• Victoria McEvedy will discuss ‘The law and social networking: third party applications’
• Mark Baker from Sun / MySQL tells us about meeting Facebook’s scalability challenges, and scaling MySQL apps.
• Dan Lester, CTO of The iPlatform will discuss frameworks for launching applications on multiple social networks
• Santosh from TwitBlogs talking about their experience building an Open Social container

The events usually attract a mix of application developers, new media agencies and internet entrepreneurs. You can find out more and check out who’s attending on the Facebook event page.