Kontingente

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.