I have two otherwise identical posts on a Facebook page that I administer. One post we'll call "full" returns the full range of insight values (31) I'd expect even when the values are zero, while the other which we'll call "subset" returns only a very limited subset of values (7). See below for the actual values returned.
Note that I've confirmed this is the case by using both the GUI-driven export to Excel and the Facebook Graph API Explorer (https://developers.facebook.com/tools/explorer).
My first thought was that the API suppresses certain values such as post_negative_feedback if they are zero (i.e., nobody has clicked hide or report as spam/abusive), but this is not the case. The "full" post has no such reports (or at the very least the return value for all the post_negative_* fields are zero.
I've even tried intentionally reporting the post with no negative return values as spam, and then repulling what I thought was a real-time field (i.e., post_negative_feedback), but data still comes back empty:
{
"data": [
],
(paging data)
}
What gives?
Here is the more limited subset returned for the problematic post:
post_engaged_users
post_impressions
post_impressions_fan
post_impressions_fan_unique
post_impressions_organic
post_impressions_organic_unique
post_impressions_unique
And here is the full set returned for most other posts (with asterisks added to show the subset returned above):
post_consumptions
post_consumptions_by_type
post_consumptions_by_type_unique
post_consumptions_unique
*post_engaged_users
*post_impressions
post_impressions_by_story_type
post_impressions_by_story_type_unique
*post_impressions_fan
post_impressions_fan_paid
post_impressions_fan_paid_unique
*post_impressions_fan_unique
*post_impressions_organic
*post_impressions_organic_unique
post_impressions_paid
post_impressions_paid_unique
*post_impressions_unique
post_impressions_viral
post_impressions_viral_unique
post_negative_feedback
post_negative_feedback_by_type
post_negative_feedback_by_type_unique
post_negative_feedback_unique
post_stories
post_stories_by_action_type
post_story_adds
post_story_adds_by_action_type
post_story_adds_by_action_type_unique
post_story_adds_unique
post_storytellers
post_storytellers_by_action_type
The issue (besides "why does this happen?") is that I've tried giving negative feedback to the post that fails to report any count whatsoever for this -- and I still receive no data (would expect "1" or something around there). I started out waiting the obligatory 15 minutes (real-time field) and then when that didn't work give it a full 24 hours. What gives?
Related
I am trying to extract all the posts from a private FB group of which I am an admin. I am using a Python script to access the data. Whether I use the Graph API Explorer via the web, or my Python script, I am having the exact same problem. I am able to gather the first 6 pages of the feed, each page containing 25 posts. The very first request looks like this:
https://graph.facebook.com/<groupID>/feed?access_token=<accessToken>
That will return, as I stated, the latest 25 posts on the group page.
At the bottom of the JSON that is returned for each request is a section like this:
"paging": {
"previous": "https://graph.facebook.com/v13.0/<pageID>/feed?access_token=<tokenID>&pretty=0&until&__previous=1&since=1649789940&__paging_token=<paging_token>",
"next": "https://graph.facebook.com/v13.0/<pageID>/feed?access_token=<tokenID>&pretty=0&until=1647885515&since&__paging_token=<paging_token>&__previous"
}
I use the value in next to launch the next query. This works until I get to the 6th request. At that point when I request the URL in next it spins for about 15 seconds and then I get the following error:
{
"error": {
"code": 1,
"message": "Please reduce the amount of data you're asking for, then retry your request"
}
}
How exactly do I reduce my data that I'm requesting? I've tried adding the feed.limit() to the request, and it works for the very first request. But that limit is never included in the next URL. Adding it in myself via the script still always returns 25 posts, not what the limit was on the first try. So if I set feed.limit(7) it returns 7 posts on the first request, but then when I use the next link I get 25.
I've set the limit to 100, the first request works, next works the first time, but not the second. If I set the limit to 120 it works with the first query, but now next doesn't. So it seems like it has this built in barrier at 125, it won't give me any more data than that. Any help would be greatly appreciated.
I want to answer this question:
Does the average time on page A (or more accurately page group A) affect the conversion rate of goal B?
So far in the GUI I have:
A) Created an advanced segment of Time on Page >= 120 ("per hit" option):
http://grab.by/tKOA
B) Modified the segment to also add a filter for Page = regex matching my group:
http://grab.by/tKOU
...But I don't know if this gives me the results I'm after; that is, if they are accurate
I have some other ideas, including assigning the page group as a funnel step and then segmenting by the Time on Page; still waiting on data to come in for that one
Wanting to know if there was a better solution or if I'm on the right track
Drewdavid,
Your approach is quite smart and correct, I would say, however keep in mind that in this context, you are mixing different scopes:
Time on Page is page-level metric
Page seen is visit-level dimension
What you would get in your report is the average time on page calculated from all the pages there were seen during visits which met the regex condition set in the filter (that's what segment does, it included all the pages, not just those that you want to filter). I know this can be confusing, but see this article that gives more examples and goes into greater detail.
To achieve what you are after, remove the segment filter and simply use the advanced filtering above the report table (and choose exactly the same regex you mentioned in your question).
Hope this helps!
from https://developers.facebook.com/roadmap/
"Currently the API returns all likes by default. After the migration, fetching a user's likes via the Graph API will return 25 results at a time. We've added pagination to the results so you can page through to all of a user's likes."
I have read the paging how-to here https://developers.facebook.com/blog/post/478/ but still it is not very clear to me which is the best practice to use:
1) The document says that "With the Graph API, when there is more data available, you will notice that paging links are provided:", but at the moment (no limit) I'm getting the paging links even if all the results are already retrieved in the first page. Do I have to check manually the number of results of the following page to verify if it is empty?
2) The document also says "You might notice that the number of results returned is not always equal to the “limit” specified. This is expected behavior. Query parameters are applied on our end before checking to see if the results returned are visible to the viewer. Because of this, it is possible that you might get fewer results than expected.". This should not affect likes retrieving, am I right? I think it is not possible that some likes are viewable and some others not.
Thanks.
I'll try to answer to myself.
1) Yes, I have to check manually, I just did something like this (in this example I retrieve music likes)
$fb_music_likes_ar = array();
$end = 0;
$offset = 0;
while ($end === 0){
$temp_ar = $facebook->api('/me/music?limit=25&offset='.$offset);
$fb_music_likes_ar = array_merge($fb_music_likes_ar, $temp_ar['data']);
$offset = $offset+25;
if (count($temp_ar['data']) < 25){
$end = 1;
}
}
This of course takes more time than before; I don't understand the reason of the change, if I need all the likes I will end up doing several calls and I don't think it is more efficient...
Maybe we can use batch processing to launch several calls?
2) I don't think this is affecting likes retrieving
I am trying to use the graph api with limit and since
I think the highest limit is 5000, so I am using that ( I want to make the fewest calls).
I am also trying to look 1 month back.
So I try:
https://graph.facebook.com/[ID of page]/feed&access_token=[accesstoken]&limit=5000&since=11-12-24
and I get 207 results, and the earliest date is december 24th, this is all fine, its saying hey there are only 207 results in the last month. The problem is there is a next link that has:
"next": "https://graph.facebook.com/[id of page]/feed?limit=5000&until=1324702511"
If I get this page, I start getting posts beore december 24th.
So my question is, how can I be sure I get all posts after a given date with fewest calls???
The kludge I am thinking of is to set the since on the first call to 1 day before, then if I get a post with that date, I know I got them all, if not I paginate... 5000 posts in one month is a lot, but I think its possible...
It seems like facebook should provide a way to get since with highest limit possible...I read this http://developers.facebook.com/blog/post/478/ but im still confused.
If a customer were "silly" (being polite here) enough to try and add, as an example, 4.6 items to their basket, what would you expect to see? or how would you deal with it. Obviously, we only deal with digital quantities (our hacksaw broke last week).
There seems to be a lot of inconsistence across the web.
Amazon Rounds down (4.6->4, 1.3->1)
FireBox Rounds (4.6->5, 1.3->1)
Ebuyer ignores the input (no error)
Expansys removes the item from your basket
I'm assuming some site will show an error
Which is the best solution
Add JavaScript verification that would remove non-numeric input while the user is typing in
Implement backward solution for the situation when JavaScript is off, either display an error message or round the value but then display a message saying "your input has been adjusted"
ADDED: Also be aware that the character that separates the fractional part from the integer one differs from country to country. In US I believe it is '.', in Europe it is usually ','. If your applications is targeted at customers in different countries with varying number representation, it would make sense to implement the support for both characters in your application logic. Otherwise some users will get format error messages without knowing why - non-techie people are often unaware of this format issue.
How about validating the user input and accepting only numeric characters?
One solution would be to bring the incorrect input to the user's attention so they can correct it. Rounding can be too much of an assumption depending on the context.
Displaying an error message next to the amount something like this: "I'm sorry, we cannot supply you with 4.6 items. Please enter a whole number." ...or something along those lines.
Another solution would be to avoid displaying error messages by restricting the input field to only allow valid input. ie If you don't want 4.6 items...only allow the user to be able to type 0-9. If the user can't enter incorrect input then there is never any reason to display an error message.
Assuming you're talking about a web app here, you can limit the characters allowed in the input box.
Alternatively, IMO you could use spinner (+/-) controls to change the quantity.
I believe tesco.com does this.
The best solution according to me would be
Customer enters: 4.6
Value changes to 5 after submitting (or if 4.4, round it to 4)
Notice is displayed telling the user that only integers are valid and that the system has roundedy "your" input (4.6) to 5
One solution would be to inform the user that their selection is invalid when they tab off the edit field that's allowed them to enter the fraction.
A lesser option would be to round (down, unless you're greedy to sell 1 extra item), or to reject the input completely.
The best solution is to prevent fractions in the first place by giving them a slider or spin control to select only whole numbers.
At the end it's always safer add server side check.
So if the input it's not an integer value:
I will redirect the user to the same form.
I will set the field with the floor value (4).
I will put on top of the field a message like"This field must be an integer value. May be did you want 4 pieces of this product?"
In my opinion if your product is an shopping system then it makes sense that primary goal is to sell some items. Usually customers want to perform as less actions as possible, so the system should predict what customer could possibly want when typing incorrect inputs.
Amazon Rounds down (4.6->4, 1.3->1) - the best for me, because everything after the decimal point can be destined to some other input;
FireBox Rounds (4.6->5, 1.3->1) - as for me I don't like when someone want to sell me more than I want to buy, so better 'floor' than 'round';
Ebuyer ignores the input (no error) - then you'll sell nothing and user needs to enter some values once again;
Expansys removes the item from your basket - terrible, now I need to search for the item in the shop once again;
I'm assuming some site will show an error. - not bad but required user to retype value;
I would implemented as Amazon plus informing user that input was not fully clear and asking him to recheck the value. So if the system guessed right then user need to change nothing but if he mistyped he'll see it immediately.
Also you could log all this kind of incidents and then perform an analysis, what user typed for the first time and what was the actual count he bought. Just for curiosity...
Well, you definitely should never round up. You should not ever bill for more materials than the customer requested, no matter how inane the request.