Explicit Sharing – Advanced Open Graph #1

explicit-sharing2
[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. Since launching Open Graph in late 2011, the platform team has been very busy refining and optimizing the available APIs. Despite being in touch with Open Graph every day since more than a year, there are plenty features I’ve rarely used myself, so this is also an effort in bringing myself up to speed – come along, enjoy the ride :) This time I’m focusing on “Explicit Sharing”, which is a great way to give maximum exposure to your users’ most important actions.

Links: official announcement, documentation

Preface

When Open Graph was first introduced in 2011, it was hailed as the “end of the Wall-Post” by some, and rightly so. However there was lots of confusion on how Open Graph actions would actually work:

  • Should Open Graph actions be published explicitly or implicitly/automatic? (answer: both is possible & reasonable!)
  • Will there be Open Graph “buttons” similar to the well-known “Like” button? (answer: no! unless you build them yourself!)
  • Especially: where are published actions going to be displayed? (answer: in various places – Ticker, News Feed, Profiles)

By the sheer amount of actions published by apps like Spotify it soon became clear that Open Graph actions had to be filtered in a similar way as each users News-Feed is filtered. Enter GraphRank, an algorithm similar to EdgeRank that is trying to decide which of your friends actions to display on which channel (Ticker, News-Feed, …) at what time. The algorithm is largely a black box, but factors it takes into account most probably include the relationship/affinity between users, the number/regularity of interactions with actions published by an app,  the usage pattern of the app in general and the richness of the action (user messages, photos, location all increase the visibility).

GraphRank basically leads to this situation: Many published actions are not displayed in friends’ News Feeds or on the publishing users’ chronological Timeline, but instead will be rendered in the Ticker (heavily filtered even there) and in aggregated views on Profiles. As soon as an action receives interactivity (comments, likes, shares), it’s more likely that this particular action might appear on friends’ News Feeds or the publisher’s Timeline. For apps with frequently published actions (again, think Spotify), aggregated views for News Feed were built as well. In all this, neither the user nor the app developer has much to decide when, where and how actions are displayed – it’s largely determined by GraphRank.

Explicit Sharing

With the announcement of “Explicit Sharing” in August, this frustrating situation is finally solved. Explicitly shared actions are meant for especially meaningful user activity like uploading content, sharing a personal message or recommending a piece of content (the docs say: “anything that usually would be shared with the Facebook composer”). Explicitly shared actions are guaranteed to be displayed on the publisher’s own chronological Timeline, and will have a much greater probability to be displayed on friends’ News Feeds.

timeline-2-570x299

The Code

As of now, you’ll have to manually activate “Explicit Sharing” in the migrations parameters of the “Advanced” settings of your application:

Screen-Shot-2012-10-04-at-12.18.55-AM.png-570x244

From there on, publishing Open Graph-actions for “Explicit Sharing” is done simply by adding the fb:explicitly_shared POST-parameter with a value of true, when you are publishing an action:

curl -X POST https://graph.facebook.com/me/app-namespace:action 
-F "access_token=..." 
-F "object=http://www.domain.com/url/to/object" 
-F "fb:explicitly_shared=true"

Everything else, like the API-endpoint you’re publishing to and the parameters specifying the action’s attributes stays the same. Yeah, that’s easy!

The Approval

“Explicit Sharing” has to be approved by Facebook as an optional property on a per-action-basis. That means, if you want to upgrade existing, approved actions with “Explicit Sharing”, you’ll have to re-submit them with the “Explicitly Shared” option checked. Make sure to provide a good & consistent explanation why this action represents an explicit interaction of your users.

Screen-Shot-2012-10-04-at-10.55.29-AM.png

It’s also worth noting, that “Explicit Sharing” is currently also available for built-in actions (“Read”, “Listen”, …). Since these actions are mostly used for passively shared content, I’d assume that an approval of “Explicit Sharing” may not be that easy to get in these cases. The documentation specifically rules out the following kinds of actions for “Explicit Sharing”:

  • Actions that occur naturally in an app, such as listening, reading, watching, and using
  • Lightweight social buttons, such as liking, loving, favoriting, and saving
  • Low-signal activities that happen in bulk, such as following, friending, and passing
  • Functional parts of game play, such as playing, earning, building, and gifting

