Wie das Business-Use-Case-Rate-Limit von Meta Facebook-Seiten bemisst

Was ist das Business-Use-Case-Rate-Limit von Meta für Seiten?

Das Business-Use-Case-Rate-Limit von Meta für Seiten ist das 24-Stunden-Aufrufbudget, das Meta auf Anfragen an die Pages API anwendet, die mit einem Page Access Token oder einem System User Access Token gestellt werden. Metas Referenz zum Rate Limiting der Graph API gibt die Formel in einer Zeile an:

Calls within 24 hours = 4800 * Number of Engaged Users

Der Satz über der Formel legt die Bedingungen fest: „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.“

Das Budget gehört also der App, das Fenster rollt, statt um Mitternacht zurückgesetzt zu werden, und die Größe des Budgets richtet sich danach, wie viele Menschen in den letzten 24 Stunden mit der Seite interagiert haben. Eine Seite mit 50 engagierten Nutzern finanziert 240.000 Aufrufe in 24 Stunden. Eine Seite ohne engagierte Nutzer finanziert nach derselben Rechnung null.

Business Use Case, von Meta als BUC abgekürzt, ist eines von zwei Rate-Limiting-Systemen, die Meta betreibt. Das andere sind die Platform Rate Limits, das System auf App- und Nutzerebene, über das der Header x-app-usage berichtet. Bei Seiten trennt Meta die beiden nach Token.

Welche Tokens stellen Seitenaufrufe unter das Business-Use-Case-Limit?

Das entscheidet allein das Access Token. Meta nennt die Aufteilung ganz oben in der Rate-Limiting-Referenz: „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.“

Derselbe Aufruf an POST /{page-id}/feed landet in einem anderen System, je nachdem, welche Zugangsdaten Ihre App sendet. Veröffentlichen läuft über Page Tokens, weil die Page-Feed-Referenz „A Page access token“ verlangt, um als Seite zu posten, und ein Page Access Token, das aus einem langlebigen User Token abgeleitet ist, hat kein Ablaufdatum. Diese Aufrufe unterliegen den Business-Use-Case-Limits.

Meta empfiehlt den Business-Use-Case-Weg auch zum Lesen öffentlicher Seiten. Die Referenzen zu Page Feed und Page Photos sagen beide: „When using the Page Public Content Access feature, use a system user access token to avoid rate limiting issues.“ Meta nennt keinen Grund, aber die Wirkung ist klar: Ein System User Token verschiebt diese Lesezugriffe vom stündlichen Platform-Budget auf das 24-Stunden-Budget des Business Use Case.

Wo beide Systeme greifen könnten, entscheidet Meta: „If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied.“

Was zählt beim Seitenlimit als engagierter Nutzer?

Metas gesamte Definition ist ein Satz: „The Number of Engaged Users is the number of Users who engaged with the Page per 24 hours.“ Eine qualifizierende Aktion nennt sie nicht. Likes, Kommentare, Shares und Klicks bleiben unerwähnt.

Dieselbe Seite verwendet den Begriff danach in anderer Bedeutung. Im Messenger-Abschnitt lautet die Formel Calls within 24 hours = 200 * Number of Engaged Users, und Meta definiert ihn anders: „The Number of Engaged Users is the number of people the business can message via Messenger.“ Zwei Formeln in einem Dokument verwenden denselben Begriff für zwei verschiedene Gruppen, mit den Multiplikatoren 4800 und 200.

Eine Untergrenze gibt es ebenfalls nicht. Der Threads-Abschnitt derselben Referenz setzt ausdrücklich eine: „The minimum value for impressions is 10 (so if the impressions is less than 10 we default to 10).“ Der Abschnitt zu Seiten hat keine entsprechende Zeile. Eine brandneue oder ruhende Seite hat eine Formel, die 4800 mit einer Zahl nahe null multipliziert.

Die Formel lässt außerdem eine Frage offen. Sie bemisst das Budget nach dem Engagement einer Seite, rechnet die Aufrufe aber auf „the app's call count“ an. Meta sagt nicht, ob zwei mit derselben App verbundene Seiten aus zwei Budgets schöpfen oder aus einem. Der Header, um den es als Nächstes geht, ordnet die Nutzung einer ID zu, die Metas Feldtabelle als „The ID of the business associated with the token making the API calls“ beschreibt. Das ist ein Business, keine Seite, und der Text sagt nirgends, wie das Budget einer Seite darauf abgebildet wird.

Wie liest man X-Business-Use-Case-Usage bei Seitenaufrufen?

