Facebook is testing different designs for the mobile login process for third-party apps and sites that connect with the social platform.

In December 2012, Facebook announced changes to the apps permissions process, which separates read and write permissions into different dialogs. This means users have the option to log into an application and receive a personalized experience using their name, friend list and other aspects of their profile, but they can reject the app’s request to publish activity on their behalf.

As that rolls out across desktop and mobile, the company has been testing different versions of the permissions dialog to improve the design and performance. The following is what users will see on an iOS device when logging into a site that uses Facebook Login. After users accept the first “read” permissions request, they can accept or skip the “write” request. They can also change their default privacy setting for the app. If an app wants to manage a user’s ads, events, notifications or other products, it will have to request this in a third dialog.

A similar version appears on Android devices, as Blink VP Planning and Media Eti Suruzon shares in the following screenshots.

Compare these to the mobile design included in the image below, which was part of Facebook’s original blog post about the change in December. As far as we’ve seen, the web and native iOS 6 implementations appear the same as below.

Article courtesy of Inside Facebook

Last March, Zynga announced its ambitions to create a web and mobile platform for social games. Zynga.com is a destination for both the company’s own games as well as for third-party developers who want to leverage Zynga’s social feed and users. In September, Zynga debuting its first third-party games. And today, Zynga is rolling out a number of changes to Zynga.com, namely how you sign-in.

The platform itself allows developers to post to the stream of social gaming activity at Zynga.com, and also to include social features like chat and real-time multiplayer. One of the major changes with this update is how players sign in. Previously, you signed in via your Facebook login, and your experience was built around all your previous Zynga gaming interactions on the social network (based on your permissions). With the new sign-in, you actually sign in with a Zynga account that is created and Facebook Connect is optional.

You can still integrate all of your Facebook game boards, progress and friends, but this is no longer required. Reading between the lines, it appears that Zynga wants to continue down the road of becoming less reliant on Facebook for social interactions and more. This isn’t particularly surprising considering Zynga and Facebook’s new terms that were released late last year. As part of the agreement at the time, the Zynga.com platform was no longer obligated to use Facebook ad units and Facebook credits. In exchange, Zynga’s right to cross-promote its non-Facebook games using Facebook data and email addresses are limited by the standard terms.

Since launching, Zynga has noticed a number of things about how people are playing games on the platform, namely that people want to be challenged and they want the ability to progress faster.

For example, on the social stream, you can see who else is playing a current game (and your friends), and by interacting in the stream, you can share gifts to the community. So if you are in Farmville, and you needed a specific tool. You could share this to your social stream, and any friends could click on this to send you the gift as a reward for interacting with the stream. Zynga does keep track of how many people you have helped.

It’s not only a way to showcase the millions of players that playing with you, but it’s also a way to actually share gifts and benefit not only yourself within a game, but others. 70 percent of players on Zynga.com are interacting with the social stream, and some are clicking more than 100 times a day.

Zynga also found that interweaving ads within the stream was better for players in terms of monetization than a static ad across the bottom of the page. The company has also been experimenting with actions like watching a video ad to get through a segment of a game.

Right now, Zynga is shipping more third-party games on Zynga.com than in-house. There have been more documentation, SDKs and tools (even a help forum) added to aid developers in building games around the platform.

It’s no secret that Zynga is rethinking its approach to gaming at the moment. The company has shut down a number of once popular titles, and is releasing fewer games and spacing their releases further apart. Zynga’s Q4 saw layoffs and a continuing series of executive and mid-level departures. It’s clear this is a transition point for the gaming company, but the Zynga.com network is one of the areas that the gaming giant is doubling down. The goal is to figure out what’s sticky for both the player and the developers, and it’s a challenge to find a balance on both fronts.

Article courtesy of TechCrunch

