Zarządzanie limitem interfejsu Google Analytics Data API

Minhaz Kazi, przedstawiciel ds. kontaktu z deweloperami, Google Analytics: Luty 2023 r.

Jeśli tworzysz aplikacje za pomocą interfejsu Google Analytics Data API, powinien zrozumieć, jak działają limity obowiązujące w interfejsie API. Jeśli Dobrze zaprojektowana aplikacja, istnieje mniejsze prawdopodobieństwo przekroczenia przez użytkowników limitu miejsca na dane. Niektóre z odpowiednie sprawdzone metody sprawiają, że zapytania do interfejsu API są skuteczne. Może to spowodować przyspieszenia raportów i paneli w aplikacji oraz dbanie o wygodę użytkowników. W tym artykule omówiono system limitów i najlepsze metod implementacji interfejsu Google Analytics Data API.

Informacje o systemie limitów w interfejsie Google Analytics Data API

Z Google Analytics korzystają miliony programistów i użytkowników, dlatego limit wykorzystania interfejsów API chronią system przed przetwarzaniem większej liczby danych, niż jest w stanie obsłużyć, zapewniając sprawiedliwy podział zasobów systemowych. Interfejs Data API dla Google Usługi w Analytics 4 wykorzystują system zasobników tokenów do zarządzania limitami interfejsu API. Do Wyjaśnienie koncepcji: wyobraź sobie, że istnieje zasobnik, który pomieści maksymalną liczby tokenów. Każde żądanie do interfejsu API najpierw sprawdza zasobnik. W przypadku braku tokeny, żądanie zakończy się niepowodzeniem. W przeciwnym razie żądanie zostanie zrealizowane i zużywa jeden lub więcej tokenów z zasobnika w zależności od złożoności do ich przesłania. Tokeny są uzupełniane w zasobniku do maksymalnej liczby ustalonych w różnych przedziałach czasowych.

W zależności od używanej metody interfejsu Data API obowiązują 3 osobne limity kategorie:

• W czasie rzeczywistym (dla runRealtimeReport)
• Ścieżka (dla runFunnelReport)
• Podstawowy (w przypadku wszystkich innych metod)

Metody interfejsu Data API będą sprawdzać wiele zasobników tokeny limitów:

1. Za usługę na dzień
2. Za usługę za godzinę
3. Za projekt na usługę na godzinę
4. Liczba żądań równoczesnych na usługę
5. Błędy serwera na projekt na usługę na godzinę

Te 5 zasobników jest sprawdzanych za każdym razem, gdy pojawi się żądanie do interfejsu Data API dla usłudze. Jeśli którykolwiek z zasobników jest pusty, żądanie natychmiast zakończy się niepowodzeniem z błędem 429. Jeśli żaden z zasobników nie jest pusty, zostanie wykorzystany z zasobnika Żądania równoczesne na usługę, żądanie do interfejsu API zostanie wykonane. W zależności od stopnia złożoności żądania określona liczba tokenów zostanie zużywana z każdego z trzech pierwszych grup po zakończeniu wykonywania kodu. Żądania równoczesne na usługę możesz otrzymać token uzupełniony.

Limit na projekt na usługę na godzinę zapewnia co najmniej jeden użytkownik nie będzie miał wpływu na innych użytkowników aplikacji. Tutaj: project odnosi się do projektu GCP Twojej aplikacji. Limit na usługę na godzinę wynosi zwykle 4 razy więcej niż limit Na projekt na usługę na godzinę. Na koniec użytkowników, dostęp do usługi muszą mieć co najmniej 4 różne projekty, zanim może zostać wyczerpany limit na usługę na godzinę. Egzekwowanie limitu w obu miejscach na poziomie projektu i usługi zapewnia, że problemy z limitami są ograniczone do i nie będzie miała wpływu na inne usługi, do których aplikacja ma dostęp.

