2 near identical URL's integrated with Open Graph tags have separate behaviors when doing a Facebook graph call - facebook

Hitting URL #1 (https://graph.facebook.com/280518352029215) associated to this REAL url (http://www.sephora.com/rose-h-cream-P224527) in a browser CORRECTLY outputs this:
{
about: "What it is:A rich hand moisturizer.What it is formulated to do:Jurlique's Rose Hand Cream deeply hydrates the hands, restoring a soft, supple feeling.What it is formulated WITHOUT:- Parabens- Synthetic Fragrances- Synthetic Dyes- Petro-ChemicalsWhat",
category: "Product/service",
description: "What it is:A rich hand moisturizer.What it is formulated to do:Jurlique's Rose Hand Cream deeply hydrates the hands, restoring a soft, supple feeling.What it is formulated WITHOUT:- Parabens- Synthetic Fragrances- Synthetic Dyes- Petro-ChemicalsWhat",
is_published: true,
talking_about_count: 0,
were_here_count: 0,
id: "280518352029215",
name: "Sephora: Rose Hand Cream : hands-feet-bath-body",
link: "http://www.sephora.com/rose-h-cream-P224527",
likes: 1
}
URL #2 (https://graph.facebook.com/541777132555995) associated to (http://www.sephora.com/green-tea-oil-control-mask-P379853) has a completely different response even though open graph meta tags are identical to URL #1. This is the response:
error: {
message: "An access token is required to request this resource.",
type: "OAuthException",
code: 104
}
additionally, even using an access token I still get this response:
https://graph.facebook.com/541777132555995?access_token=158904350882249|753f74bda2299df3758d21708c7ba34c
error: {
message: "Unsupported get request.",
type: "GraphMethodException",
code: 100
}
I need URL #2 to have a response like URL #1... with or without an access token, I just need a response similar to URL #1. Both URL's are coming from the same website and app where their meta tags are programmatically generated, thus I don't see why FB could successfully consume URL #1, but not URL #2... please help!
Thanks

Well, I think we cannot help you without the real url of the object, so as to see what it is!
Have you try both url (the real ones) in facebook debugger: https://developers.facebook.com/tools/debug
to see the difference?

Related

Facebook Marketing API returns error on "breakdowns call"

I'm trying to make an API call with the folowing URL
act_XXXXXXXX/insights?fields=ad_id,clicks,unique_clicks,impressions,reach,spend,date_start,date_stop,actions,action_values,unique_actions,account_id&level=ad&breakdowns=platform_position&time_range={"since":"2019-09-07","until":"2019-09-07"}
and the response is :
{
"error": {
"message": "(#100) Current combination of data breakdown columns (action_type, platform_position) is invalid ",
"type": "OAuthException",
"code": 100,
"fbtrace_id": "XXXXXXXXXXXXXXXXXXXX"
}
}
the reason is in "breakdown" value = "platform_position"
but the problem is that I need exactly that breakdown :(
when I do an API call and change "breakdown" in URL to something else, for example to "publisher_platform":
act_XXXXXXX/insights?fields=ad_id,clicks,unique_clicks,impressions,reach,spend,date_start,date_stop,actions,action_values,unique_actions,account_id&level=ad&breakdowns=publisher_platform&time_range={"since":"2019-09-07","until":"2019-09-07"}
it is OK and responds with data.
I don't know why it happens because I'm not specifying any "action_type" breakdown but it tells that I am :(
What I've tried:
I tried to remove all the parameters from that URL one by one but it still returns an error
The main questions are: why the API call for "breakdown" value = "platform_position" fails and how to make it work.
Thanks.
PS: you can use FB API testing tool to test requests to FB api.
I'm using API version v8.0
You will need both publisher and position:
breakdowns=publisher_platform,platform_position

How to get "daily" video views Facebook API?

I have a little experience dealing with Facebook Graph API. I need to get daily views for the video as oppose to lifetime views.
FB API docs don't show this to be an option (lifetime - only period param)
https://developers.facebook.com/docs/graph-api/reference/video/video_insights/
However, I've seen another post on SO answering this question, yet for some reasons it doesn't work for me
(Getting a video views with Facebook API).
This is my successful API call which returns lifetime stats as expected:
/{video_id}/video_insights/total_video_views/lifetime
This is what I thought I should be doing:
/{video_id}/video_insights/total_video_views/day
... but got this error:
{
"error": {
"message": "(#100) Invalid parameter",
"type": "OAuthException",
"code": 100,
"error_data": "Daily query is not supported for metric (total_video_views)"
}
}
Then, as the SO post suggested, I tried different period param:
/{video_id}/video_insights/total_video_views/month
... and got this:
{
"error": {
"message": "(#100) Invalid parameter",
"type": "OAuthException",
"code": 100,
"error_data": "Period should be either lifetime or day."
}
}
... which tells that day should be acceptable param just like lifetime
Eventually, just for fun, I thought I'll pass "wrong" param - Day:
/{video_id}/video_insights/total_video_views/Day
... and got this:
{
"error": {
"message": "(#100) For field 'video_insights': period must be one of the following values: day, week, days_28, month, lifetime",
"type": "OAuthException",
"code": 100
}
}
This states that all of these values are good (day, week, days_28, month, lifetime), yet they don't work.
I'm really confused here. I saw daily break down for a video views on FB webpage/insights and thought it should be possible to do the same through the API.
What am i doing wrong?
I encountered the same problem shortly after your post. All of my testing and research has led me to believe Facebook has removed the ability to retrieve anything other than lifetime. After reading all of the Change Log for the last few releases, I don't see any evidence of this change being documented by Facebook. This is obviously very disappointing.
The API responses clearly indicate "day" should be a valid period, which leads me to believe it was hastily removed.
Unfortunately I do not see a reliable workaround. One may be able to achieve an approximation of daily by retrieving lifetime every 24 hours and calculating the difference between the two. This would only be an approximation though since there could be data reconciliation issues for a given time period.
It is too bad this issue didn't get any traction because it is core to the Facebook Video Insights API.
Here is my solution (after running this through FB support)
basically,
1) i get list of all posts:
fields='object_id,type'
url="https://graph.facebook.com/v3.2/{}?access_token={}&fields={}&limit={}".format(resource_id,access_token,fields,limit)
while url:
rec=requests.request(method="GET",url=url)
content = json.loads(rec.content)
if "next" in content["paging"]:
url=content["paging"]["next"]
else:
url=False
break
2) then, i iterate through each of them (filtering those with videos) and retrieve data for the post which contains this video rather than video itself (which turned out to be not possible anymore with daily grouping)
insights=[]
video_post_id=page_id+"_"+video_id
metric="post_video_views"
url_insight=f"https://graph.facebook.com/v3.2/{video_post_id}/insights?metric={metric}&since={since}&until={until}&pretty=0&access_token={access_token}"
while url_insight:
rec=requests.request(method="GET",url=url_insight)
insight = json.loads(rec.content)
if "next" in insight["paging"]:
url_insight=insight["paging"]["next"]
else:
url_insight=False
break
this worked for me

