Let's say a user selects 50 facebook ids that are his friends.
I take each facebook id and post a message on each person's wall. (Making 50 publish_stream api calls)
What is the limit for Facebook? How do I check how many I can post on behalf of the user?
There is no longer a limit on doing this. But in my company we stopped practicing publish_stream at all after Facebook banned 3 applications using this and we had to make long conversations with them. It's written nowhere on what basis but there is definetly an algorithm catching applications that publish a lot.
When we did that I found many comments on different limits. It seems that it all depends on the application history. This means, if your applicatin is new and generates many streams in the first day it will be caught as spamy. If the app has long history and large user base you can afford that.
Related
I need to quickly get the names of about 1000 users that I now only have the facebook id and access tokens of. I'm not comfortable with the FB api yet so I was considering just writing a scraper to retrive the name from the FB page of the user (since I have the id of the users).
Is this allowed? I assume it's not "best practice" but how severe is it? Will it get me banned for instance? The data will only be used to complete our user database so no advertisement
Alternativly: Can anyone point me in to a good (and up to date) guide of how to get user info using the FB api (keep in mind that I have the ID and the access.tokens of all my users).
No, scraping is not allowed and you MUST use the Graph API: https://www.facebook.com/apps/site_scraping_tos_terms.php
/me?fields=name&access_token=[user-access-token] returns the name of a User - You may run into API limits though, but if it´s a one time thing it should not really matter. If you run into limits, just wait a bit and get the next batch.
For my iPhone app, an user can logged in using Facebook, then the app can get list of friends that already on the app. Now I am wondering - when should the user's Facebook friends be pulled down. Should it be the time when the user start using the app and login with Facebook? Or should it be done periodically in the background thread? Or should it actually be done on my apps' web service side (with the access token received and sent over from the iPhone app) What's the best practice to go with?
The main concerns are
total # of friends could be a large number, which would require a lot of network traffic
time processing
A couple of options:
From your comments below your question, cache friends lists for a minimum of 24 hours. Friend listings rarely change often (unless the user is under 25 years of age, then it might change more frequently...statistically speaking).
Another option you can also subscribe to a user using the Real Time API. Store their friend information on your server and when Facebook tells you they've added a new friend you add it to your data store. Then you can query your own server rather that hitting the Graph API.
I know pretty well that this topic has been discussed very intensively (I read a lot all over the day).
Still, how probable is it that FB might allow me to create a frontend crawler for a non-commercial, non-public research university project?
My crawler should repeatedly lookup a very limited number of specific public fan pages and collect anonymized data like number of fans, status updates and their number of likes and number of comments each.
What I would like to show is what kind of topics in media pages are "liked" and discussed most and how that develops over time. I know about FB's restricted TOS. Thanks for your opinion on that.
The second question concerns technological approach / authorization: Reading a fan page's number of fans, status updates and their number of likes each - could I even use the API/OpenGraph for such a crawler? I think for reading page walls, you need an access token at any cost, and realizing an automatic "crawler" via an application therefore is not possible I guess (as apps only react to users' actions and cannot act like cron jobs for example)?
As you see, I am pretty new to FB development and logic. Thanks so much for your expertise.
If you mainly target public pages then you should be ok.
You need to have a facebook app and then you can authenticate as the app from your program.
You will get an app token with which you should be able to use in order to crawl public pages data.
If you check the documentation for the Page object you'll see in the tables (fields and connections) that most of what's in the Permissions column is either "No access token or user access_token" or "any valid access_token or user access_token", if you have the app token you're good.
Also, and I think this is something you'll be interested in, the Page object has the "talking_about_count" field.
So, yes you can do it, at least most of it.
As for the TOS, since all of this is perfectly ok and straight from their official documentation, there's no problem.
My app stores the Facebook Access Token for offline use. The main purpose of the app is to allow users to automatically posts on the walls of people within a specified number of days of their friends birthday.
My app has been blocked by Facebook due to spam (some users are sending marketing messages to their friends instead of using the app for it's purpose).
I want to find out who those users are and block their access to my application. The only problem is that my Facebook App has a few hundred access tokens (one for each user of my application). The insights dashboard does not provide me with stats per access token. I need to find out which of my users are getting their wall posts reported as spam.
Is there any way of doing this?
After appealing, Facebook has unblocked my application but I don't want it to happen again. As far as I can tell, I can find out the number of people who have reported the wall posts as spam...but I don't know which access token made those posts...and hence don't know which of my users is posting spam messages.
It's not Facebook job to keep track of your application internal activities. You should be logging every activity, at least posts ids returned when someone posts anything on their friends' wall.
And one more time... you DON'T need the offline_access permission to publish something when the user is offline!
I am developing a social media monitoring application. Currently, we are entering Facebook page ids into the application to collect data from possible customers' Facebook walls (so we have a realistic sample for the customer for direct promotion).
These page ids are used to collect wall postings and comments and to compute statistics (e.g. to show most used words), and are presented to the user in a special view. Requirements are to collect all postings and comments without exception in near-live time. We currently have about 130 page ids in the system, with more to come.
Right now, I am using the Graph API for this, with several disadvantages:
FB API access is restricted to 600 request/10 minutes. To get a near-live view, I need to access the API at least each two hours. As we are using API requests in other parts of the program, too, it is obvious that the limit is hit sooner or later (actually, this already happens)
The responses are mostly redundant: to receive current comments, I have to request the wall postings (comments are enclosed in postings) with the URL http://graph.facebook.com/NAME/feed...
The probability for hitting the limits is dependent on the number of postings on the several walls
I cannot get all comments with this method (e.g. comments on postings some time ago)
I am currently trying out how to switch to (or to complement Graph API usage) using FQL by querying the stream and the comment tables but this also has limitations:
I cannot restrict my query to a specific timespan, leading to redundancy again
The max number of posts I am getting for each one of my 130 page ids is 61 - (why 61?)
I need an unpredictable number of additional requests because I need to get special objects like videos and links in separate requests.
My question now is - if anyone is doing similar things: How did you solve these problems? How do you get a pseudo-live-stream of a larger number (up to, say 1,000) of walls?
Letting the customer grant extra permissions to us is currently not an option.
you will probably have to meet with FaceBook and work out a contractual deal for greater access to their data. I would bet that the answer will be no, no and no, seeing as it appears you are trying to monetize their data, and furthermore, do so without the explicit permission of the users, but hey give it a shot.
I have a similar task - By default FB return only last ~50 posts or all in last 30 days(whichever is smaller) in FQL you should use created_time filter to receive more results. my current problem is that via FQL I receive no more than ~500 posts from any FB page wall even when LIMIT increased:
'select post_id from stream where source_id = 40796308305 and created_time <'.time().' LIMIT 1000000 ;'
this FQL request to CocaCola FB Page returns now ~300 posts only (less than 2 day posts).
If you find a better solution pls advise :)