Facebook Graph API – Post Versus Link

Difficult Choices. (Photo by Beppie K, cc-by-nc-sa license)

Over in the WordPress Support forums for WPBook, WPBook user TheCitizen was asking about the absence of “share” links on Wall Excerpts posted via WPBook. I responded that in my experience posts made via the API (by an App, rather than by the user directly) don’t get “share” links inside Facebook.

He pointed to Facebook Page Publish, a WordPress plugin which also cross-posts to Facebook (though it does not import comments). Posts made via this plugin do get a share link.

Digging in a bit, I realized that Facebook Page Publish uses the Link object in the Facebook Graph API, whereas WPBook and WPBook Lite both use a Post object.

What’s the difference? That’s what I’m trying to determine now.

Links are posted with these fields (ref):

The rest of the values “are taken from the metadata of the page URL given in the ‘link’ prarameter.

Posts are created with these fields (ref):

So Posts are more complex than Links, whereas Links rely on getting the Facebook metadata from the page returned by the link.

How does each appear, on the timeline and in the news feed?

Here’s the same link, posted twice, using the Facebook Graph API explorer – the first time (the lower box) is as a Link, the second time is as a Post:

That is how they look on the timeline – logging in as another FB user and looking at News Feed, I could not even see the Post type, only the Link type:

Though I’m certain that in the past I have seen items in the newsfeed which were posted as Posts. (Maybe it was that I’d just posted the same link as a link, so Facebook was hiding the second item as spam? I’ll retry with something different).

(Update: here’s what a Post type object looks like in the Newsfeed – the item for this blog post):

A few things to note:

Given all this, plus the fact that I found it hard to find the Post type in the newsfeed of an account I know follows me, I wonder if we shouldn’t switch to posting blog posts as the “Link” type.

The challenge is that the “link” type depends on the target blog having the right open graph metadata in place already (unless wpbook / wpbook lite try to actually provide that metadata).

When Facebook visits the link, it looks for Open Graph Metadata – which your blog’s theme may or may not provide.

Using the “Post” object allows WPBook / WPBook Lite to control the message being sent to Facebook more explicitly, rather than relying on metadata.

The part that worries me though is how frequently “Post” type objects get into News Feeds. Since Facebook controls the algorithm which decides what, out of the hundreds or thousands of possible posts in any given user’s feed, to show that user, I have no way of knowing whether object type (Post vs Link) has any impact.

Anyone have data on that to share?

Did you like this? Share it:
13 Comments. Leave a comment or send a Trackback.
  1. #1 • Laurent J.V. Dubois said on January 5 2012:

    Great question and article John !

    About the SEO impact, I’ve just launched a discussion about your article and this question on the FB developers group, perhaps some other dev. will be able to help us with relevant feedbacks.

    The key point is already to have a complete Open Graph implementation, because the application isn’t the only traffic generator, and Google+ take care of Open Graph informations too.

    Best Regards,

  2. #2 • Steve said on January 5 2012:

    Interesting bit of research. Its become obvious that posting through the API has inconsistent results and FB have openly admitted to playing with their feed algorithms on more than one occasion . I think I might have a play with wordbooker’s publishing methods and see if it has an impact on the insights.

  3. #3 • Steve said on January 5 2012:

    Actually its all very odd John because “link” objects use the same post url (/profile_id/feed) but only have the link and message fields (and none of the other fields) so actually I suspect that they’re the same thing – and certainly if you implement the call by taking the normal “post” action and stripping everything out until all you have is link, message and access token you pretty much get the same result on the target wall.

  4. #4 • John said on January 5 2012:

    Steve – also interesting is that the Facebook Page Publish plugin seems to post to ‘https://graph.facebook.com/user/links’ – using the “links” connection of the user rather than the /feed connection.

    Maybe that’s just an allowed but deprecated behavior?

    On this Facebook documentation page: http://developers.facebook.com/docs/reference/api/

    Look at the Publishing section – they do say that an HTTP POST to the /links connection of the user object is allowed.

    But then on this page: http://developers.facebook.com/docs/reference/api/user/

    Of course they say you post a link by using the /feed connection.

    I wonder if there’s a difference between the two calls – the one seems to accept more parameters than the other.

  5. #5 • Steve said on January 5 2012:

    And another one from me – application made posts can have a Share link : Wordbooker does (its user selectable between “Read Full Article” and “Share”) – its all defined in the actions object

  6. #6 • John said on January 5 2012:

    Note that according to http://bugs.developers.facebook.net/show_bug.cgi?id=19336 the /links is a valid connection for posting links – and that the reason people prefer this over /feed is that you get a “share” button this way.

    (Note the lack of the “share” button on the Post type objects above).

  7. #7 • John said on January 5 2012:

    @Steve – on the “Share” button – sure, but you’re programatically creating the “Share” action, right, and passing it in as part of your actions object?

    When you post a link you don’t have to define any actions, and you get like, comment, and share automatically.

    Or am I wrong about how Wordbooker handles the “share” action?

  8. #8 • Steve said on January 5 2012:

    I think its the usual problem with the FB docs being out of date and/or inconsistent. This: https://developers.facebook.com/docs/reference/api/user/#links states that you make link posts using the /feed url not the link url… but then those bugs talk about /links….

    I am programmatically creating the share in the action object – so it calls the sharer.php with the post url so that shares the original post rather than the wall post.

    Oddly enough you still get the “Via appname” on the line at the bottom but you lose the app icon.

  9. #9 • Pat said on January 5 2012:

    Interesting, I think I will a/b test clickthrough rates using my app that posts about 12,000 newsfeed posts a day. they could just as easily be rendered as links using the og: metadata vs the current method I am using which is to manually specify the post contents.

    Wouldn’t posting as a link forego the use of the action_link parameter? That is another valuable source of clickthrough volume.

  10. #10 • Steve said on January 6 2012:

    Pat – the action link is lost – so you can’t do what my plugin does which allows you do a “Read Entire Article” or a “Share” and the share on a link post is a share of the FB wall post and not a share of the original article (which is what I implement in my action link).

    It will be interesting to find out which works best… well until Facebook change things again!

  11. #11 • John said on January 9 2012:

    Right – if you use the “POST” type you can define an action link, though only one. (WordBooker offers the choice of “Read More” or “Share” – WPBook just uses “Read More” – I used to offer the share link but thought FB was going to discontinue it in favor of “like”).

    If you use the “LINK” type it gets a “Share” action automatically. Not sure if there is any real difference between the share link generated using sharer.php or one automatically added by Facebook themselves.

  12. #12 • John said on January 9 2012:

    Pat – any results from testing?

  13. #13 • Fabien said on March 8 2012:

    Nice search, I’ve done the same and still wonder what to use to mimic the share you would do through facebook (browsing mode).

    I mean using the graph API (or FQL) to automatically do what a user does when clicking the share option while reading his newsfeed.

    Any hint?