Tracks for "The Hives" are not streaming via the api

Tracks for "The Hives" claims to be streamable, but are returning 404s.
Here's the JSON response for Civilization's Dying id 3644317 (http://api.soundcloud.com/tracks/3644317.json?client_id=):
{
"kind": "track",
"id": 3644317,
…
"sharing": "public",
"streamable": true,
"embeddable_by": "all",
"downloadable": false,
"title": "Civilization's Dying",
…
"stream_url": "http://api.soundcloud.com/tracks/3644317/stream"
}
the streamable is true and it gives a stream_url, when trying to access it with my client_id (like I've done with other tracks) it returns 404.
Edit: Sharing is public. Added the info back to the payload and a link to the api page with the full response for reference.
There's currently a bug affecting some artists whose tracks are not actually streamable any more, but the API response not showing that fact. This should be fixed very shortly.
Make sure this song has "sharing" set to "public" in the returned track get request. If not, you will need to authenticate with Soundcloud.
http://developers.soundcloud.com/docs#authentication
I encountered this issue as well when I tried to stream Lorde's (Royals) tracks. (Soundcloud userid: 27622444)
After examining the track properties returned from the API I noticed that the streamable property had been set to false
API return data:
(...)
sharing: "public"
state: "finished"
streamable: false
tag_list: ""
title: "Swingin' Party"
(...)
Hope that helps!
Cheers,
T

How to deal with URLs with commas in Facebook Graph API

I would like to use Graph API to get some information about URLs.
It works like this:
http://graph.facebook.com/?ids=URL,URL2,URL3
However, when an URL contains comma, things get complicated. For
http://www.example.com/name,something
we get
http://graph.facebook.com/?ids=http%3A%2F%2Fwww.example.com%2Fname%2Csomething
what gives us:
{
"error": {
"message": "(#803) Some of the aliases you requested do not exist: something",
"type": "OAuthException",
"code": 803
}
}
What can be done with URLs to avoid such errors?
Just double-URL-encode the comma, so use %252C for it:
http://graph.facebook.com/?ids=http%3A%2F%2Fwww.example.com%2Fname%252Csomething
It might look weird, because then the Graph API identifies this URL by http://www.example.com/name\u00252Csomething - but I just tested it by pointing a like button to a URL containing a comma (un-encoded), liked it – and afterwards it showed 1 share for this URL on the Graph.

Facebook: identify object id and type by url

I want to get the id and type of a Facebook object based on its URL.
My goal is to identify if a certain URL is a Facebook Event (for example https://www.facebook.com/events/258629027581347).
So if I had the object-id of that object I could do the following FQL query and know that if I get a result the object is an Event:
select eid from event where eid = 258629027581347
The problem is getting the object-id based only on the URL. I do not want to parse the id from the URL because there is no guarantee that the format of the URL will remain the same in the future. I want to find a way to do it through one of Facebook's API's.
After searching for a while, I found the following suggestions for how to do this, but unfortunately none of them work:
FQL query from the object_url table - the query yields no results:
SELECT url, id, type, site FROM object_url WHERE url = "https://www.facebook.com/events/258629027581347"
Use the graph api:
https://graph.facebook.com/https://www.facebook.com/events/258629027581347
This returns a JSON object containing only the URL - no id.
Use the graph api with ?ids= like this:
https://graph.facebook.com/?ids=https://www.facebook.com/events/258629027581347
This returns the following JSON, also no id:
{
"https://www.facebook.com/events/258629027581347": {
"id": "https://www.facebook.com/events/258629027581347",
"metadata": {
"connections": {
"comments": "https://graph.facebook.com/https://www.facebook.com/events/258629027581347/comments?access_token=AAACEdEose0cBADzSuuyJWohIwkXuvQGJUsIlSJz04J4nzKqqQXTvGiPXf4YDBPuh0rdyXgSWnWcJpN3X3GaATVLjG6UmZBiHKmcxCWwZDZD"
},
"type": "link_stat"
}
}
}
What am I missing here?
Thanks!
To my knowledge, there isn't an API method at this time that takes a Facebook URL and tells you what it is. The only way to go about this is to parse the URL and look for the last element and pass this to https://graph.facebook.com/258629027581347?metadata=1&access_token=XXXX
It's a noble goal that you are trying to build a future-proof Facebook application, but I don't think that is a possibility at this time. The Facebook platform is still evolving. There is less of a guarantee that the api methods will remain constant than the url struture.