Meta hängt diesen Header an Antworten unter Business-Use-Case-Logik an und beschreibt ihn als „a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call.“ Die Einträge sind nach Business-Objekt-ID geschlüsselt, und der type jedes Eintrags nennt das Limit, über das er berichtet. Für Seitenaufrufe ist der passende Wert pages.

Metas Beispiel zeigt einen Seiteneintrag so:

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

In Metas eigenem Beispiel stecken zwei Probleme. Erstens taucht der Schlüssel 10153848260347724 im Beispiel zweimal auf, einmal mit einem ads_insights-Eintrag und einmal mit dem pages-Eintrag. JSON verbietet das nicht, aber RFC 8259 warnt davor: „The names within an object SHOULD be unique,“ und wenn sie es nicht sind, „the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only.“ JSON.parse in JavaScript behält den letzten. Wenn der echte Header jemals einen Schlüssel so wiederholt wie das Beispiel, verwirft ein Standardparser stillschweigend einen der beiden Einträge. Iterieren Sie deshalb über jeden Eintrag und filtern Sie nach type, statt einen einzelnen Schlüssel nachzuschlagen.

Zweitens ist call_count über „a rolling one hour period“ definiert, während die Seitenformel Aufrufe über „a rolling 24 hour window“ zählt. Der Instagram-Abschnitt desselben Dokuments hat genau dieselbe Unstimmigkeit. Meta sagt nicht, welches Fenster der Seitenprozentsatz verwendet. Planen Sie mit dem 24-Stunden-Fenster, weil es das in der Seitenformel ist.

Die Best Practices unter diesem Header wurden für Anzeigen geschrieben, bis hin zu „Switch to other ad accounts and come back to this account later.“ Keine davon erwähnt Seiten.

Was passiert, wenn eine Seite ihr Business-Use-Case-Limit erreicht?

Aufrufe scheitern mit Fehler 80001. Metas Beispielantwort:

{
  "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"
  }
}

Die Referenzen zu Page Photos und Page Post führen in ihren eigenen Fehlertabellen denselben Text für 80001, das ist also der Code, den ein Veröffentlichungs- oder Lesejob tatsächlich sieht.

Die Meldung sagt „Wait a bit and try again.“ Der Best-Practices-Abschnitt auf derselben Seite sagt etwas Strengeres: „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.“ Folgen Sie dem zweiten. Lesen Sie estimated_time_to_regain_access aus dem pages-Eintrag, parken Sie die Warteschlange dieser Seite für so viele Minuten und senden Sie zwischendurch keine Testaufrufe.

Metas Fehlertabelle für Business-Use-Case-Limits hat einen Ausrutscher, auf den man hinweisen sollte. Sie führt „error code 32“ für „Page calls made with a User access token“ auf, in einer Tabelle über Business-Use-Case-Limits, während dasselbe Dokument sagt, dass Aufrufe mit User Token bei Seiten der Platform-Logik folgen. Die Platform-Tabelle ist die zutreffende: Code 32 „Indicates that the User or app whose token is being used in the Pages API request has reached its rate limit.“ Behandeln Sie 32 als Platform-Fehler und 80001 als Business-Use-Case-Fehler, und leiten Sie sie in unterschiedliche Wiederherstellungspfade.

Nichts davon regelt, wie viele Beiträge eine Seite veröffentlichen darf. Facebooks tägliche Postinglimits sind ein eigenes System mit eigenen Fehlern.

Wie unterscheidet sich das Business-Use-Case-Limit vom Limit auf App-Ebene?

Fast jede Eigenschaft ist anders, einschließlich der Zeiteinheit. Die Multiplikatoren liegen näher beieinander, als es aussieht: 200 Aufrufe pro Stunde über 24 Stunden sind 4800 Aufrufe am Tag, beide Formeln gewähren also dieselbe Tagesrate pro gezählter Person. Der Unterschied liegt darin, wer gezählt wird.

Ein Planungstool mit wenigen täglich aktiven Nutzern, aber belebten Kundenseiten bekommt mit Page Tokens weit mehr Spielraum als mit App Tokens. Eine beliebte App, die auf ruhige Seiten zeigt, erlebt das Gegenteil.

Der Multiplikator 4800 ist nicht auf Seiten beschränkt. Meta verwendet dieselbe Zahl für Instagram, wo sie Impressionen statt engagierter Nutzer multipliziert, und die Instagram-Version dieser Formel hat ihre eigenen Header-Eigenheiten. Nur bei der Seitenversion hängt es davon ab, welches Token Sie senden.

Häufig gestellte Fragen

