Limity i kwoty interfejsu API danych

W przypadku interfejsu Data API obowiązują te limity i limity przydziału.

Stosowanie limitów przydziału

Wszystkie żądania do interfejsu Google Analytics Data API w wersji 1 wymagają projektu Google Cloud i podlegają limitom przydziału określonym na tej stronie. Limity przydziału są wykorzystywane niezależnie od metody używanej do identyfikowania projektu wywołującego, w tym:

  • żądania uwierzytelnione za pomocą danych logowania OAuth 2.0,
  • żądania uwierzytelnione tylko za pomocą klucza interfejsu API.

Klucze interfejsu API służą do powiązania żądania z konkretnym projektem w chmurze Google Cloud na potrzeby limitu i rozliczeń. Wszystkie wywołania interfejsu API wykonywane przy użyciu danych logowania lub klucza interfejsu API z Twojego projektu będą wliczane do odpowiednich limitów przydziału projektu i usługi w Google Analytics.

Kategorie limitów przydziału

Interfejs Data API ma 4 kategorie limitów przydziału żądań: Rdzeń, W czasie rzeczywistym, Ścieżka i Czat.

Żądania do interfejsu API dotyczące metod podstawowych wykorzystują limity przydziału podstawowego. Żądania do interfejsu API dotyczące metod w czasie rzeczywistym wykorzystują limity przydziału w czasie rzeczywistym. Żądania do interfejsu API dotyczące metod ścieżki wykorzystują limity przydziału ścieżki. Żądania do interfejsu API dotyczące metod czatu wykorzystują limity przydziału czatu. Każde żądanie wykorzystuje tylko 1 rodzaj limitu przydziału.

Kategoria limitu przydziału Metody interfejsu API
Rdzeń runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports
W czasie rzeczywistym runRealtimeReport
Ścieżka runFunnelReport
Czat properties.chat

Limity przydziału usługi w Analytics

Wszystkie żądania wykorzystują limity przydziału usługi.

Nazwa limitu przydziału Limit przydziału w usłudze standardowej Limit przydziału w usłudze w Analytics 360
Tokeny podstawowe na usługę dziennie 200 000 2 000 000
Tokeny podstawowe na usługę na godzinę 40 000 400 000
Tokeny podstawowe na projekt na usługę na godzinę 14 000 140 000
Równoczesne żądania podstawowe na usługę 10 50
Błędy serwera podstawowego na projekt na usługę na godzinę 10 50
Tokeny w czasie rzeczywistym na usługę dziennie 200 000 2 000 000
Tokeny w czasie rzeczywistym na usługę na godzinę 40 000 400 000
Tokeny w czasie rzeczywistym na projekt na usługę na godzinę 14 000 140 000
Równoczesne żądania w czasie rzeczywistym na usługę 10 50
Błędy serwera w czasie rzeczywistym na projekt na usługę na godzinę 10 50
Tokeny ścieżki na usługę dziennie 200 000 2 000 000
Tokeny ścieżki na usługę na godzinę 40 000 400 000
Tokeny ścieżki na projekt na usługę na godzinę 14 000 140 000
Równoczesne żądania ścieżki na usługę 10 50
Błędy serwera ścieżki na projekt na usługę na godzinę 10 50
Tokeny czatu na usługę dziennie 3 750 000 3 750 000
Tokeny czatu na usługę na godzinę 500 000 500 000
  • Żądania równoczesne są mierzone liczbą żądań wykonywanych jednocześnie. Aby zmniejszyć liczbę równoczesnych żądań, poczekaj na zakończenie poprzednich żądań, zanim wyślesz kolejne.
  • Błędy serwera to kody 500 i 503. Limity przydziału błędów serwera są naliczane tylko wtedy, gdy żądanie spowoduje błąd serwera. Gdy limity przydziału błędów serwera dla pary projekt-usługa zostaną wyczerpane, wszystkie żądania do usługi z projektu zostaną zablokowane. Pełną listę odpowiedzi na błędy znajdziesz w sekcji Error Responses.
  • Każde żądanie wykorzystuje limit przydziału zarówno w przypadku tokenów na usługę na godzinę, jak i tokenów na projekt na usługę na godzinę. Oznacza to, że zanim limit przydziału „Tokeny na usługę na godzinę” zostanie wyczerpany przed limitem przydziału „Tokeny na projekt na usługę na godzinę”, do jednej usługi musi mieć dostęp więcej niż 3 projekty.

