Jede API-Anfrage überprüft, ob Kontingente ausgeschöpft wurden und verbraucht. Wenn ein Kontingent erschöpft ist, schlägt die Anfrage mit einer entsprechenden Fehlermeldung fehl. Jede Data API-Anfrage prüft mehrere Kontingent-Buckets.
Kontingentkategorien
Für Kontingente gibt es in der Data API drei Anfragekategorien: Core, Realtime und Funnel. Für API-Anfragen an Kernmethoden fallen Kernkontingente an. API-Anfragen an Realtime-Methoden berechnen Realtime-Kontingente. Eine Anfrage verbraucht nicht gleichzeitig Core- und Echtzeitkontingente. Dies sind die API-Methoden und -Kategorien:
| Kontingentkategorie | API-Methoden |
|---|---|
| Kernprodukt | runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility |
| Echtzeit | runRealtime-Bericht |
| Trichter | RunFunnelReport |
Analytics-Property-Kontingente
Für alle Anfragen werden Property-Kontingente verbraucht.
| Kontingentname | Standard-Property-Limit | Analytics 360-Property-Limit |
|---|---|---|
| Zentrale Tokens pro Property und Tag | 25.000 | 250.000 |
| Kerntokens pro Property und Stunde | 5.000 | 50.000 |
| Haupttokens pro Projekt, Property und Stunde | 1.250 | 12.500 |
| Gleichzeitige grundlegende Anfragen pro Property | 10 | 50 |
| Core Server-Fehler pro Projekt, Property und Stunde | 10 | 50 |
| Echtzeittokens pro Property und Tag | 25.000 | 250.000 |
| Echtzeittokens pro Property und Stunde | 5.000 | 50.000 |
| Echtzeittokens pro Projekt, Property und Stunde | 1.250 | 12.500 |
| Gleichzeitige Anfragen in Echtzeit pro Property | 10 | 50 |
| Echtzeit-Serverfehler pro Projekt, Property und Stunde | 10 | 50 |
| Trichtertokens pro Property und Tag | 25.000 | 250.000 |
| Trichtertokens pro Property und Stunde | 5.000 | 50.000 |
| Trichtertokens pro Projekt, Property und Stunde | 1.250 | 12.500 |
| Gleichzeitige Anfragen pro Property im Trichter | 10 | 50 |
| Trichterserverfehler pro Projekt, Property und Stunde | 10 | 50 |
- Gleichzeitige Anfragen werden anhand der Anzahl der gleichzeitig ausgeführten Anfragen gemessen. Um die Nebenläufigkeit von Anfragen zu reduzieren, warten Sie, bis vorherige Anfragen abgeschlossen sind, bevor Sie weitere Anfragen senden.
- Serverfehler sind 500 und 503 Codes. Kontingente für Serverfehler werden nur in Rechnung gestellt, wenn in einer Anfrage Serverfehler aufgetreten sind. Wenn die Kontingente für Serverfehler für ein Projekt und ein Attributpaar aufgebraucht sind, werden alle vom Projekt an das Attribut gesendeten Anfragen blockiert.
- Jede Anfrage verbraucht Kontingente für Tokens pro Property, pro Stunde und Tokens pro Projekt und Property pro Stunde. Das bedeutet, dass mehr als vier Projekte auf eine Property zugegriffen werden müssen, bevor das Kontingent „Tokens pro Property pro Stunde“ vor dem Kontingent „Tokens pro Projekt und Property pro Stunde“ aufgebraucht sein kann.
Für Properties sind 120 potenziell zulässige Anfragen pro Stunde zulässig. Die Dimensionen userAgeBracket, userGender, brandingInterest, audienceId und audienceName haben möglicherweise einen Schwellenwert. Grenzwerte sollen verhindern, dass ein Betrachter eines Berichts Rückschlüsse auf demografische Merkmale oder Interessen eines einzelnen Nutzers ziehen kann.
Kontingent für Property-Tokens
Tokens werden mit jeder Anfrage in Abhängigkeit von der Komplexität der Anfrage berechnet. Bei den meisten Anfragen werden maximal zehn Tokens berechnet. Wenn eine größere Anzahl von Kontingenttokens von einer Anfrage genutzt wird, sind folgende Faktoren häufig verantwortlich:
- Große Anzahl von Zeilen
- Große Anzahl von Spalten
- Komplexe Filterkriterien
- Langer Zeitraum
Bei jeder API-Anfrage können Sie im Anfragetext "returnPropertyQuota": true angeben, um den aktuellen Status des Property-Kontingenttokens zurückzugeben. Dieser Status enthält sowohl den für diese Anfrage verbrauchten Betrag als auch den für jede Kontingentgruppe verbleibenden Betrag. Beispielsweise könnten Sie diesen Parameter in RunReportRequest angeben.