I need your expert advice on this one.
I have been asked to analyse a potential Facebook application.
This application is a parental monitoring for kids accounts. Basically it will search a kid status message for specific keywords amongst others things. And this application will alert the parents when it finds something.
Of course this application will have a valid token to access the kid's data. This is not a tool to spy on the kid.
I am using the Graph API coupled with the 'since' keyword to get the last updates. It's working fine with a single user.
My question is about scalability.
How should I get updates of a huge number of kids to monitor? (between 10,000 and 100,000 accounts)
And for each kids I have to monitor status messages, videos, images, friend, friends' status messages...
Here are some numbers:
~2.1M requests each day to get hourly updates of 10,000 kids' account.
~57.8M requests each day to get hourly updates of 10,000 kids'account plus their friends', with an average of 40 friends each.
And as I read here, it would be limited.
So what do you reckon?
ps: Maybe with real-time updates I won't have this problem or would it be worse?
Yes I would subscribe to real-time updates so as an account gets updated you get a callback and then you get the latest updates. This would avoid the overhead of constantly polling accounts for updates. You will need to get an offline_access token for this to work as well.
Related
I'm currently developing a facebook App whose purpose is to
For a given page, list the last X posts
For each of said posts, list the last Y comments
For each of said posts, list the last W reactions (e.g. likes)
For the page as a whole, display the Z most active users considering the last X posts
The app is not yet published (And, since it'll only provide server to server communication, it might never be) and it currently has one admin and 4 test users.
I'm currently hitting rate limits for the comments endpoint, whereas I've never got any alert for the reactions endpoint.
The rate limit documentation says that some endpoints do not count for rate limiting, but it doesn't say which ones. So I assume that, in my case, only the comments API calls are eating my rate limit.
One approach I might consider to go over the rate limit is to create test apps for my app. They do have their own app-id and app-secret, and share the same app-scoped User ID namespace, so user IDs will be consistent and I'll be able to use both Apps to display aggregate data.
What I don't know is do test apps have their own rate limit?, or do they "eat" part of the production app rate limit?
I want to avoid creating the logic to rotate the App credentials on each call only to discover the rate is still the same.
Edit: I created a test app and hardcoded some calls to use its credentials. However, said calls aren't shown in test app's dashboard. I believe this would mean that its calls are attributed to the main app anyway.
my question is simple, we need an app to manage a large amount of Facebook ads/adsets on our own single account.
Basic operations, like for example setting a daily budget for all adsets in one shot, instead of manually doing it via facebook interface.
The issue is that we are reaching the API limits pretty fast, as we can have even 50-100 adsets in one campaign. I am hitting the API limit simply by listing them sometimes.
I saw in the Facebook App advanced settings that you can add an Facebook Ad account ID, or a Business account, would that help with the limits?
Or even better, is this even possible? Handling large amount of ads? We have a big budget and all, but it's getting tedious to micromanage large amount of ads.
The rate limit per adaccount is heavier limited if you are in development than in basics. In the basics level you can also have three instead of one system users, which would probably mean (correct me if I am wrong) that you can alternate between three tokens and thus get more api calls.
It is also worth to note that updating existing ads/adsets/campaigns is 10-100 times more expensive than creating new ones. You will also get the rate limit error if you change daily budget or similar more than four times a day, so that might be a problem during testing.
I'm creating an app for Q&A that unifies twitter mentions/DMs, facebook wall posts/messages, as well as email and sms into one inbox. I know how I'm going to handle the SMS (storing each incoming message and outgoing response), but I'm wondering if it's realistic to apply the same methodology to twitter/facebook messages.
I figure I need to store them so I can at least mark them read/unread. Is this how TweetDeck does it? I can't imagine them polling the API constantly without caching anything.
By the way if you know of an app that does this already that would be fantastic. Hootsuite does everything but SMS and email oddly.
Assuming you're building a mobile app (since you mention SMS), if you're aiming to support arbitrary Facebook & Twitter accounts (ie including very busy ones) & use over a long period of time, then you can't store all the tweets & posts on the mobile device: this storage required would grow over time to exceed the capacity of any device.
You can store a reasonable number of "recent" tweets/posts in full; these form the backing model for your UI's views. When the user navigates past either end you can retrieve more via the APIs, and you'll perform housekeeping on this collection so it doesn't get too big, discarding older ones as necessary.
(This collection may end up being gappy: eg if I haven't run the app for a week, when I start it it would retrieve the most recent day's content, leaving a gap between yesterday's content & that of a week ago. Twitter's apps do this & show the gaps, allowing the user to fill them in via the APIs.)
If you need to keep track of read/unread status, you could store this & the unique id for a larger number of items; but again, you'll eventually need to purge these too.
You might want to look at the Twitter User Streams feature; Facebook's Realtime Updates isn't as well-suited for mobile apps (unless backed by your own server).
I've been exploring ways that it might be possible to promote the business of a friend of mine. One of these ways is by encouraging users to check in to his business, the incentive for this being that they go into the draw to win some kind of prize.
I've been trying to find if the code for this already exists but I might be looking in the wrong places. If it doesn't what would be the best way to do it using the graph APIs.
Thanks.
You can use Facebook app to check-in to your page/business.
All page check-ins can be fetched using following request by your code
https://graph.facebook.com/PAGE_ID/checkins?access_token=PAGE_ACCESS_TOKEN
If you want to get only specific time period check-ins use since and until params in query.
You have to parse the json response and store in an array and randomly select the winner.
you can contact the winner using their facebook id and send them a message.
You will have to write the code yourself, but it would essentially work like this:
Get the user to allow access to the "Raffle" application and get their email address and permissions to look at their check-ins. Email is required to contact the winner.
Use a scheduled script (cronjob) to periodically check if the user has checked-in anywhere (in particular, the business you want to promote).
Award a raffle ticket for each unique check-in within a 24 hour period.
Hold a draw between all the users who checked in on that day or week and award the prize to someone randomly.
Pretty simple flow, but complex code.
I am conducting test for a future project. I tried to rapidly post 100 - 200 test messages to a test user's feed from a server creating ~20 threads in parallel to send them as fast as possible. I got positive response to each one of those requests (including the id of the item being created in the body) but random number of those those messages does not appear on the facebook user's feed. For example it as ~40 when sending 200 in batch.
Any idea what could be causing this? It is weird especially considering that I am getting positive answer to each request.
Most likely Facebook spam detectors are filtering the messages after they get posted. Why would you possibly need to post 200 messages in a row to a users account? Your app would get shut down so fast. You can use the Facebook api to create a bunch of test accounts and then try distributing the posts to several different users to simulate real usage.