Ostrzeżenie: zdecydowanie odradzamy deweloperom fragmentację tokenów limitów wielu projektów API. Jest to naruszenie Warunków korzystania z interfejsów API Google.

Limit Błędy serwera odnosi się do odpowiedzi interfejsu API o wartości 500 lub 503 kodów. Jeśli aplikacja generuje zbyt wiele błędów podczas na dostęp do usługi, spowoduje to wyczerpanie błędów serwera na projekt usługi na godzinę.

Wszystkie tokeny limitów są uzupełniane do limitu w określonych odstępach czasu. Więcej informacji: Limity interfejsu Google Analytics Data API, aby zaktualizować informacje o limitach. Przykład: Metody podstawowe otrzymują 1250 tokenów limitu w ramach opcji Na projekt na usługę na godzinę. zasobnika. Przy założeniu, że średnie żądanie z aplikacji zużywa 10 limitów aplikacja będzie mogła wysyłać 125 żądań Core na godzinę dla usługę standardową i 10 razy tę liczbę (1250 żądań podstawowych) na dowolne Analytics Usługa w Analytics 360. Wyższy limit tokenów jest jednym z głównych dzięki usługom Analytics 360.

Ponieważ wykorzystanie tokenów dla pierwszych 3 zasobników zależy od złożoności , trudno jest przewidzieć dokładne użycie tokena przed To zwykle zwiększa złożoność żądania, więc w wyniku użycia tokenów:

• Prośba o więcej wymiarów
• Wysyłanie zapytań do większego zakresu czasu
• Uwzględniam wymiary o większej mocy zbioru
• Wysłanie zapytania do usługi z większą liczbą zdarzeń

Dlatego to samo zapytanie w przypadku 2 różnych usług może spowodować zupełnie inne wykorzystanie tokenów, ponieważ moc zbioru wymiarów może lub natężenie ruchu może być inne. Jednakże usług o podobnym poziomie ruchu i podobnej konfiguracji, podobne wykorzystanie tokenów. Możesz wykorzystać to założenie do prognozowania wykorzystania tokenów klienta podczas planowania i projektowania aplikacji.

Uwaga: jeśli zdarzyło Ci się wcześniej korzystać z interfejsu API do raportowania w Universal Analytics, zauważy, że limit interfejsu API do raportowania egzekwowany w projekcie Application/API na poziomie 300%. W przypadku interfejsu Data API egzekwowanie zasad następuje jednak w usłudze w Google Analytics. oraz na poziomie projektu API.

Wykorzystanie limitu monitorowania

Aby monitorować wykorzystanie limitu i przekazywać użytkownikom informacje o nim, możesz dodać "returnPropertyQuota": true do treści żądania do interfejsu API. Zwróci to PropertyQuota wraz z odpowiedzią interfejsu API. Obiekt PropertyQuota będzie zawierać kwoty konsumpcji i stan pozostałych limitów dla wszystkich 5 zasobników. Oto przykład treści żądania i odpowiedzi:

Wyślij prośbę

{
  "dimensions": [
    {
      "name": "medium"
    }
  ],
  "metrics": [
    {
      "name": "activeUsers"
    }
  ],
  "dateRanges": [
    {
      "startDate": "yesterday",
      "endDate": "yesterday"
    }
  ],
  "returnPropertyQuota": true
}

Odpowiedź

{
  "dimensionHeaders": [
    {
      "name": "medium"
    }
  ],
  "metricHeaders": [
    {
      "name": "activeUsers",
      "type": "TYPE_INTEGER"
    }
  ],
  ...
  
  "propertyQuota": {
    "tokensPerDay": {
      "consumed": 1,
      "remaining": 24997
    },
    "tokensPerHour": {
      "consumed": 1,
      "remaining": 4997
    },
    "concurrentRequests": {
      "consumed": 0,
      "remaining": 10
    },
    "serverErrorsPerProjectPerHour": {
      "consumed": 0,
      "remaining": 10
    },
    "potentiallyThresholdedRequestsPerHour": {
      "consumed": 0,
      "remaining": 120
    },
    "tokensPerProjectPerHour": {
      "consumed": 1,
      "remaining": 1247
    }
  },
  
  "kind": "analyticsData#runReport",
  ...
}

