Mit jeder API-Anfrage wird bestätigt, dass Kontingente nicht erschöpft sind und verbraucht Kontingente. Wenn ein Kontingent erschöpft ist, schlägt die Anfrage mit einer entsprechenden Fehlermeldung fehl. Mit jeder Data API-Anfrage werden mehrere Kontingent-Buckets überprüft.
Kontingentkategorien
Für das Kontingent hat die Data API drei Anfragekategorien: Kern, Echtzeit und Trichter. Für API-Anfragen an Core-Methoden werden Core-Kontingente in Rechnung gestellt. Für API-Anfragen an Realtime-Methoden werden Realtime-Kontingente berechnet. Eine Anfrage beansprucht nicht sowohl das Kern- als auch das Echtzeitkontingent. Dies sind die API-Methoden und -Kategorien:
Kontingentkategorie | API-Methoden |
---|---|
Kernprodukt | runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports |
Echtzeit | runRealtimeReport |
Trichter | runFunnelReport |
Kontingente für Analytics-Properties
Alle Anfragen verbrauchen Attributkontingente.
Kontingentname | Limit für Standard-Properties | Limit für Analytics 360-Properties |
---|---|---|
Kerntokens pro Property und Tag | 200.000 | 2.000.000 |
Kerntokens pro Property und Stunde | 40.000 | 400.000 |
Kerntokens pro Projekt, Property und Stunde | 14.000 | 140.000 |
Gleichzeitige Kernanfragen pro Property | 10 | 50 |
Kernserverfehler pro Projekt, Property und Stunde | 10 | 50 |
Realtime-Tokens pro Property und Tag | 200.000 | 2.000.000 |
Realtime-Tokens pro Property und Stunde | 40.000 | 400.000 |
Realtime-Tokens pro Projekt, Property und Stunde | 14.000 | 140.000 |
Gleichzeitige Anfragen in Echtzeit pro Property | 10 | 50 |
Realtime-Serverfehler pro Projekt, Property und Stunde | 10 | 50 |
Trichtertokens pro Property und Tag | 200.000 | 2.000.000 |
Trichtertokens pro Property und Stunde | 40.000 | 400.000 |
Trichtertokens pro Projekt, Property und Stunde | 14.000 | 140.000 |
Gleichzeitige Anfragen im Trichter pro Property | 10 | 50 |
Trichterserverfehler pro Projekt, Property und Stunde | 10 | 50 |
- Gleichzeitige Anfragen werden 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 Nebenläufigkeit von Anfragen zu reduzieren.
- Bei Serverfehlern handelt es sich um die Codes 500 und 503. Kontingente für Serverfehler werden nur berechnet, wenn eine Anfrage „Serverfehler“ ausgegeben wird. Wenn die Kontingente für Serverfehler für ein Projekt/Property-Paar ausgeschöpft sind, werden alle Anfragen an die Property vom Projekt blockiert.
- Jede Anfrage verbraucht das Kontingent sowohl für Tokens pro Property und Stunde als auch für Tokens pro Projekt, pro Property und Stunde. Dies bedeutet, dass ein Attribut von mehr als drei Projekten aufgerufen werden muss, bevor das Kontingent „Tokens pro Attribut und Stunde“ vor dem Kontingent „Tokens pro Projekt pro Attribut und Stunde“ ausgeschöpft sein kann.
Properties dürfen 120 Anfragen pro Stunde mit potenziell eingeschränktem Grenzwert zulassen. Die Dimensionen userAgeBracket
, userGender
, brandingInterest
, audienceId
und audienceName
haben möglicherweise einen Grenzwert. Grenzwerte sollen verhindern, dass sich ein Betrachter eines Berichts auf demografische Merkmale oder Interessen eines einzelnen Nutzers schließen lässt.
Kontingent für Property-Tokens
Tokens werden mit jeder Anfrage abhängig von der Komplexität der Anfrage berechnet. Bei den meisten Anfragen werden maximal 10 Tokens berechnet. Wenn eine große Anzahl von Kontingenttokens für eine Anfrage verbraucht wird, sind häufig folgende Faktoren verantwortlich:
- Große Anzahl von Zeilen
- 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 des Attributkontingenttokens zurückzugeben. Dieser Status enthält sowohl die durch diese Anfrage verbrauchte Menge als auch die für jede Kontingentgruppe verbleibende Menge. Beispielsweise können Sie diesen Parameter in RunReportRequest angeben.