Für die Data API gelten die folgenden Limits und Kontingente.
So werden Kontingente angewendet
Für alle Anfragen an die Google Analytics Data API v1 ist ein Google Cloud-Projekt erforderlich. Außerdem gelten die auf dieser Seite beschriebenen Kontingente. Kontingente werden unabhängig von der Methode verbraucht, die zum Identifizieren des aufrufenden Projekts verwendet wird, einschließlich:
- Anfragen, die mit OAuth 2.0-Anmeldedaten authentifiziert wurden.
- Anfragen, die nur mit einem API-Schlüssel authentifiziert werden.
API-Schlüssel werden verwendet, um eine Anfrage zu Kontingent- und Abrechnungszwecken einem bestimmten Google Cloud-Projekt zuzuordnen. Alle API-Aufrufe, die mit Anmeldedaten oder einem API-Schlüssel aus Ihrem Projekt erfolgen, werden auf die entsprechenden Kontingente Ihres Projekts und der Google Analytics-Property angerechnet.
Kontingentkategorien
Für die Data API gibt es drei Kontingentkategorien für Anfragen: „Core“, „Realtime“ und „Funnel“. Für API-Anfragen an Core-Methoden werden Core-Kontingente berechnet. Für API-Anfragen an Echtzeitmethoden werden Echtzeitkontingente berechnet. Für jede Anfrage wird nur eine Art von Kontingent verbraucht.
| Kontingentkategorie | API-Methoden |
|---|---|
| Kern- | runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports |
| Echtzeit | runRealtimeReport |
| Trichter | runFunnelReport |
Kontingente für Analytics-Properties
Für alle Anfragen werden Property-Kontingente verbraucht.
| Kontingentname | Limit für Standard-Properties | Limit für Analytics 360-Properties |
|---|---|---|
| Core-Tokens pro Property und Tag | 200.000 | 2.000.000 |
| Core-Tokens pro Property und Stunde | 40.000 | 400.000 |
| Kern-Tokens pro Projekt, Property und Stunde | 14.000 | 140.000 |
| Gleichzeitige Kernanfragen pro Property | 10 | 50 |
| Core-Serverfehler pro Projekt, Property und Stunde | 10 | 50 |
| Echtzeit-Tokens pro Property und Tag | 200.000 | 2.000.000 |
| Echtzeit-Tokens pro Property und Stunde | 40.000 | 400.000 |
| Echtzeit-Tokens pro Projekt, Property und Stunde | 14.000 | 140.000 |
| Gleichzeitige Echtzeitanfragen pro Property | 10 | 50 |
| Echtzeit-Serverfehler pro Projekt, Property und Stunde | 10 | 50 |
| Trichter-Tokens pro Property und Tag | 200.000 | 2.000.000 |
| Trichter-Tokens pro Property und Stunde | 40.000 | 400.000 |
| Trichter-Tokens pro Projekt, Property und Stunde | 14.000 | 140.000 |
| Gleichzeitige Anfragen pro Property im Trichter | 10 | 50 |
| Trichter-Serverfehler pro Projekt, Property und Stunde | 10 | 50 |
- Gleichzeitige Anfragen werden anhand der Anzahl der Anfragen gemessen, die gleichzeitig ausgeführt werden. Um die Anzahl gleichzeitiger Anfragen zu reduzieren, warten Sie, bis vorherige Anfragen abgeschlossen sind, bevor Sie weitere Anfragen senden.
- Serverfehler sind die Codes 500 und 503. Kontingente für Serverfehler werden nur berechnet, wenn eine Anfrage zu einem Serverfehler führt. Wenn die Kontingente für Serverfehler für ein Projekt- und Property-Paar aufgebraucht sind, werden alle Anfragen an die Property aus dem Projekt blockiert.
- Für jede Anfrage wird das Kontingent für „Tokens pro Property pro Stunde“ und „Tokens pro Projekt pro Property pro Stunde“ verbraucht. Das bedeutet, dass auf eine Property von mehr als drei Projekten zugegriffen werden muss, bevor das Kontingent „Tokens pro Property pro Stunde“ vor dem Kontingent „Tokens pro Projekt pro Property pro Stunde“ erschöpft sein kann.
Für Properties sind 120 Anfragen pro Stunde zulässig, bei denen der Schwellenwert möglicherweise überschritten wird. Die Dimensionen userAgeBracket, userGender, brandingInterest, audienceId und audienceName werden möglicherweise zusammengefasst. Grenzwerte sollen verhindern, dass ein Betrachter eines Berichts Rückschlüsse auf demografische Merkmale oder Interessen eines bestimmten Nutzers ziehen kann.
Kontingent für Property-Tokens
Die Anzahl der Tokens wird bei jeder Anfrage in Abhängigkeit von der Komplexität der Anfrage berechnet. Für die meisten Anfragen werden 10 Tokens oder weniger berechnet. Wenn eine große Anzahl von Kontingenttokens durch eine Anfrage verbraucht wird, sind häufig die folgenden Faktoren dafür verantwortlich:
- Große Anzahl von Zeilen
- Große Anzahl von Spalten
- Komplexe Filterkriterien
- Langer Zeitraum
Bei jeder API-Anfrage können Sie "returnPropertyQuota": true im Anfragetext angeben, um den aktuellen Status der Kontingent-Tokens für die Property zurückzugeben. Dieser Status enthält sowohl die von dieser Anfrage verbrauchte Menge als auch die verbleibende Menge für jede Kontingentgruppe. Sie können diesen Parameter beispielsweise in RunReportRequest angeben.