Tired of wading through irrelevant newspaper coupons? RetailMeNot doesn’t want you to feel the same way about its massive website. So it’s just launched a Facebook app that recommends coupons you’ll actually use by pulling in your Likes and interests. RetailMeNot is the top coupon site in the US with 450 million visits a year to its 500,000 offers. The app will make sorting through them a breeze and could show off the power of Facebook for personalized e-commerce.

RetailMeNot’s app is simple enough to get mainstream coupon clippers to put down the scissors. First you give it permission to see your Likes, and then you can give it some extra help by selecting a few of your most beloved retailers. RetailMeNot then gives you a personalized feed of coupons. Click one to copy the promo code and visit the site where you’ll redeem it. You can also share a coupon with friends, or save it for later.

Over time, RetailMeNot’s app gets smarter — something your newspaper obviously doesn’t do. It learns from what you check out to better tailor recommendations of the 60,000 retailers it offers coupons for. With its Alerts feature, you can get notified when your favorite stores have new discounts.

Jag Bath, the SVP of Product at RetailMeNot’s parent company WhaleShark Media tells me that rather than being a replacement for its website, the app caters to a group of people who find deal-hunting to be an “inherently social activity”. And since it already has 2.2 million Facebook fans to promote to, gaining traction won’t be tough. It’s all part of Whaleshark’s plan to diversify and adopt the next wave of tech, which is already paying dividends as 20% of traffic now comes from mobile. The company has $300 million in funding and expects total of 450 million total visits and $125 million in traffic, up from 300 million visits and $80 million in revenue in 2011.

The app seems like such a good idea, I’m surprised how few retailers are getting serious about Facebook personalization. There’s a massive trove of data there that’s easy to get permission to access and that can drastically reduce bounce rates.

I think we’re headed squarely in the direction of minimizing the “shopping” experience. Search, category browsing, and decision-making are all exhausting — they just used to be the only ways for people to apply their preferences. But now with rich APIs powering recommendation engines, the choices are a lot closer to choosing themselves. Users are easily distracted. They’re always just one moment of irrelevant content away from going somewhere else. Many times you only get one shot to get them out of the discovery phase and into the conversion flow.

If you only have a single fold of real estate to catch someone’s eye with, don’t take a wild guess about what customers want. RetailMeNot’s got it right with this app. Sure you might lose some users during the permissions step. But if you grab the data and make a smart recommendation, people will remember how you made something stressful a snap, and they’ll come back.

Article courtesy of TechCrunch

Facebook has launched the new Notifications API beta giving developers a way to reengage users with custom messages through the native notifications channel. These notifications are different from app requests in that users do not need to allow further permissions to receive them.

Developers will find many positives to this feature as it makes it easier to reach their users. However, they must beware of the possibility of overflowing users’ notifications channel. Facebook previously allowed developers to send notifications to users, but it removed the feature in early 2010 as a way to reign in spammy apps. This time around, the social network has put in more safeguards to prevent developers from abusing the channel.

Users can accept or decline these notifications and are given the option to opt-out at any time. Facebook encourages developers to test and monitor how notifications are performing through the notifications dashboard in Insights. Developers will get information on how notifications are being received as well as turn-off rates. Exceedingly high turn-off rates may be classified as spam and will be disabled.

The company encourages developers to be mindful of the language in their notifications, suggesting that high-quality notifications receive higher click through rates than app requests. Low-quality app notifications are more likely to cause people to turn off notifications for that app all together.

Article courtesy of Inside Facebook

Some Facebook canvas games are testing a new “start now” function to let users begin playing games immediately without the roadblock of a permissions dialog.

Game developers Zynga, Kixeye and EA have signed contracts with Facebook similar to deals the company made with Instant Personalization partners like Yelp and TripAdvisor, we’ve learned from a source familiar with the matter. However, unlike with Instant Personalization, which was for third-party websites, this new program is for games on the social network.

These games — including Zynga Slingo, Indiana Jones Adventure World, Backyard Monsters and Battle Pirates, among others — will be able to access to a user’s basic profile information and friend list without requesting permissions. A blue bar above the game will allow users to opt out at any time and the app will no longer have access to their information. Early tests have shown increased installs and low opt-out rates, Facebook confirmed in a statement.