Dzięki temu po każdym udanym żądaniu do interfejsu Data API możesz oczekiwać, ile określ limit zużytego żądania i ile pozostało do końca limitu usługi. Jest Można też wyświetlić te informacje użytkownikom w aplikacji, za pomocą prostego interfejsu online.

Uwaga: na obecnym etapie interfejsu Data API musisz wykonać Żądanie do interfejsu API umożliwiające zwrot obiektu PropertyQuota. Jeśli usługa została już wyczerpał się zasobnik tokenów limitu, żądanie zakończy się niepowodzeniem i zostanie wyświetlony błąd 429, odpowiedź nie będzie zawierać obiektu PropertyQuota. Jeśli ma to wpływ na: i uważasz, że Twoja aplikacja skorzystałaby z osobnego sposobu dostęp do informacji o limitach, +1 prośbę o dodanie funkcji w narzędziu Issue Tracker.

Zarządzanie limitami

Zalecamy wdrożenie sprawdzonych metod zarządzania limitami opisanych poniżej, aby uzyskać w pełni wykorzystać możliwości interfejsu Data API. Poza tym Aktualizacja usług do wersji 360 może zwiększyć liczbę dostęp do danych przy użyciu interfejsu API.

Sprawdzone metody

Istnieją zasadniczo 2 sposoby zmniejszenia wykorzystania limitu aplikacji:

• Wysyłanie mniejszej liczby żądań do interfejsu API
• Wysyłanie mniej złożonych żądań do interfejsu API

Oto metody, które możesz wdrożyć, pamiętając przy tym o tych dwóch zasadach:

• Pamięć podręczna: wdrożenie warstwy buforowania jest korzystne zarówno dla łatwości, jak i zarządzania limitem Twojej aplikacji. Sam Google Analytics również będzie zapisywać w pamięci podręcznej. żądania do interfejsu API, ale powtarzające się żądania nadal będą powodować naliczanie tokenów limitu. Według buforowanie odpowiedzi interfejsu API, można znacznie zmniejszyć liczbę powtórzeń żądań. Na przykład dane w ciągu dnia w przypadku usług standardowych mogą obejmować 4. godzin lub dłuższy czas ważności pamięci podręcznej. Zobacz Częstotliwość aktualizacji danych w Google Google Analytics.
• Scalanie żądań: spróbuj połączyć kilka żądań do interfejsu API w jedno. Na przykład 5 żądań danych w ciągu 2 dni może spowodować użycie 3 razy. tokeny limitu w porównaniu z 1 żądaniem w okresie 10 dni. Jeśli wiele żądań, które różnią się tylko jednym wymiarem, rozważ ich scalenie je w jednym żądaniu.
• Upraszczanie żądań: ograniczanie żądań do minimalnej ilości danych wymagane przez aplikację i użytkownika. Duża liczba wierszy/kolumn lub złożone kryteria filtrowania zużywają więcej tokenów limitu. Dłuższe zakresy dat są zwykle droższe (np. zmiana zakresu dat z 28 dni na 365 dni) dni mogą zużywać 3-krotnie więcej tokenów limitu). Możesz też użyć funkcji wymiary o mniejszej mocy zbioru, gdy tylko jest to możliwe (np. żądanie dateHour zamiast dateHourMinute).
• Efektywne wykorzystanie limit: zmiana limit w interfejsie API. żądanie zmniejszenia liczby zwróconych wierszy nie ma istotnego wpływu wykorzystanych tokenów limitu. Na przykład 5 żądań z limitem 10 tys. wierszy może wykorzystują 5 razy tokeny limitu w porównaniu z 1 żądaniem z limitem 50 tys.
• Przyjęcie odpowiedniej kategorii metody: jak wspomnieliśmy powyżej, limity można podzielić na 3 kategorie metod. Używanie odpowiedniej metody dla prawej strony pozwala zaoszczędzić miejsce w innych kategoriach. Na przykład zamiast utworzyć własną ścieżkę w aplikacji przy użyciu danych z podstawowych metod, użyj metody runFunnelReport do tworzenia ścieżek.
• Aktualizuj ustawienia domyślne: podczas tworzenia lub dostosowywania raportów na swoim użytkownicy mogą nie aktualizować opcji domyślnych wyświetlanych aplikacji i zmieniaj je tylko w czasie działania. Jeśli Twoja aplikacja ma domyślny zakres dat to 365 dni, a użytkownik zwykle sprawdza raport 28 dni, spowoduje to zużywanie większego limitu niż jest to regularnie wymagane. Rozważ ograniczenie zakresów i opcji w ustawieniach domyślnych i zezwól użytkownicy wybierają optymalne ustawienia dla swoich przypadków użycia. W niektórych przypadkach możesz też ograniczyć ustawienia domyślne, które mogą zmieniać użytkownicy.
• Kolejkowanie żądań i leniwe ładowanie: pamiętaj o równoczesnych Limit tokenów na liczbę żądań na usługę. Aplikacja nie powinna być wysyłana zbyt wiele żądań jednocześnie. Jeśli Twoja aplikacja ma dużą liczbę elementów interfejsu, które generują znaczącą liczbę żądań do interfejsu API, rozważ dzielenie interfejsu na strony, leniwe ładowanie i kolejkowanie żądań z metodą wykładniczą dla ponownych prób. Agresywne użycie metody returnPropertyQuota monitorowanie wykorzystania tokenów równoczesnych żądań na usługę przez aplikację.

