I'm looking for clarification on how Facebook uniquely identifies objects in the object graph. Specifically, we have several hundred sites for which there is significant overlap in pages that display hotel information. We'd like to have 'Like' buttons for hotels, but have the counts aggregate across sites - so that it doesn't matter on which site a person 'likes' a specific hotel, it'll contribute to the same global count.
More importantly, the philosophy behind Open Graph is that is represents associations between real-world objects - which just happen to be represented by a web-page, so it makes sense for page about a particular hotel to reference the same hotel page object in the graph, regardless of which site it was 'liked' from. For example, for books and products the Open Graph Protocol (OGP) uses ISBN and UPC numbers, while no such universal code exists for other types.
Specifically,
If I set the Open Graph Protocol (OSP) og:url meta property of a hotel page to a URL that references a central site - so that it will be the same og:url for all pages about that hotel regardless of which of our many sites the information appears on, will that achieve the uniqueness required? (does FB even interpret that or is it considered opaque?)
When I use the FB Debugger/Lint app to check my page, it complains that the App ID referenced in the fb:app_id meta tag isn't allowed on any domain other that the 'base' domain set in the App's settings on Facebook. Assuming that this implies I need to create a separate app for every domain we use(!), is there any implication of that for the hotel object identity? (or will the hotel identity remain independent and 'Like'ing a hotel via a Graph API call with any App ID will result in the correct association with the single hotel object as identified in its og:url?). Do I even need an App ID on the page? (just admins perhaps?)
If Facebook returns any of the hotels when people search on the Facebook site, which URL/link will it offer for the result? (the og:url?)
Lastly, and slightly OT, I'm wondering what happens if the og: metadata for a particular canonical og:url object has different properties on different sites, what Facebook will make of it (- e.g. if the og:site_name was different on each domain where the same hotel was represented by the same og:url)
I'm still trying to get my head around it all, so I appreciate all those Facebook ninjas out there :) Apologies if I've put too much detail.
Cheers.
To partially answer 1, Facebook says "If a user likes your URL using a Like button, a News Feed story [...] will be published to Facebook. The og:title links to og:url and the og:site_name is rendered pointing to your site's domain automatically."
Sad. While the og:url is intended to uniquely identify a real-world object, Facebook apparently thinks all users would like to have a link to only a single web-page about the object, regardless of the existence of many and from which page about the object they hit 'Like'. So, even if a user 'Likes' a hotel from a page like coolhotelinfo.con/abchotel or discounthotels.con/abchotel they'll get a link on their feed to boringhotelreferencedata.con/abchotel (for example).
Related
As I am learning and getting familiar with the FB OG API I am finding that I am lacking some of the basics. For example I see here that I use the action type news.publishes to post an article. However the access_token is for the user owning the page and thus it will go to their news feed and not the page (in this case their company page). Correct?
If I understand correctly then how does one get it to post to a specific page. Is there an access_token collection you iterate through till you find the one for the company page?
TIA
JB
You should be able to use /PAGE_ID/feed? Where page id is the numerical assigned by facebook..or the text friendly name you used.
I'm creating an "object" via Facebook's Open Graph. Obviously it's assigned a unique URL within my application (e.g. www.myapp.com/something/hash), and I'm injecting the relevant OG meta tags. All fine, and I can then "attach" a "Like" button and Facebook comments.
However those user-created objects are generated from within a Facebook application - which happens to "live" under the same domain (e.g. www.myapp.com/fb) and that object has its own page within the Facebook application (e.g. www.myapp.com/fb/something/hash)
Thus, that same object has effectively two unique URLs. The "external" one is the one I use to identify it, but I also want to have a "Like" button and Facebook comments on that page. It doesn't seem to accept a URL in, say, the fb-like DIV and corresponding og:url meta tag that doesn't match the URl it's housed on.
Is there any way around this - or do I need to do something like a redirect when calling the page from within the Facebook app, or some sort of clever template switching?
Just set the og:url meta tag value for both URLs to the one URL you want to be the “actual” URL of the object.
Is it possible to configure a Facebook app to have FB likes on a website "aggregated" on different third-level domains?
So, for instance, all the likes on http://example.com/page-to-like are the same of http://www.example.com/page-to-like and https://secure.example.com/page-to-like ?
This could be very important also in case of switching to a new domain (third or second level). It's really incredible that with a domain switch all the likes will be erased...isn't it?
I already searched about on Google, Facebook and here without success, so I think that it's not possible to to this but this is the last try.
Thank you.
Either of these will work:
On all three pages, point the like buttons to one of the pages, all likes will accumulate on the page you point the like buttons at.
On the three URLs, set your og:url meta tag to point to the canonical URL for that content (i.e pick the 'main' URL for that content)
1) Paper.li enables people to publish online newspapers from their favorite social media. An example is here : http://paper.li/tag/socialmedia. All the pages are provided in six languages (English, German, French, Spanish, Portuguese, Japanese).
2) For each of these pages, we are inserting OpenGraph meta information in the source of the page as described in Facebook documentation (https://developers.facebook.com/docs/opengraphprotocol/). We insert the following metas :
a. og:title : The paper title inserted by the user on our service.
b. og:description : A standard description for all pages on our service.
c. og:type : We do not used a standard type provided by Facebook here and we know that the page is classified in “Others” by providing the following value “paper_li:newspaper”.
d. og:url : This is the paper URL.
e. og:image : This is the image of the first article shown in the page to the user. (this is the most relevant content for this page).
f. og:site_name : This is top domain of the app, we mean here “paper.li”
g. fb:app_id : This is the Facebook Application Id we use for our service (providing a Facebook Tab App and login on our service too). This app can be accessed through the following URL on Facebook : http://www.facebook.com/362293833600.
h. og:locale : It defines the current language used by the user on our service
i. og:locale:alternate : It defines all the five other languages we support on our service
This meta information is working really well when using the send button or the like button with social plugins.
3) Our service provides papers who are updated every 24 hours on the same URL (each daily edition is served on one unique URL corresponding to the paper). By this, it means that “og:image” can change (that’s 99.9% of cases) daily, because first article fetched on the web will change daily and image too (corresponding to point 2.e). Paper title (indicated in OpenGraph meta by the point 2.a) can be changed by the user at any time too. In this example, the title is in Japanese in the Graph, for example, with always the same avatar picture in the wall posts.
4) As it’s suggested in your documentation, we want to use the publishing functionality from Facebook linked with the “Like” button. By this, it means that every time a paper is updated on our service, our service is publishing automatically a status to the page corresponding on the Graph on Facebook with the daily headlines (article title, description and image) through the GraphAPI. By doing this, every user having liked the page with the “Like” button will get the status in his news feed if Facebook decides to show it. That’s the purpose of the “Like” button and it’s working really well.
The problem is the following: when we access each of these pages liked on Facebook as an administrator (with application authentication token), we can publish statuses (what we are already doing), but they are published with a page avatar corresponding to the first “og:image” meta that was fetched by Facebook at the first “Like” of this page. It means users are seeing an image for this page that is not corresponding to the content (statuses) published by the page. Same problem appears with the title (if a user is changing it on our side, it can’t be updated on Facebook).
We find it very strange as for standard pages (created by “Create a page” button on Facebook), an access to “Profile picture” and page settings is provided as we don’t have it for pages created through the “Like” button plugin placed on our website (even if we are admin of the page through the app_id). The only way for us to change it for future pages is to change “og:image” meta information but it means that no more relevant image will be shared with corresponding URL (when sharing it in a status at a specific time, for example).
In conclusion, our question is the following: Is it possible to change avatar image and settings (title, ..) on Facebook (through Graph API) of a page created (in the Graph) through the “Like” button plugin? What would be the impact of this action?
In conclusion, our question is the following: Is it possible to change
avatar image and settings (title, ..) on Facebook (through Graph API)
of a page created (in the Graph) through the “Like” button plugin?
No, pages cannot be created via the Like plugin. But if you're referring to a feed post being created, then still no because your app did not insert it.
What would be the impact of this action?
If any authenticated app can change people's posts, regardless of which app created the posting, to their feed, then it might lead to abuse of the system.
I have defined "book" to be an open graph object in my Facebook app. A book is a logical unit, and the user can view a book in a number of different ways in the app. However, there is no single URL in my app which corresponds to any single book.
I thought I would be able to have a URL which spits out open graph meta data to Facebook behind the scenes. For example http://www.example.com/opengrpah/object_book.php?id=3265 would return the title, author, and other info for a book, but not actually be user visible.
However it appears that Facebook uses the object URL for actions involving the object. If I create an action related to the book (e.g. add a book), then if somebody clicks on the link in the ticker they will go to the object_book.php URL, instead of an actual app page. Thus they will see the meta data but nothing useful.
Is this by design? Certainly an object shouldn't have to correspond to a single user-visible page. Can we not have object data drawn from one URL, but have that object displayed to the user within the context of an app?
How about just redirecting from your Open Graph Object URL to the actual app page? Or how about designing your app pages to provide Open Graph metadata?
I think this could be a tricky solution.
In the app I'm working on we had a similar problem because it is an FB Canvas App, so if the og:url for our objects is something like http://apps.facebook.com/our_namespace/?my_first_obj=0 then FB sees the app itself instead of the object loaded in the app. That is where we ultimately want people to land, but we had to provide a direct URL to our app that provided the proper meta tags, much like your situation. I simply put this in the head of those pages:
<script>
try {
if (top.location.href === window.location.href) {
window.location.replace("http://apps.facebook.com/our_namespace/"+window.location.search);
}
} catch(e) {}
</script>
So if somebody is sent directly to that page, they are immediately redirected to our Canvas App, but Facebook's scraper can still get the correct meta data about the object.
I had a similar problem and I ended up with 2 layers for my objects. One is the "master" object, which is actually the object (book in your case, goal in mine).
Then, I have another "user" object, which is actually an association between the master object and a user. This user object has the url like mysite/user/object and it's what I publish to the fb graph with the "add" action.