Limity i kwoty interfejsu API danych

W przypadku interfejsu Data API obowiązują te limity.

Jak stosowane są limity

Wszystkie żądania wysyłane do interfejsu Google Analytics Data API w wersji 1 wymagają projektu Google Cloud i podlegają limitom opisanym na tej stronie. Limity są wykorzystywane niezależnie od metody użytej do zidentyfikowania projektu wywołującego, w tym:

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

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

Kategorie limitów

Interfejs Data API ma 4 kategorie limitów żądań: Core, Realtime, Funnel i Chat.

Żądania do interfejsu API dotyczące metod Core obciążają limity Core. Żądania do interfejsu API dotyczące metod Realtime są rozliczane w ramach limitów Realtime. Żądania do interfejsu API dotyczące metod ścieżki obciążają limity ścieżki. Żądania do interfejsu API dotyczące metod Google Chat obciążają limity Google Chat. Każde żądanie wykorzystuje tylko 1 rodzaj limitu.

Limity usługi w Analytics

Wszystkie żądania zużywają limity usługi.

• Żą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 błędów serwera są naliczane tylko wtedy, gdy żądanie powoduje błąd serwera. Gdy limity błędów serwera zostaną wyczerpane dla pary projekt i usługa, wszystkie żądania do usługi z projektu będą blokowane. Pełną listę odpowiedzi o błędzie znajdziesz w sekcji Odpowiedzi o błędzie.
• Każde żądanie wykorzystuje limit tokenów na usługę na godzinę oraz tokenów na projekt na usługę na godzinę. Oznacza to, że jedna usługa musi być używana przez więcej niż 3 projekty, aby limit „Tokeny na usługę na godzinę” mógł zostać wyczerpany przed limitem „Tokeny na projekt na usługę na godzinę”.

W przypadku usług dozwolonych jest 120 potencjalnie ograniczonych żądań na godzinę. Wymiary userAgeBracket, userGender, brandingInterest, audienceId i audienceName mogą podlegać wartościom progowym. Wartości progowe są stosowane, aby uniemożliwić osobom wyświetlającym raport poznanie danych demograficznych lub zainteresowań poszczególnych użytkowników.

Limit tokenów usługi

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

Czynniki wpływające na wykorzystanie tokenów

Dokładny koszt tokena dla żądania jest określany w momencie wykonania, co utrudnia precyzyjne obliczenie wstępne. Na koszt wpływa kombinacja czynników związanych z samym żądaniem i danymi bazowymi w usłudze w Google Analytics. Te czynniki mogą powodować wzrost kosztów:

• Liczba wierszy: żądanie większej liczby wierszy.
• Liczba wymiarów i rodzajów danych: uwzględnienie większej liczby wymiarów i rodzajów danych.
• Złożoność filtra: używanie złożonych wyrażeń filtra.
• Długość zakresu dat: zapytania dotyczące 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 o większej liczbie zdarzeń mogą zużywać więcej tokenów niż takie same zapytania dotyczące usług z mniejszą ilością danych.

Monitorowanie wykorzystania tokenów

Najskuteczniejszym sposobem określenia kosztu tokena w przypadku konkretnych wywołań interfejsu API jest uwzględnienie parametru "returnPropertyQuota": true w treści żądania (obsługiwanego w runReport, batchRunReports, runPivotReport, batchRunPivotReports, runRealtimeReport i runFunnelReport). Odpowiedź interfejsu API będzie wtedy zawierać obiekt PropertyQuota, który szczegółowo opisuje tokeny wykorzystane przez to konkretne żądanie i pozostałe limity.

Przykładowe żądanie z użyciem 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ładowy ładunek odpowiedzi propertyQuota

Gdy ustawisz parametr "returnPropertyQuota": true, odpowiedź będzie zawierać obiekt propertyQuota, w którym każde pole zawiera obiekt QuotaStatus z liczbami całkowitymi consumed i remaining:

{
  "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 w limitach usługi w Analytics. Opłata za tokeny w ramach pojedynczego żądania do interfejsu API jest odliczana jednocześnie z tokensPerDay, tokensPerHour i tokensPerProjectPerHour. Jeśli w dowolnym zasobniku limitu pozostanie 0, kolejne żądania do tej usługi zwrócą błąd 429 RESOURCE_EXHAUSTED.

Sprawdzone metody unikania błędów 429 RESOURCE_EXHAUSTED

• Dynamicznie monitoruj salda remaining: sprawdzaj propertyQuota.tokensPerProjectPerHour.remaining i propertyQuota.tokensPerHour.remaining w odpowiedziach i ograniczaj lub wstrzymuj mniej pilne zadania w tle, gdy liczba pozostałych tokenów spadnie poniżej progu bezpieczeństwa.
• Grupowanie powiązanych zapytań: użyj batchRunReports lub batchRunPivotReports, aby zgrupować do 5 raportów w jednym wywołaniu HTTP i zmniejszyć narzut związany z czasem odpowiedzi HTTP (pamiętaj, że każdy raport w grupie jest nadal liczony osobno w ramach limitów tokenów i concurrentRequests).
• Zmniejsz złożoność i liczbę elementów zapytania: ogranicz żądania tylko do niezbędnych wymiarów i danych, skróć dateRanges, jeśli to możliwe, i unikaj łączenia wielu wymiarów o dużej liczbie elementów (takich jak pagePath lub fullPageUrl) w częstych zapytaniach sondujących.
• Kontroluj równoczesność żądań: umieszczaj żądania w kolejce lub ograniczaj rozmiar puli instancji roboczych, aby liczba żądań w toku nie przekraczała limitu concurrentRequests (10 w przypadku wersji standardowej, 50 w przypadku Analytics 360).
• Zastosuj wzrastający czas do ponowienia z limitami ponownych prób: jeśli żądanie nie powiedzie się i zwróci błąd 429 RESOURCE_EXHAUSTED, 500 INTERNAL lub 503 UNAVAILABLE, spróbuj ponownie, używając skróconego wzrastającego czasu do ponowienia, zgodnie z opisem w sekcji Odpowiedzi z błędami.

Wykorzystanie i monitorowanie tokenów czatu

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

• Zakres zapytania i analizy: złożoność i zakres żądanej analizy.
• Tokeny wejściowe i wyjściowe modelu: ilość przetworzonych danych kontekstowych i wygenerowanych odpowiedzi.
• Tokeny myślenia: kroki rozumowania modelu wymagane do syntezy wyników.
• Czas oczekiwania na wykonanie: czas przetwarzania wymagany do wieloetapowej eksploracji danych.

Aby monitorować wykorzystanie tokenów czatu, ustaw "returnPropertyQuota": true w ChatRequest. Odpowiedź będzie zawierać obiekt PropertyChatQuota z polami tokensPerDay i tokensPerHour, które zawierają wykorzystane i pozostałe saldo.