Passive Sharing & The End of Authenticated Referrals – Advanced Open Graph #2

[tl;dr] In the “Advanced Open Graph” series of posts I’m going to shed some light on lesser known or very new and therefore not as widely used features of Facebook’s Open Graph platform. This week we’ll cover a very recent change in policy regarding passive sharing & Authenticated Referrals.

Links: official announcementroadmapcoverage
Screen-Shot-2012-10-11-at-1.00.00-PMIn last week’s post on Open Graph “Explicit Sharing”, I’ve pointed out how explicitly published actions are favored over passive sharing when it comes to distribution in Facebook’s News Feed. Little did I know that the platform guys at Facebook would be releasing a significant change in the Open Graph policy only few days later. :) In an ongoing effort to improve user experience, Facebook is going to restrict automatically published actions when consuming content (“passive sharing”) to their built-in actions “read”, “listen” and “watch”. Apps which have been using Open Graph rather aggressively won’t be able to continue doing so. Examples that come to mind are Foodily (“User X found food Y”) or Rotten Tomatoes (“User A checked our review B”) which have been publishing custom actions without most users being aware of it until after the fact. On the other hand: social readers or music apps like Spotify which are using the official, built-in actions (“read”, “listen”, …) will still be allowed to do passive sharing, the rationale being that users have a clear understanding that the very nature of these apps is to share consumed content with their friends. Moreover, the approval of these built-in actions is more strict and (especially for “watches” and “listens”) requires the app owner to also cover legal legitimization on the published content.

For all custom actions this change in policy means that developers are required to model sharing experience around user intent and explicit actions. Simply put: developers should only publish custom actions when the user did some significant interaction with your app, like leaving a rating, loving/liking a piece of content etc.

Key Facts:

  • Passive sharing (i.e. automatic publishing when consuming content) will only be allowed for built-in actions (“read”, “listen”, “watch” etc.).
  • Developers are required to change the sharing experience for custom actions. Sharing should always be triggered by a clear user intent or user action.
  • These changes will be enforced by policy & approval process for both existing and new actions (there’s no technical way to enforce this).
  • Authenticated Referrals will be discontinued.
  • The ability to post on a friend’s wall through the API will be discontinued (although invoking the feed dialog will still work!).
  • These changes in API & policy will go into effect 90 days from now (around January 10th, 2013). The roadmap hasn’t been updated accordingly yet.

Authenticated Referrals
Screen-Shot-2012-10-11-at-1.00.22-PMWith the launch of Open Graph, Facebook enabled developers to configure their apps in a way that ensured that all referred visitors were first authenticated by installing the app. For early Open Graph apps, Authenticated Referrals were a very powerful way to get the viral loop going. Every referred new user would again spread content by passively sharing the peace of content that attracted them in the first place. This worked especially great for well known & trusted brands like Washington Post Reader and Spotify (and it really made sense in these cases, as the user actually expects this kind of behavior from a “social consumption” app). For lesser-known apps, the free viral distribution came with the cost of dramatically lowered CTR on the Auth dialog. In many cases, even with perfectly reasonable brands and detailed app descriptions, we measured CTR as low as 15-20%. Turns out users like to see the content or app before authorizing it. :)


The Bottom Line
Untitled-1 (1)Authenticated Referrals lured many developers into driving traffic by passive sharing in cases where it really was inappropriate from a users point of view. Low CTR always left developers wondering if the viral distribution was worth the bad user experience, so I’m glad this will be sorted out by policy. Together with restricting automatic sharing to very few specific use cases which are regulated by the approval of built-in actions, this change in policy will eventually lead to better user experience and better acceptance of Open-Graph-enabled apps. Don’t get me wrong: when implemented properly and with the users’ perspective in mind, Open Graph apps have been great before this. What Facebook is actually doing here is giving developers a soft nudge to build apps the way Open Graph was originally intended to. That said, there will be edge case apps which are clearly considered “social consumption” but don’t fit the built-in actions for some reason – these apps will have a hard time complying with the new terms of Open Graph.

By the way: All that was said in Advanced Open Graph #1 – Explicit Sharing is still valid: The key to creating successful Open Graph apps is modeling meaningful custom actions, enable explicit sharing & user messages where it makes sense, augmenting actions with location, images etc. – more on that coming up next in this series … :)

Have some feedback on my post or want to share your take on the change in policy? Comment below, I’d love to get into conversation!

Like this post? Become a fan to get regular updates on “Advanced Open Graph” – in the pipeline there’s stuff like “Rich stories – Optimizing Open Graph” – so be sure to subscribe and don’t miss a post!

No Responses

  1. […] fine. If you followed all of the Open Graph Tutorials, Checklists, Michael‘s blog posts, and if you are an eager PMD developer, there should be no problem at all to pass the approval […]

  2. […] fine. If you followed all of the Open Graph Tutorials, Checklists, Michael‘s blog posts, and if you are an eager PMD developer, there should be no problem at all to pass the approval […]

Leave a Reply

Your email address will not be published. Required fields are marked *