Usługi mogą wysyłać 120 żądań potencjalnie przekraczających limit na godzinę. Wymiary userAgeBracket, userGender, brandingInterest, audienceId i audienceName mogą przekraczać limit. Limity przydziału są stosowane, aby uniemożliwić osobom wyświetlającym raport ustalenie danych demograficznych lub zainteresowań poszczególnych użytkowników.

Limit przydziału tokenów usługi

Tokeny są wykorzystywane z każdym żądaniem do interfejsu Google Analytics Data API w wersji 1. Liczba naliczonych tokenów zależy od złożoności żądania. Większość żądań będzie wykorzystywać 10 lub mniej tokenów, ale bardziej złożone żądania (np. zapytania chat w funkcji Ask Advisor) będą wykorzystywać więcej tokenów.

Czynniki wpływające na wykorzystanie tokenów

Dokładny koszt tokenów dla żądania jest określany w momencie jego wykonania, co utrudnia dokładne obliczenie z wyprzedzeniem. Koszt zależy od kombinacji czynników związanych z samym żądaniem i danymi bazowymi w usłudze w Google Analytics. Te czynniki mogą powodować wyższe koszty:

  • Liczba wierszy: żądanie większej liczby wierszy.
  • Liczba wymiarów i danych: uwzględnienie większej liczby wymiarów i danych.
  • Złożoność filtra: używanie złożonych wyrażeń filtra.
  • Długość zakresu dat: wysyłanie zapytań dotyczących dłuższych okresów.
  • Moc zbioru danych: wymiary o dużej mocy zbioru (wiele unikalnych wartości, np. pagePath, wymiary niestandardowe) mogą znacznie zwiększyć koszt tokenów.
  • Liczba zdarzeń w usłudze: zapytania dotyczące usług z większą liczbą zdarzeń mogą wykorzystywać więcej tokenów niż to samo zapytanie dotyczące usługi z mniejszą ilością danych.

Monitorowanie wykorzystania tokenów

Najskuteczniejszym sposobem na określenie kosztu tokenów w przypadku konkretnych wywołań interfejsu API jest dodanie parametru "returnPropertyQuota": true w treści żądania (obsługiwane w przypadku runReport, batchRunReports, runPivotReport, batchRunPivotReports, runRealtimeReport i runFunnelReport). Odpowiedź interfejsu API będzie wtedy zawierać obiekt PropertyQuota, który zawiera szczegółowe informacje o tokenach wykorzystanych przez to konkretne żądanie oraz o pozostałych limitach przydziału.

Przykładowe żądanie z parametrem returnPropertyQuota
POST https://analyticsdata.googleapis.com/v1beta/properties/GA_PROPERTY_ID:runReport
{
  "dateRanges": [
    { "startDate": "7daysAgo", "endDate": "yesterday" }
  ],
  "dimensions": [
    { "name": "country" }
  ],
  "metrics": [
    { "name": "activeUsers" }
  ],
  "returnPropertyQuota": true
}
Przykładowa treść odpowiedzi propertyQuota

Gdy "returnPropertyQuota": true jest ustawione, odpowiedź zawiera obiekt propertyQuota, w którym każde pole zawiera QuotaStatus z consumed i remaining liczbami całkowitymi:

