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.
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.
I know that fb have made available some documentation about the requests limits to the api https://developers.facebook.com/docs/marketing-api/api-rate-limiting,
but it is not clear how each api call is calculated...
i.e, If I want to get stats for ~10,000 adsets, how can I evenly space the time between the calls ?
The best answer i could find for this question from another SO thread -
"After some testing and discussion with the Facebook platform team, there is no official limit I'm aware of or can find in the documentation. However, I've found 600 calls per 600 seconds, per token & per IP to be about where they stop you. I've also seen some application based rate limiting but don't have any numbers.
As a general rule, one call per second should not get rate limited. On the surface this seems very restrictive but remember you can batch certain calls and use the subscription API to get changes."
Source - What's the Facebook's Graph API call limit?
Official Doc-: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Rate limits are imposed on each app. The rate limiting tool gives you information about how close your app is to being throttled. Click on any sample to get more detail on the types of utilization.
Your app can make 200 calls per hour per user in aggregate. As an example, if your app has 100 users, this means that your app can make 20,000 calls. This isn't a per-user limit, so one user could make 19,000 of those calls and another could make 1,000. This limit is calculated based on the number of calls made in the previous hour.
Source-: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Heavily rate-limited per ad account. For development only. Not for production apps running for live advertisers.
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.
I read a blog about how ad mediators make requests to multiple providers simultaneously. Is this true? From the article:
"Mediators request ads from all embedded SDKs simultaneously then discard all but the highest paying impression. The problem here is that if an ad is called then ignored, the impression is still counted, and if it’s counted and never shown, it’ll kill your CTR as there’s no way for the user to see and click. Initially you might be thinking: “Great, Adwhirl will artificially increase my impressions and I’ll get more money.” Wrong. It will increase your impressions but it will artificially decrease your CTR. The networks will effectively start ignoring your ad requests; some networks will ban you for fraud. You’ll hurt on ad fill, ad quality and CPMs."
I was thinking about using AdWhirl, but if this is the case, I might not (and use my own custom solution). I am bit skeptical because the blog was written by MobClix.
AdWhirl does NOT make requests to multiple providers simultaneously.
Based upon your configuration settings, AdWhirl will randomly select a primary ad network and request an ad. If it cannot get an ad from the primary ad network, it will fallback to the backfill priority, which you can also configure. AdWhirl will request an ad from backfill priority 1, and if that doesn't succeed it will request an ad from backfill priority 2, incrementally until it finds an ad to display.
How do you get the total number of users in a Google Apps Domain? I'm aware of the "Retrieve All Users in Domain" call using the Google Provisioning API, but I'd rather not execute such an intensive call just to count up all the users. Is there a simpler way to do this?
I found a solution that isn't as resource-heavy as retrieving all users: The Google Reporting API can be used to get the total number of accounts in a Google Apps domain.
The Google Apps Admin Settings API allows you to retrieve both the current and maximum number of users in the domain:
https://developers.google.com/google-apps/admin-settings/#retrieving_the_current_number_of_users_in_a_domain
this would be preferable to the reports API as it's both lower in traffic and it's closer to real time (reports are only updated every 24 hours so it won't take into account users recently added).
You could try "Retrieve All Nicknames in Domain" which could save some bandwidth as it hopefully really only retrieves the nicknames, although I think this won't get you the exact count because "Retrieve All Nicknames for a User" seems to imply that a user can have multiple nicknames.
If you've got some test domain, also assure that retrieving all users really is too much overhead and keep in mind that depending on what you want to do, you can perhaps build some kind of cache around it that only does a full request after the cache is older than X.