Como o limite de taxa de caso de uso comercial da Meta mede as Páginas do Facebook

O que é o limite de taxa de caso de uso comercial da Meta para Páginas?

O limite de taxa de caso de uso comercial da Meta para Páginas é o orçamento de chamadas de 24 horas que a Meta aplica às requisições da Pages API feitas com um token de acesso de Página ou um token de acesso de usuário do sistema. A referência de limites de taxa da Graph API da Meta dá a fórmula em uma linha:

Calls within 24 hours = 4800 * Number of Engaged Users

A frase acima da fórmula define os termos: "Requests made by your app to the Pages API using a Page access token or system User access token are counted against the app's call count. An app's call count is the number of calls it can make during a rolling 24 hour window."

Ou seja, o orçamento pertence ao app, a janela é móvel em vez de zerar à meia-noite, e o tamanho do orçamento acompanha quantas pessoas engajaram com a Página no último dia. Uma Página com 50 usuários engajados rende 240.000 chamadas em 24 horas. Uma Página sem nenhum usuário engajado rende zero, pela mesma conta.

Caso de uso comercial, que a Meta abrevia como BUC (de business use case), é um dos dois sistemas de limite de taxa que a Meta mantém. O outro é o Platform Rate Limits, o sistema por app e por usuário sobre o qual o cabeçalho x-app-usage informa. As Páginas são onde a Meta separa os dois pelo token.

Quais tokens colocam chamadas de Páginas no limite de caso de uso comercial?

Quem decide é o token de acesso, e nada mais. A Meta declara a divisão no topo da referência de limites de taxa: "requests made with application or user access tokens are subject to Platform Rate Limits, while requests made with system user or page access tokens are subject to Business Use Case Rate Limits."

A mesma chamada a POST /{page-id}/feed cai em um sistema diferente dependendo de qual credencial seu app envia. A publicação roda com tokens de Página, porque a referência Page Feed exige "A Page access token" para postar como a Página, e um token de acesso de Página derivado de um token de usuário de longa duração não tem data de expiração. Essas chamadas ficam sob os limites de caso de uso comercial.

A Meta também recomenda o caminho do caso de uso comercial para ler Páginas públicas. As referências Page Feed e Page Photos dizem: "When using the Page Public Content Access feature, use a system user access token to avoid rate limiting issues." A Meta não dá o motivo, mas o efeito é claro: um token de usuário do sistema tira essas leituras do orçamento horário do Platform e as coloca no orçamento de 24 horas do caso de uso comercial.

Quando os dois sistemas poderiam se aplicar, a Meta resolve: "If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied."

O que conta como usuário engajado no limite de Páginas?

A definição completa da Meta é uma frase: "The Number of Engaged Users is the number of Users who engaged with the Page per 24 hours." Ela não cita nenhuma ação que conte. Curtidas, comentários, compartilhamentos e cliques não aparecem.

A mesma página depois reutiliza o termo com outro sentido. Na seção do Messenger, a fórmula é Calls within 24 hours = 200 * Number of Engaged Users, e a Meta a define de outro jeito: "The Number of Engaged Users is the number of people the business can message via Messenger." Duas fórmulas no mesmo documento usam o mesmo termo para duas populações diferentes, com multiplicadores de 4800 e 200.

Também não existe piso. A seção de Threads da mesma referência define um explicitamente: "The minimum value for impressions is 10 (so if the impressions is less than 10 we default to 10)." A seção de Páginas não tem linha equivalente. Uma Página recém-criada, ou parada, tem uma fórmula que multiplica 4800 por um número perto de zero.

A fórmula ainda deixa uma pergunta em aberto. Ela dimensiona o orçamento pelo engajamento de uma Página, mas cobra as chamadas de "the app's call count". A Meta não diz se duas Páginas conectadas ao mesmo app consomem de dois orçamentos ou de um. O cabeçalho, tratado a seguir, agrupa o uso por um ID que a tabela de campos da Meta descreve como "The ID of the business associated with the token making the API calls". Isso é uma empresa, não uma Página, e o texto nunca diz como o orçamento de uma Página se relaciona com ela.

