Cómo el límite de tasa business use case de Meta mide las Páginas de Facebook

¿Qué es el límite de tasa business use case de Meta para Páginas?

Para las Páginas, el límite de tasa business use case de Meta es el presupuesto de llamadas de 24 horas que Meta aplica a las peticiones a la Pages API hechas con un token de acceso de Página o con un token de acceso de usuario de sistema. La referencia de limitación de tasa de la Graph API de Meta da la fórmula en una línea:

Calls within 24 hours = 4800 * Number of Engaged Users

La frase que precede a la fórmula fija los términos: "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."

Así que el presupuesto pertenece a la app, la ventana es móvil en lugar de reiniciarse a medianoche, y el tamaño del presupuesto cambia según cuántas personas interactuaron con la Página durante el último día. Una Página con 50 usuarios implicados financia 240,000 llamadas en 24 horas. Una Página sin usuarios implicados financia cero, por la misma aritmética.

Business use case, que Meta abrevia BUC, es uno de los dos sistemas de limitación de tasa que tiene Meta. El otro es Platform Rate Limits, el sistema a nivel de aplicación y de usuario del que informa la cabecera x-app-usage. Las Páginas son el punto donde Meta separa los dos según el token.

¿Qué tokens ponen las llamadas de Páginas bajo el límite business use case?

Lo decide el token de acceso, y nada más. Meta indica la separación al principio de la referencia de limitación de tasa: "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."

La misma llamada a POST /{page-id}/feed cae en un sistema u otro según la credencial que envíe tu app. La publicación funciona con tokens de Página, porque la referencia de Page Feed exige "A Page access token" para publicar como la Página, y un token de acceso de Página derivado de un token de usuario de larga duración no tiene fecha de caducidad. Esas llamadas quedan bajo los límites business use case.

Meta también recomienda la vía business use case para leer Páginas públicas. Las referencias de Page Feed y de Page Photos dicen las dos: "When using the Page Public Content Access feature, use a system user access token to avoid rate limiting issues." Meta no da el motivo, pero el efecto es claro: un token de usuario de sistema saca esas lecturas del presupuesto horario de Platform y las lleva al presupuesto business use case de 24 horas.

Donde podrían aplicarse los dos sistemas, Meta lo zanja: "If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied."

¿Qué cuenta como usuario implicado para el límite de Páginas?

Toda la definición de Meta cabe en una frase: "The Number of Engaged Users is the number of Users who engaged with the Page per 24 hours." No nombra ninguna acción que cuente. Los me gusta, los comentarios, los compartidos y los clics no aparecen.

La misma página reutiliza luego el término con otro significado. En la sección de Messenger, la fórmula es Calls within 24 hours = 200 * Number of Engaged Users, y Meta lo define de otra manera: "The Number of Engaged Users is the number of people the business can message via Messenger." Dos fórmulas de un mismo documento usan el mismo término para dos poblaciones distintas, con multiplicadores de 4800 y 200.

Tampoco hay suelo. La sección de Threads de la misma referencia fija uno de forma explícita: "The minimum value for impressions is 10 (so if the impressions is less than 10 we default to 10)." La sección de Páginas no tiene una línea equivalente. Una Página recién creada, o una inactiva, tiene una fórmula que multiplica 4800 por un número cercano a cero.

La fórmula también deja abierta una pregunta. Dimensiona el presupuesto a partir de la interacción de una Página, pero carga las llamadas a "the app's call count". Meta no dice si dos Páginas conectadas a la misma app tiran de dos presupuestos o de uno. La cabecera, que se cubre a continuación, agrupa el uso por un ID que la tabla de campos de Meta describe como "The ID of the business associated with the token making the API calls". Eso es un negocio, no una Página, y el texto nunca explica cómo encaja el presupuesto de una Página en él.

¿Cómo se lee X-Business-Use-Case-Usage en las llamadas de Páginas?

Meta añade esta cabecera a las respuestas bajo la lógica business use case y la describe como "a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call." Las entradas se agrupan por ID de objeto de negocio, y el type de cada entrada nombra el límite del que informa. Para las llamadas de Páginas, el valor que hay que buscar es pages.

El ejemplo de Meta muestra una entrada de Páginas así:

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

Hay dos problemas dentro del propio ejemplo de Meta. Primero, la clave 10153848260347724 aparece dos veces en el ejemplo, una con una entrada ads_insights y otra con la entrada pages. JSON no lo prohíbe, pero el RFC 8259 lo desaconseja: "The names within an object SHOULD be unique," y cuando no lo son, "the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only." JSON.parse en JavaScript se queda con la última. Si la cabecera real repite alguna vez una clave como lo hace el ejemplo, un parser estándar descarta en silencio una de las dos entradas, así que recorre todas las entradas y filtra por type en lugar de buscar una sola clave.

Segundo, call_count se define sobre "a rolling one hour period" mientras que la fórmula de Páginas cuenta las llamadas sobre "a rolling 24 hour window". La sección de Instagram del mismo documento tiene exactamente el mismo desajuste. Meta no dice qué ventana usa el porcentaje de Páginas. Planifica con la ventana de 24 horas, ya que es la que aparece en la fórmula de Páginas.

Las buenas prácticas de esta cabecera se escribieron para anuncios, hasta el punto de decir "Switch to other ad accounts and come back to this account later." Ninguna menciona las Páginas.

¿Qué pasa cuando una Página alcanza su límite business use case?

Las llamadas fallan con el error 80001. La respuesta de ejemplo de 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"
  }
}

Las referencias de Page Photos y Page Post llevan el mismo texto para 80001 en sus propias tablas de errores, así que este es el código que ve de verdad un proceso de publicación o de lectura.