The reduced friction could help developers bring in more users who might otherwise be turned off by the permissions request. The result amounts to somewhat of a trial period. If games need additional permissions down the line, for example, access to a user’s email address, birthday or Timeline publishing, they will have to request those with a traditional auth dialog.

Facebook has been experimenting with ways to make it easier for users to try games without the hurdle of the auth dialog. The new App Center allows users to grant permission directly from an app detail page rather than through an additional pop up. In May, the company announced a test with some developers that allows them to create a short demo of their game that users can play directly from within News Feed or Timeline. However, with those in-stream games, developers do not gather any insights about the users who play them. With this latest test, partners will receive some basic information about who is playing their game and how they are converting.

The impression we get is that this is a preliminary test and developers shouldn’t expect it to roll out to all games and apps any time soon. Instant Personalization for off-Facebook sites launched in 2010, and is still only available to a handful of partners. However, if this becomes successful for canvas games, more developers might be interested in working with Facebook in this way. If users become more comfortable with their basic profile information being used to personalize websites, apps and games, the social network might eventually decide to allow some of this info to be used by default, but it’s unclear whether the majority of users would support this currently.

The “start now” functionality has only been available for a small subset of users, but it should be rolling out more over the weekend. Facebook has already updated its Help Center with information about the change.

Here’s what users see when they click “learn more” or “disable” from the blue bar as seen in the screenshot above.

Businesses using Google Apps should have an easier time managing complex tasks starting today with the launch of Kissflow from startup OrangeScape — it’s supposedly the first workflow-creator that’s “deeply integrated” with Apps.

OrangeScape is pitching this as an alternative to using email and spreadsheets to track approvals and other tasks, which can turn into a headache as the company grows and tasks get more complex. With Kissflow, businesses should be able to create workflows for things like expense reporting in five relatively easy steps: Naming the process, designing the form, defining the workflow, configure the permissions, then publish.

And of course, there’s integration with Google Apps. Kissflow customers can attach Docs directly to their workflows, and collaborate with anyone else in their Google Apps domain. The interface is meant to be reminiscent of Gmail. And for security and control, every business on Kissflow gets a separate database on Google Cloud SQL.

Kissflow will be available in the Google Apps Marketplace and will be free for up to 10 users, then cost $3 per user after that.

As for the company behind the product, OrangeScape was founded by CEO Suresh Sambandam and CTO Mani Doraisamy. It has raised a $1 million “bridge round” from angel investors (including Sharad Sharma, former CEO of YahooIndia; Venkat Raju; Pramod Bhasin, former chairman, Nasscom and CEO of Genpact; Raman Roy, CEO of Quattro; and Linda Bernardi, CEO StraTerra Partners) and plans to raise a larger $10 million round later this year.

Oh, and for those of you at Google I/O, OrangeScape will be demonstrating the product in Room 5 at 2:45pm.

Article courtesy of TechCrunch

Social marketing platform Involver found that integrating Open Graph to let users share their app activity with friends led to a 20 percent viral boost for the USA Today Ad Meter application.

The app, which presented users with a number of Super Bowl commercials to watch and rate, asked for permissions up front and then shared users’ actions seamlessly, rather than disrupting the experience with frequent prompts to share. The Ad Meter, which was the first large-scale marketing campaign to use this new type of sharing, had 11 percent of users opt in and authorize Open Graph publishing. Even with a small proportion of users enabling automatic sharing, the app significantly increased its reach.

Involver says two million video views were driven directly from the app, but another 200,000 views came as the result of people seeing their friends’ “watched” or “rated” actions in News Feed. The Ad Meter had 120 additional users for every 100 pieces of content shared from the app. Overall the app reached more than 6 million unique users through News Feed, Facebook tabs, USAToday.com and mobile devices.