Como ler o X-Business-Use-Case-Usage em chamadas de Páginas?

A Meta anexa esse cabeçalho às respostas sob a lógica de caso de uso comercial e o descreve como "a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call." As entradas são indexadas pelo ID do objeto de negócio, e o type de cada entrada nomeia o limite que ela reporta. Para chamadas de Páginas, o valor a procurar é pages.

O exemplo da Meta mostra uma entrada de Páginas assim:

"10153848260347724": [
  {
    "type": "pages",
    "call_count": 97,
    "total_cputime": 23,
    "total_time": 23,
    "estimated_time_to_regain_access": 0
  }
]

Há dois problemas dentro do próprio exemplo da Meta. Primeiro, a chave 10153848260347724 aparece duas vezes no exemplo, uma com uma entrada ads_insights e outra com a entrada pages. O JSON não proíbe isso, mas a RFC 8259 desaconselha: "The names within an object SHOULD be unique," e, quando não são, "the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only." O JSON.parse do JavaScript fica com a última. Se o cabeçalho real algum dia repetir uma chave como o exemplo faz, um parser padrão descarta uma das duas entradas sem avisar, então percorra todas as entradas e filtre por type em vez de buscar uma única chave.

Segundo, call_count é definido sobre "a rolling one hour period", enquanto a fórmula de Páginas conta chamadas em "a rolling 24 hour window". A seção de Instagram do mesmo documento tem a mesma incoerência. A Meta não diz qual janela a porcentagem de Páginas usa. Planeje pela janela de 24 horas, já que é ela que está na fórmula de Páginas.

As boas práticas sob esse cabeçalho foram escritas para anúncios, até em "Switch to other ad accounts and come back to this account later." Nenhuma delas menciona Páginas.

O que acontece quando uma Página atinge o limite de caso de uso comercial?

As chamadas falham com o erro 80001. A resposta de exemplo da Meta:

{
  "error": {
    "message": "(#80001) There have been too many calls to this Page account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.",
    "type": "OAuthException",
    "code": 80001,
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"
  }
}

As referências Page Photos e Page Post trazem o mesmo texto para 80001 nas suas próprias tabelas de erro, então esse é o código que um job de publicação ou de leitura realmente vê.

A mensagem diz "Wait a bit and try again." A seção de boas práticas da mesma página diz algo mais rígido: "When the limit has been reached, stop making API calls. Continuing to make calls will continue to increase your call count, which will increase the time before calls will be successful again." Siga a segunda. Leia estimated_time_to_regain_access na entrada pages, pause a fila daquela Página por essa quantidade de minutos e não fique testando com chamadas no meio do caminho.

A tabela de erros da Meta para limites de caso de uso comercial tem um deslize que vale apontar. Ela lista "error code 32" para "Page calls made with a User access token", em uma tabela sobre limites de caso de uso comercial, enquanto o mesmo documento diz que chamadas de Páginas com token de usuário seguem a lógica do Platform. A tabela do Platform é a correta: o código 32 "Indicates that the User or app whose token is being used in the Pages API request has reached its rate limit." Trate 32 como erro do Platform e 80001 como erro de caso de uso comercial, e mande cada um para um caminho de recuperação diferente.

Nada disso trata de quantos posts uma Página pode publicar. Os limites diários de postagem do Facebook são um sistema separado, com falhas próprias.

Qual é a diferença entre o limite de caso de uso comercial e o limite por app?

Quase todas as propriedades mudam, inclusive a unidade de tempo. Os multiplicadores são mais próximos do que parecem: 200 chamadas por hora durante 24 horas dá 4800 chamadas por dia, então as duas fórmulas concedem a mesma taxa diária por pessoa contada. O que muda é quem é contado.

Uma ferramenta de agendamento com poucos usuários ativos diários mas Páginas de clientes movimentadas ganha muito mais espaço com tokens de Página do que com tokens de app. Um app popular apontado para Páginas paradas ganha o contrário.

O multiplicador 4800 não é exclusivo das Páginas. A Meta usa o mesmo número para o Instagram, onde ele multiplica impressões em vez de usuários engajados, e a versão do Instagram dessa fórmula tem suas próprias peculiaridades de cabeçalho. Só a versão de Páginas depende de qual token você envia.