El mensaje dice "Wait a bit and try again." La sección de buenas prácticas de la misma página dice algo más estricto: "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." Haz caso a la segunda. Lee estimated_time_to_regain_access de la entrada pages, aparca la cola de esa Página durante esos minutos y no hagas llamadas de prueba entretanto.

La tabla de errores de Meta para los límites business use case tiene un desliz que conviene señalar. Lista "error code 32" frente a "Page calls made with a User access token", en una tabla sobre límites business use case, mientras que el mismo documento dice que las llamadas a Páginas con token de usuario siguen la lógica de Platform. La tabla de Platform es la correcta: el código 32 "Indicates that the User or app whose token is being used in the Pages API request has reached its rate limit." Trata 32 como un error de Platform y 80001 como el error de business use case, y llévalos a rutas de recuperación distintas.

Nada de esto cubre cuántos posts puede publicar una Página. Los límites de publicación diaria de Facebook son un sistema aparte con fallos propios.

¿En qué se diferencia el límite business use case del límite a nivel de aplicación?

Casi todas las propiedades cambian, incluida la unidad de tiempo. Los multiplicadores están más cerca de lo que parece: 200 llamadas por hora durante 24 horas son 4800 llamadas al día, así que las dos fórmulas conceden el mismo ritmo diario por persona contada. Lo que cambia es a quién se cuenta.

Una herramienta de programación con pocos usuarios activos diarios pero con Páginas de clientes muy activas consigue mucho más margen con tokens de Página que con tokens de aplicación. Una app popular que trabaja con Páginas tranquilas consigue lo contrario.

El multiplicador 4800 no es exclusivo de las Páginas. Meta usa la misma cifra para Instagram, donde multiplica impresiones en lugar de usuarios implicados, y la versión de Instagram de esta fórmula tiene sus propias rarezas de cabecera. Solo la versión de Páginas depende del token que envíes.

Preguntas frecuentes

¿Cuál es la fórmula del límite de tasa business use case de Meta para Páginas?

Calls within 24 hours = 4800 * Number of Engaged Users, donde Meta define los usuarios implicados como "the number of Users who engaged with the Page per 24 hours." Se aplica a las llamadas a la Pages API hechas con un token de acceso de Página o de usuario de sistema.

¿Qué código de error indica que una Página ha alcanzado su límite de tasa business use case?

El error 80001, con el mensaje "There have been too many calls to this Page account. Wait a bit and try again." El error 32 es el código de Platform Rate Limits para las llamadas a la Pages API hechas con un token de usuario o de aplicación.

¿Un token de acceso de usuario usa el límite de tasa business use case en Páginas?

No. Meta envía las llamadas a la Pages API hechas con tokens de acceso de aplicación o de usuario a Platform Rate Limits. Las llamadas con un token de usuario cuentan contra el recuento de llamadas por hora de ese mismo usuario, que Meta no revela, y las llamadas con un token de aplicación cuentan contra el presupuesto por hora de la aplicación, de 200 * Number of Users. Solo los tokens de Página y de usuario de sistema usan el límite business use case.

¿Cuánto tengo que esperar después del error 80001?

Lee estimated_time_to_regain_access en la entrada pages de la cabecera X-Business-Use-Case-Usage. Meta lo define como el tiempo, en minutos, hasta que las llamadas dejen de estar limitadas. No hagas ninguna llamada sobre esa Página hasta entonces, ya que Meta dice que las llamadas adicionales alargan el bloqueo.

¿Qué significa usuarios implicados en el límite de tasa de Páginas de Meta?

Meta solo dice que es el número de usuarios que interactuaron con la Página cada 24 horas, y no lista ninguna acción que cuente. La misma página de limitación de tasa usa "Engaged Users" para Messenger con otra definición, el número de personas a las que el negocio puede escribir.

¿Por qué recomienda Meta un token de usuario de sistema para Page Public Content Access?

Las referencias de Page Feed y Page Photos indican a las apps que usan Page Public Content Access que empleen un token de acceso de usuario de sistema "to avoid rate limiting issues." Un token de usuario de sistema lleva esas lecturas del presupuesto horario de Platform al presupuesto business use case de 24 horas.

¿Qué diferencia hay entre el error 80001 y el error 32 en llamadas de Páginas?

El error 80001 es el error business use case para tokens de Página y de usuario de sistema, con el mensaje "There have been too many calls to this Page account". El error 32 es un código de Platform Rate Limits para llamadas a la API de Páginas hechas con un token de usuario o de aplicación. La tabla de errores de Meta para los límites business use case lista el 32 junto a las llamadas con token de usuario, lo que contradice el resto del documento. Trata el 32 como error de Platform y envía cada error a un camino de recuperación distinto.

¿Cuántas llamadas recibe en 24 horas una Página de Facebook con 50 usuarios implicados?

La Página financia 240.000 llamadas, es decir, 4800 por 50, en una ventana móvil de 24 horas. Una Página sin usuarios implicados financia cero con la misma cuenta. La sección de Páginas no fija un mínimo, a diferencia de la de Threads, que sube las impresiones a 10.

¿Dos Páginas conectadas a la misma aplicación comparten un solo presupuesto de límite de tasa?

Meta no lo dice. La fórmula calcula el presupuesto a partir del engagement de una Página, pero carga las llamadas al recuento de llamadas de la aplicación. La cabecera X-Business-Use-Case-Usage indexa el uso por el ID del negocio asociado al token, no por Página, así que lee todas las entradas en lugar de suponer un presupuesto separado por Página.

¿El límite business use case restringe cuántas publicaciones puede hacer una Página?

Restringe llamadas a la API, no publicaciones. Los límites diarios de publicación de Facebook son un sistema aparte, con errores propios. Las llamadas de publicación a POST /{page-id}/feed siguen contando contra el presupuesto de llamadas, porque se hacen con tokens de Página.