Involver VP of Marketing Roland Smart says the results prove the value of integrating Open Graph. He says there several best practices developers should implement in order to increase the number of users allowing Open Graph permissions and to maximize the reach of a campaign. We have outlined his key points and provided a look at the Ad Meter user flow below. The full Ad Meter case study is available here.

1. Do not ask for permissions until proving some value.

2. Use images and a clear call to action to give users an idea of what they’ll gain by granting permissions. For example, offer transparent views of content or sample content that will be revealed after authorizing the app. Once users understand the experience, they are more likely to accept the permissions.

3. Always offer an alternative experience for users who do not authorize the app. This will keep users engaged and can provide opportunities for authorization later.

4. Use the “persistent ask” or “intermittent ask” methods. With the persistent ask, a call to action stays in view so that users can decide at any time to authorize the app. Typically, the placement is unobtrusive and near an area where authorization will improve the user experience. With the intermittent ask, the call to action is removed if a user does not opt in within a set time period but it is resurfaced after a user has engaged further with the app. This can be successful in converting users since it provides a greater sense of urgency.

5. Do not ask for more permissions than necessary to provide the intended experience. Group permissions so that users only have to authorize the app once.

6. Thank users for authorizing the application and be clear about how their activity is being shared throughout the experience.

Read more about Open Graph and how it can enhance a marketing campaign here.

Article courtesy of Inside Facebook

After a week of confused coverage around which mobile app developers access user address books and how they do it, we are finally getting a product-level resolution. Apple says today (in time to beat back some inquiring congressmen) that it will start requiring developers to ask for explicit user permission in order to access these contacts.

The new interface, slated for its next iOS operating system release, will provide a permissions notification to users after they install an app, similar to how it currently requires users to approve location sharing or push notifications. This change will add some arguably unnecessary friction to users of apps that pull address books — and a lot of developers will be affected, as 11% of free iOS apps were accessing address books as of the start of last year, according to one research report.

Beyond technical fixes that developers should be implementing anyway, the solution means that users will now at least know what’s being shared. But the problem I have with Apple’s solution is that it looks like an inelegant knee-jerk response, not a carefully planned advancement in how it helps developers build better products for users.

The reason Path as well as Twitter, Hipster and others were uploading address books with user names, emails and phone numbers was because they were trying to help users find existing friends who were also using their services. It wasn’t about reselling this data to the Egyptian government, even if that was a distant hypothetical possibility.

Recent investigations by VentureBeat, The Next Web and The Verge revealed that in fact, dozens of popular apps were accessing address books. But here’s some less anecdotal data about the scope of the issue, from Lookout. The mobile developer provides an app for iOS, Android and other mobile platforms that finds malware and other security and privacy problems within apps that users are downloading by scanning apps across the entire ecosystem. So unlike most data sources it can see the big picture here.

At the beginning of 2011, it found that out of the hundreds of thousands of free apps on iOS, 11% were able to read contacts. The company doesn’t have updated numbers available yet for iOS this year, and it’s only providing percentages, but clearly address book accessing is way more prevalent than just the few dozen apps that people have looked at so far.

The same goes for Android. Lookout’s data from last year shows that 7.4% of free apps on the platform were accessing user contacts; this year, the company tells me it’s tracking 7.1% that do.

Android is in a bit of a different position here, though, because it requires explicit user permission for contact sharing with apps before they install it. That’s more transparent, but also adds some friction.

Which brings me back to what developers are trying to accomplish. Typically, they want to help friends find each other within a seamless user experience. In Path’s case, it lets you sign in with Facebook, your address book and other sites to cross-reference them for any Path user who you’re already friends with elsewhere. This makes the service more valuable for users, which is a good thing.

Apple should be working to enable this while protecting user data in a more nuanced way, rather than just throwing in another permissions dialog like what it says it’s going to do. Facebook provides a good example of how it could do that. The social network has had to figure out how to balance friend list sharing with maintaining a simple social interface as its platform has grown over the years.