{
  "dimensionHeaders": [
    { "name": "country" }
  ],
  "metricHeaders": [
    { "name": "activeUsers", "type": "TYPE_INTEGER" }
  ],
  "rows": [
    {
      "dimensionValues": [{ "value": "United States" }],
      "metricValues": [{ "value": "4820" }]
    }
  ],
  "propertyQuota": {
    "tokensPerDay": {
      "consumed": 1,
      "remaining": 199999
    },
    "tokensPerHour": {
      "consumed": 1,
      "remaining": 39999
    },
    "concurrentRequests": {
      "consumed": 0,
      "remaining": 10
    },
    "serverErrorsPerProjectPerHour": {
      "consumed": 0,
      "remaining": 10
    },
    "potentiallyThresholdedRequestsPerHour": {
      "consumed": 0,
      "remaining": 120
    },
    "tokensPerProjectPerHour": {
      "consumed": 1,
      "remaining": 13999
    }
  }
}

Każde pole w propertyQuota odpowiada limitowi przydziału w limitach przydziału usługi w Analytics. Opłata za tokeny w przypadku pojedynczego żądania do interfejsu API jest odliczana jednocześnie od tokensPerDay, tokensPerHour i tokensPerProjectPerHour. Jeśli którykolwiek limit przydziału osiągnie wartość 0, kolejne żądania do tej usługi będą zwracać błąd 429 RESOURCE_EXHAUSTED.

Sprawdzone metody unikania błędów 429 RESOURCE_EXHAUSTED
  • Dynamiczne monitorowanie salda remaining: sprawdzaj propertyQuota.tokensPerProjectPerHour.remaining i propertyQuota.tokensPerHour.remaining w odpowiedziach i ograniczaj lub wstrzymuj niepilne zadania w tle, gdy liczba pozostałych tokenów spadnie poniżej progu bezpieczeństwa
  • Grupowanie powiązanych zapytań: używaj batchRunReports lub batchRunPivotReports aby grupować do 5 raportów w jednym wywołaniu HTTP i zmniejszać obciążenie związane z rundą HTTP (pamiętaj, że każdy raport w pakiecie nadal jest liczony osobno w limitach przydziału tokenów i concurrentRequests ).
  • Zmniejszanie złożoności i mocy zbioru zapytań: ograniczaj żądania tylko do potrzebnych wymiarów i danych, skracaj dateRanges tam, gdzie to możliwe, i unikaj łączenia wielu wymiarów o dużej mocy zbioru (np. pagePath lub fullPageUrl) w częstych zapytaniach.
  • Kontrolowanie liczby równoczesnych żądań: kolejkowanie żądań lub ograniczanie rozmiaru puli procesów roboczych, aby liczba żądań w trakcie realizacji nie przekraczała limitu concurrentRequests (10 w przypadku usługi standardowej, 50 w przypadku usługi w Analytics 360).
  • Wdrażanie wzrastającego czasu do ponowienia z limitami ponawiania: jeśli żądanie zakończy się niepowodzeniem z powodu błędu 429 RESOURCE_EXHAUSTED, 500 INTERNAL lub 503 UNAVAILABLE, ponów próbę, stosując skrócony wzrastający czas do ponowienia zgodnie z opisem w sekcji Odpowiedzi na błędy.

Wykorzystanie i monitorowanie tokenów czatu

W przypadku żądań chat w funkcji Ask Advisor tokeny reprezentują koszty obliczeń modelu, wnioskowania i pobierania danych bazowych. Na wykorzystanie tokenów czatu wpływają:

  • Zakres zapytań i analiz: złożoność i zakres żądanej analizy.
  • Tokeny wejściowe i wyjściowe modelu: ilość przetwarzanych danych kontekstowych i wygenerowana narracja odpowiedzi.
  • Tokeny myślenia: kroki wnioskowania modelu wymagane do syntezy wyników.
  • Opóźnienie wykonania: czas przetwarzania wymagany do wieloetapowych eksploracji danych.

Aby monitorować wykorzystanie tokenów czatu, ustaw wartość "returnPropertyQuota": true w ChatRequest. Odpowiedź będzie zawierać obiekt PropertyChatQuota z polami tokensPerDay i tokensPerHour z wykorzystanymi i pozostałymi limitami przydziału.