Perguntas frequentes

Qual é a fórmula do limite de taxa de caso de uso comercial da Meta para Páginas?

Calls within 24 hours = 4800 * Number of Engaged Users, onde a Meta define usuários engajados como "the number of Users who engaged with the Page per 24 hours." Ela vale para chamadas à Pages API feitas com um token de acesso de Página ou de usuário do sistema.

Qual código de erro indica que uma Página atingiu o limite de taxa de caso de uso comercial?

O erro 80001, com a mensagem "There have been too many calls to this Page account. Wait a bit and try again." O erro 32 é o código do Platform Rate Limits para chamadas à Pages API feitas com token de usuário ou de app.

Um token de acesso de usuário usa o limite de taxa de caso de uso comercial em Páginas?

Não. A Meta manda chamadas à Pages API feitas com tokens de acesso de aplicativo ou de usuário para o Platform Rate Limits. As chamadas com token de usuário contam na contagem horária de chamadas do próprio usuário, que a Meta não divulga, e as chamadas com token de app contam no orçamento horário do app, de 200 * Number of Users. Só tokens de Página e de usuário do sistema usam o limite de caso de uso comercial.

Quanto tempo esperar depois do erro 80001?

Leia estimated_time_to_regain_access na entrada pages do cabeçalho X-Business-Use-Case-Usage. A Meta o define como o tempo, em minutos, até as chamadas deixarem de ser limitadas. Não faça nenhuma chamada naquela Página até lá, já que a Meta diz que novas chamadas prolongam o bloqueio.

O que significa usuários engajados no limite de taxa de Páginas da Meta?

A Meta diz apenas que é o número de usuários que engajaram com a Página a cada 24 horas, e não lista nenhuma ação que conte. A mesma página de limites de taxa usa "Engaged Users" para o Messenger com outra definição, o número de pessoas a quem a empresa pode enviar mensagens.

Por que a Meta recomenda um token de usuário do sistema para o Page Public Content Access?

As referências Page Feed e Page Photos orientam os apps que usam o Page Public Content Access a usar um token de acesso de usuário do sistema "to avoid rate limiting issues." Um token de usuário do sistema tira essas leituras do orçamento horário do Platform e as coloca no orçamento de 24 horas do caso de uso comercial.

Qual é a diferença entre o erro 80001 e o erro 32 em chamadas de Páginas?

O erro 80001 é o erro de caso de uso comercial para tokens de Página e de usuário do sistema, com a mensagem "There have been too many calls to this Page account". O erro 32 é um código dos Platform Rate Limits para chamadas à API de Páginas feitas com token de usuário ou de app. A tabela de erros da Meta para limites de caso de uso comercial lista o 32 para chamadas com token de usuário, o que contradiz o resto do documento. Trate o 32 como erro de Platform e leve os dois erros a caminhos de recuperação diferentes.

Quantas chamadas uma Página do Facebook com 50 usuários engajados recebe em 24 horas?

A Página financia 240.000 chamadas, ou seja, 4800 vezes 50, numa janela móvel de 24 horas. Uma Página sem usuários engajados financia zero pela mesma conta. A seção de Páginas não define mínimo, ao contrário da seção do Threads, que sobe as impressões para 10.

Duas Páginas conectadas ao mesmo app dividem um único orçamento de limite de taxa?

A Meta não diz. A fórmula dimensiona o orçamento pelo engajamento de uma Página, mas cobra as chamadas da contagem de chamadas do app. O cabeçalho X-Business-Use-Case-Usage indexa o uso pelo ID do negócio associado ao token, não pela Página. Por isso, leia todas as entradas em vez de supor um orçamento separado por Página.

O limite de caso de uso comercial restringe quantas publicações uma Página pode fazer?

Ele restringe chamadas de API, não publicações. Os limites diários de publicação do Facebook são um sistema à parte, com erros próprios. As chamadas de publicação para POST /{page-id}/feed continuam contando no orçamento de chamadas, porque rodam com tokens de Página.