Today, Facebook shows you which friends are using an app before you install it. Imagine if Apple did this for Path and every other app in the App Store, instead of Path having to grab your address book afterwards to do the same thing.

If you click to install an app on Facebook, its permissions dialog tells you explicitly that you’re giving the app access to your friends lists (not friends’ emails and phone numbers) by default. If you don’t want to share your friends lists with the app, you don’t install it. If an app wants to do other things, like automatically share back to Facebook on behalf of a user, it needs to ask for additional approval within another permissions interface. If a developers wants to ask any user to contact friends within the app — for inviting them to play a game or whatever — it requires them to do so separately later on within the app.

On top of building in a feature that shows you mobile apps that you have in common with other iOS users, why doesn’t Apple offer a single permissions interface that gracefully explains the various permissions that apps might want, not just friend list access, but location, push notifications, etc?

I think the answer has do with Apple’s poorly-received Ping social network in iTunes. The company, for all of its amazing successes with software and hardware, just hasn’t made social features a key part of how it thinks about the world. The address book fiasco shows that when it ignores key social features, it gets itself and its developers and users into privacy issues. For the sake of its users and developer community, now is the time for Apple to focus on getting social features right.

Article courtesy of TechCrunch

Facebook is granting all developers access to a new application authentication flow today that was announced at f8 last month. Developers can now add a description of their app that will be displayed in a redesigned publishing permissions dialog. Extended permissions have been broken out into a second authentication step that explains why an app needs certain data, and lets users revoke specific permissions. Data about publishing permissions dialog impressions and accepts, sources of users, and extended permissions conversion rates are now included in Facebook’s app Insights analytics tool.

The changes will make it clearer to users what permissions they are granting applications, and give them more control of their privacy. The two-step authentication process could increase app install friction in a way that could hurt app growth. However, in the long-run, the revised authentication flow could increase user confidence in the Platform such that users become more comfortable experimenting with new apps.

Facebook has also changed the way it measures active user counts to only publicly report authenticated users, rather than all users. We’ve written a separate article discussing how this will cause a one-time dip in active user counts that does not actually mean apps have lost users, and explaining how this impacts our AppData tracking service.

Redesigned Permissions Dialog

Previously, users only had to accept one extended permissions dialog to give an application publishing privileges and access to their data. The permissions dialog didn’t explain what that data would be used for, or what the app would publish to a user’s profile. This meant users would sometimes grant privileges they didn’t understand and would get angry when they saw the app had published on their behalf.

The redesigned authentication flow aims to solve this problem. First, users see a dialog asking for permission to install the app and allow it to publish Open Graph activity. It shows users:

• The name  and logo of the app
• A tag line about the app
• A privacy selector for choosing who it can share with
• A list of the data types it requires
• An “About this app” description of its purpose
• Open Graph aggregations previews that show what it can add to a user’s profile Timeline
• A link to the Facebook terms of service and privacy policy
• A tiny link to report the app as spam
• Friends who’ve installed the app
• A “Log In and Add t0 Facebook” accept button

Developers can configure what appears in the dialog and the default privacy setting by entering the Developers app and selecting Settings -> Auth Dialog. Once they’ve properly configured the dialog, they can implement it by enabling “Enhanced Auth Dialog” in the Migrations section of the Developers app’s “Advanced Settings”. Facebook says all apps will be migrated to the redesigned dialog by the end of 2011, though it hasn’t released exact migration dates.

Open Graph app developers reorder the aggregation previews. These previews of what an app will publish represent a significant step forward in increasing transparency in the app install process. Facebook could further improve transparency by including a sample Ticker or news feed story from the app in the previews.

Separate Extended Permissions Dialog and Authenticated Referrals

Apps requiring additional, optional privileges such as the ability to publish check-ins or post to a user’s wall will display a second extended permissions dialog after users complete the initial install dialog. This step includes clear descriptions of what each permission means and the option to deny the app these non-essential privileges. Below, the dialog is an explanation provided by the developer for why it requires these permissions.