As the general Open Graph-terms point out, your users should always have the possibility to undo their published actions easily. This is especially important for explicitly shared actions. Of course you can provide users with an easy way to manage their published actions using the new Shared Activity plugin which lists all recent actions and allows users to delete them with a click. That’s fine enough, but we’d definitely recommend to go the extra mile and provide users with an “Undo” link/button placed near the particular piece of content. Examples from our apps Mein Klub and Last.fm Scrobbler:

undo-2.png-570x318

The Big Picture

When measuring potential exposure of published actions, “Explicit Sharing” is on the exact opposite of what came to be called “Passive Sharing” (it used to be called “frictionless sharing”, but that seems decades ago). “Passive Sharing” was originally the concept championed of many 2011-launch-time show cases of Open Graph, namely all the Social Reader-apps (Washington Post, Guardian etc.) and of course music apps like Spotify. The premise is simple: Content consumed by users, – be it audio, video or news – is (with users’ consent!) automatically published to their Timeline along the way. While this seems to work great especially for music, the sheer amount of published actions meant that these signals had to be filtered down and to a large amount be migrated from the News Feed (still the most important engine of viral distribution) to the – then-brand-new – Ticker. Don’t get me wrong – Ticker is a great driver of traffic, but it pales compared to News Feed. Here’s a real-life example of our app Last.fm Scrobbler f. Facebook:

Screen-Shot-2012-10-03-at-11.19.34-PM-570x215

While Ticker notably drives 20% of traffic, News Feed with more than 64% of all referral traffic is still king (also worth noting: Profiles – which definitely have been upvalued by the switch to Timeline – drive 16% of traffic). This is especially true when considering that News Feed only accounts for 32% of all impressions. The bottom line: As a developer, you want your most important actions go to News Feed for maximum exposure.

Moreover, there are strong signals from Facebook indicating that passive sharing is going to be marginalized by platform. Earlier this year, Facebook made a deep cut into the viral growth of Social News Readers by downgrading the display of “Trending Articles” published with the built-in “Read” action, dramatically changing the they way these stories are displayed in aggregate on News Feed (reported by BuzzFeed first, later explained on TechCrunch):

recent-articles-2.png

While the original display included several articles with social context (profile images of your friends who have been reading the articles displayed), the new box displays only one story at a time while omitting who has actually been reading the article. This has, of course, resulted in the decreased growth of Social Readers as reported by BuzzFeed. Recently there’s even been some on-the-record confirmation of this change in strategy by Facebook’s Manager f. Media Partnerships, Andy Mitchell at a panel (reported, again, by BuzzFeed, who as someone drawing big benefits from their great Open Graph-integration certainly have an interest in the topic):

The Bottom Line

For developers using Open Graph, the message is quite clear: for content-heavy apps, use built-in, passively shared actions like “Read”, “Watch” and “Listen” as a great way for users to share consumed content on their Ticker and build their identity on Profiles. But don’t stop there! Modeling custom actions (we recommend aiming for 5 different custom actions) along the interaction paths users might take in your app will give you much greater exposure on News Feed, especially when emphasizing the most important actions with the “Explicit Sharing” attribute. Make sure to use built-in actions “Follow” and “Like” when appropriate! Need some ideas on what kind of interactions that might be? For content-heavy apps, let your users recommend, rate or comment on stuff. Let them build favorite lists to share with friends or simply highlight content they’ve created themselves. And always remember: “Explicit Sharing” is not meant to be used in bulk, don’t be spammy! One more thing: often neglected, don’t underestimate the power of building rich & nice aggregations (see traffic-example above)!

Have some feedback on my post or want to share your experience with “Explicit Sharing”? 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 “How to cross-utilize Action Links” or “Solving Authenticated Referrals” – so be sure to subscribe and don’t miss a post!

Comments

  1. Reply

  2. […] last week’s post on Open Graph “Explicit Sharing”, I’ve pointed out how explicitly published actions are favored over passive sharing when it […]

  3. […] and that’s 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 […]

  4. […] last week’s post on Open Graph “Explicit Sharing”, I’ve pointed out how explicitly published actions are favored over passive sharing when it […]

  5. […] and that’s 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 […]

You (dis)agree? Leave a Reply!