Wie lautet die Formel für das Business-Use-Case-Rate-Limit von Meta bei Seiten?

Calls within 24 hours = 4800 * Number of Engaged Users, wobei Meta engagierte Nutzer als „the number of Users who engaged with the Page per 24 hours“ definiert. Sie gilt für Pages-API-Aufrufe mit einem Page Access Token oder System User Access Token.

Welcher Fehlercode bedeutet, dass eine Seite ihr Business-Use-Case-Rate-Limit erreicht hat?

Fehler 80001, mit der Meldung „There have been too many calls to this Page account. Wait a bit and try again.“ Fehler 32 ist der Code der Platform Rate Limits für Pages-API-Aufrufe mit einem User- oder App-Token.

Nutzt ein User Access Token bei Seiten das Business-Use-Case-Rate-Limit?

Nein. Meta leitet Pages-API-Aufrufe mit Application oder User Access Tokens an die Platform Rate Limits weiter. Die Aufrufe eines User Tokens zählen gegen das stündliche Aufrufkontingent dieses Nutzers, das Meta nicht offenlegt, und die Aufrufe eines App Tokens zählen gegen das stündliche Budget der App von 200 * Number of Users. Nur Page Tokens und System User Tokens nutzen das Business-Use-Case-Limit.

Wie lange warte ich nach Fehler 80001?

Lies estimated_time_to_regain_access im pages-Eintrag des Headers X-Business-Use-Case-Usage. Meta definiert es als die Zeit in Minuten, bis Aufrufe nicht mehr gedrosselt werden. Sende bis dahin keine Aufrufe für diese Seite, denn laut Meta verlängern weitere Aufrufe die Sperre.

Was bedeutet engagierte Nutzer im Seiten-Rate-Limit von Meta?

Meta sagt nur, dass es die Zahl der Nutzer ist, die pro 24 Stunden mit der Seite interagiert haben, und nennt keine qualifizierenden Aktionen. Dieselbe Rate-Limiting-Seite verwendet „Engaged Users“ für Messenger mit einer anderen Definition, nämlich der Zahl der Menschen, denen das Unternehmen per Messenger schreiben kann.

Warum empfiehlt Meta ein System User Token für Page Public Content Access?

Die Referenzen zu Page Feed und Page Photos weisen Apps, die Page Public Content Access nutzen, an, ein System User Access Token zu verwenden, „to avoid rate limiting issues.“ Ein System User Token verschiebt diese Lesezugriffe vom stündlichen Platform-Budget auf das 24-Stunden-Budget des Business Use Case.

Worin unterscheiden sich Fehler 80001 und Fehler 32 bei Seitenaufrufen?

Fehler 80001 ist der Business-Use-Case-Fehler für Page- und System-User-Tokens, mit der Meldung "There have been too many calls to this Page account". Fehler 32 ist ein Code der Platform Rate Limits für Pages-API-Aufrufe mit User- oder App-Token. Metas Fehlertabelle für Business-Use-Case-Limits führt 32 bei User-Token-Aufrufen auf, was dem Rest des Dokuments widerspricht. Behandle 32 als Platform-Fehler und leite beide Fehler auf getrennte Wiederherstellungswege.

Wie viele Aufrufe bekommt eine Facebook-Seite mit 50 engagierten Nutzern in 24 Stunden?

Die Seite finanziert 240.000 Aufrufe, also 4800 mal 50, in einem rollierenden 24-Stunden-Fenster. Eine Seite ohne engagierte Nutzer finanziert nach derselben Rechnung null. Der Abschnitt zu Seiten nennt kein Minimum, anders als der Threads-Abschnitt, der Impressions auf 10 setzt.

Teilen sich zwei Seiten in derselben App ein Rate-Limit-Budget?

Meta sagt es nicht. Die Formel bemisst das Budget nach dem Engagement einer Seite, berechnet die Aufrufe aber auf den Call Count der App. Der Header X-Business-Use-Case-Usage ordnet die Nutzung der ID des Business zu, das zum Token gehört, nicht der Seite. Lies deshalb jeden Eintrag, statt von einem eigenen Budget pro Seite auszugehen.

Begrenzt das Business-Use-Case-Limit, wie viele Beiträge eine Seite veröffentlichen darf?

Es begrenzt API-Aufrufe, keine Beiträge. Die täglichen Beitragslimits von Facebook sind ein eigenes System mit eigenen Fehlern. Veröffentlichungsaufrufe an POST /{page-id}/feed zählen trotzdem gegen das Aufrufbudget, weil sie mit Page-Tokens laufen.