Before the redesign, users had to grant apps all the extended permissions and then dig into their app privacy settings to revoke certain permissions. This can now be handled as users install an app. Developers should reference the tutorial Facebook posted this week to ensure their apps run properly if some permissions are revoked.

This granular control may improve app install rates from users who are sensitive about a certain type of privacy, such those who don’t want to provide contact information or have content published to the stream on their behalf.

Authenticated Referrals is another option available in the Auth Dialog settings that when enabled causes users clicking a link to an app to see the authentication flow in-line being being brought to the app. This is useful for apps that require user data or permissions to function. It allows them to remove the awkward pre-permissions landing page and provide a personalized experience when users first arrive.

Authentication Data in App Insights

App Insights now displays impressions and accepts, sources of users, and the what privacy setting users are selecting for the authentication dialog and authenticated referrals. The authentication conversion rate will help developers determine if they are asking for too many or unnecessary permissions, or that they need to reword their their explanation for asking for permissions.

Extended permissions are each listed separately in Insights, and display their impressions, click through rate, and how many times they’ve been accepted. Developers can then identify extended permissions with low conversion rates that they may want to stop asking for.

The way applications use or abuse the permissions process has been a problem for Facebook in the past. Without enough transparency, some users would end up regretting that they installed an app that published or content or used their data in ways they didn’t want. They might then blame the Facebook Platform rather than the developer, leading them to avoid using applications in the future.

This increase in transparency and enhanced granular app privacy controls should give users a much clearer sense of what and with who they’re sharing. With time, Facebook may be able to remove the privacy stigma around apps and create a Platform more users want to engage with and more developers want to work on.

Article courtesy of Inside Facebook

Facebook announced several important changes this week that impact developers of apps and social plugin-integrated websites. The latest Platform update described how developers can track app feed stories using ref parameters, and listed many new metrics that have been added to the Insights table for apps and websites. A special Developers Blog post explained how social plugins can be optimized to reduce webpage load times and Insights errors.

On October 22nd, developers will gain the ability to request permission to read and manage user notifications. Developers can now alo exclude certain User IDs from seeing dialogs or limit the number of Requests they can send, and apps can be deauthorized or have their permissions revoked via the Graph API.

New Ref Parameter and Insights Metrics

Developers can now add a ref parameter to feed dialogs, allowing them to track the performance of different dialogs in Insights. Ref parameters can added using the JavaScript SDK, PHP, or the Graph API. A “story types” drop-down will then appear in news feed section, allowing developers to see all story types or just those with a certain ref parameter. This will improve A/B testing of feed dialogs, helping developers determine what dialog design causes causes users to publish the most feed stories.

Facebook has also added the following new metrics to Insights:

Websites

• domain_feed_clicks - The number of clicks sent to your site from stories in News Feed, Page Walls, or Profile Walls
• domain_feed_views – The number of times people viewed stories that link to your site in News Feed, Page Walls, or Profile Walls
• domain_stories - The number of times people posted a link to your site through an action on a social plugin or through a status message or Wall post
• domain_widget_like_views - The number of times people viewed Like buttons on your site
• domain_widget_likes - The number of times people clicked the Like button on your site
• domain_widget_like_feed_views - The number of times people viewed stories generated from Like button clicks on your site
• domain_widget_like_feed_clicks - The number of clicks sent to your site from stories in News Feed, Page Walls, or Profile Walls

Apps

• application_api_errors_rate - Average number of errors per API request from your app
• application_api_time_average - Average time for API requests from your app, in milliseconds
• application_canvas_time_average - Average HTTP response time on your Canvas page, in milliseconds
• application_canvas_errors - HTTP request errors on your Canvas page
• application_canvas_errors_rate - Average number of errors per canvas request of your app

Article courtesy of Inside Facebook