Für die Data API gelten die folgenden Limits und Kontingente.
Kontingentkategorien
Die Data API hat drei Anfragekontingentkategorien: „Kern“, „Echtzeit“ und „Trichter“. 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 |
|---|---|
| Kernprodukt | 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 |
|---|---|---|
| Haupt-Tokens pro Property und Tag | 200.000 | 2.000.000 |
| Kern-Tokens pro Property und Stunde | 40.000 | 400.000 |
| Kern-Tokens pro Projekt und Property und Stunde | 14.000 | 140.000 |
| Gleichzeitige Kernanfragen pro Property | 10 | 50 |
| Serverfehler pro Projekt und Property pro Stunde | 10 | 50 |
| Realtime Tokens Per Property Per Day | 200.000 | 2.000.000 |
| Echtzeit-Tokens pro Property und Stunde | 40.000 | 400.000 |
| Echtzeit-Tokens pro Projekt und Property pro Stunde | 14.000 | 140.000 |
| Gleichzeitige Anfragen in Echtzeit pro Property | 10 | 50 |
| Echtzeit-Serverfehler pro Projekt und Property pro 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 und Property pro Stunde | 14.000 | 140.000 |
| Gleichzeitige Anfragen aus dem Trichter pro Property | 10 | 50 |
| Trichter-Serverfehler pro Projekt und Property pro Stunde | 10 | 50 |
- Die Anzahl gleichzeitiger Anfragen wird anhand der Anzahl der Anfragen gemessen, die gleichzeitig ausgeführt werden. Warten Sie, bis vorherige Anfragen abgeschlossen sind, bevor Sie weitere Anfragen senden, um die Anzahl gleichzeitiger Anfragen zu reduzieren.
- Serverfehler haben die Codes 500 und 503. Kontingente für Serverfehler werden nur in Rechnung gestellt, wenn eine Anfrage zu einem Serverfehler führt. Wenn das Kontingent für Serverfehler für ein Projekt- und Property-Paar aufgebraucht ist, werden alle Anfragen an die Property aus dem Projekt blockiert.
- Bei jeder Anfrage wird das Kontingent sowohl für „Tokens pro Unterkunft und Stunde“ als auch für „Tokens pro Projekt und Unterkunft und Stunde“ verbraucht. Das bedeutet, dass auf eine Property von mehr als drei Projekten zugegriffen werden muss, bevor das Kontingent „Tokens pro Property und Stunde“ aufgebraucht ist.
Für Properties sind 120 Anfragen pro Stunde zulässig, bei denen der Grenzwert möglicherweise überschritten wird. Für die Dimensionen userAgeBracket, userGender, brandingInterest, audienceId und audienceName werden möglicherweise Grenzwerte verwendet. 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 je nach Komplexität der Anfrage berechnet. Für die meisten Anfragen werden 10 oder weniger Tokens berechnet. Wenn bei einer Anfrage eine große Anzahl von Kontingenttokens verbraucht wird, sind häufig folgende Faktoren dafür verantwortlich:
- Große Zeilenanzahl
- Große Anzahl von Spalten
- Komplexe Filterkriterien
- Langer Zeitraum
Sie können bei jeder API-Anfrage "returnPropertyQuota": true im Anfragetext angeben, um den aktuellen Status der Kontingenttokens für die Property zurückzugeben. Dieser Status enthält sowohl die Menge, die durch diese Anfrage verbraucht wurde, als auch die verbleibende Menge für jede Kontingentgruppe. Angenommen, Sie geben diesen Parameter in RunReportRequest an.