Zarządzanie wrażeniami użytkowników i oczekiwaniami

• Przekazuj użytkownikom opinie, zanim wykona zapytania z potencjalnie wysokim wykorzystaniem tokenów. Na przykład zapytania z wieloma wymiarami o dużej mocy zbioru lub w dłuższym okresie może wymagać dużej liczby tokenów. Umieszczanie ostrzeżenia i prośba o potwierdzenie może uniemożliwić użytkownikom niepotrzebnych zmian w raportach i ograniczaniu zakresu zapytań.
• W przypadku spersonalizowanych rozwiązań do raportowania zapewnij użytkownikom sposób na zrozumienie i zapytania o wykorzystanie poszczególnych elementów raportu. Możesz na przykład podać w widoku debugowania z informacją o wykorzystaniu tokenów limitu dla poszczególnych elementów raportu.
• Prześlij opinię na temat konkretnego typu błędu limitu i określ użytkownika działania.
• Usługi w Google Analytics 360 mają 5–10 razy większy limit w porównaniu z limitem usług do standardowych usług, masz większą elastyczność dzięki Google Analytics 360 usługi.

Zwiększanie limitu interfejsu API powyżej limitów domyślnych nie jest dostępne dla interfejsu Data API dla Google Analytics 4. Google Analytics 360 zapewnia wyższe limity usług w Google Analytics 4. Jeśli użytkownicy osiągają limity po wdrożeniu sprawdzonych metod powinien rozważyć uaktualnienie do Analytics 360. Użytkownicy mogą też skorzystać z Eksportowanie danych do BigQuery z Google Analytics. Dzięki temu użytkownicy będą mogli eksportować dane na poziomie zdarzenia do BigQuery i przeprowadzać własne analizy.

Jeśli masz więcej pytań na temat limitów interfejsu Data API, wejdź na stronę Google Analytics Discord lub zapytaj na Stack Overflow. Jeśli masz konkretne prośby o dodanie funkcji związanych z danymi API, możesz je opublikować w naszym narzędziu do zgłaszania problemów.