Spis treści
- Skąd biorą się limity GA4 w Looker Studio
- Jak rozpoznać błąd limitu i inne błędy ładowania danych
- Szybkie poprawki w raporcie, które zmniejszają zużycie limitów
- Wyodrębnianie danych: migawka zamiast zapytań na żywo
- BigQuery jako źródło zamiast łącznika GA4
- Inne obejścia: Arkusze, automatyzacje, GA4 360 i dashboardy w GA4
- Najczęściej zadawane pytania
Looker Studio limit GA4 to w praktyce limity Google Analytics Data API, przez które łącznik GA4 pobiera dane do każdego wykresu: dzienne i godzinowe pule tokenów na usługę, osobna pula dla projektu oraz limit jednoczesnych żądań. Gdy raport z wieloma wykresami otwiera kilka osób naraz, pule się wyczerpują i wykresy zamiast danych pokazują błąd. Rozwiązania są trzy: odchudzić raport, ograniczyć liczbę zapytań przez wyodrębnianie danych i dłuższy czas odświeżania albo przenieść źródło do BigQuery, które limitów Data API w ogóle nie ma. Od kwietnia 2026 narzędzie nazywa się ponownie Data Studio, ale zasady działania łącznika GA4 się nie zmieniły.
Najważniejsze w skrócie
- Każdy wykres w raporcie to osobne żądanie do Data API, a każde żądanie zużywa tokeny zależne od złożoności: zakresu dat, liczby wymiarów i wierszy.
- Standardowa usługa GA4 ma m.in. 200 tys. tokenów dziennie, 40 tys. na godzinę i 10 równoczesnych żądań; GA4 360 ma limity mniej więcej dziesięciokrotnie wyższe (stan na październik 2026).
- Najszybsze poprawki to mniej wykresów na stronie, krótszy domyślny zakres dat, mniej wymiarów o dużej liczbie wartości i dłuższy czas odświeżania danych.
- Wyodrębnianie danych zapisuje migawkę do 100 MB i odświeża ją według harmonogramu, więc oglądający nie wysyłają zapytań do GA4.
- Raport oparty na tabelach w BigQuery nie podlega limitom Data API, ale wymaga eksportu i kontroli kosztów zapytań.
Skąd biorą się limity GA4 w Looker Studio
Łącznik GA4 nie przechowuje danych – przy każdym otwarciu strony, zmianie zakresu dat czy filtra wysyła zapytania do Data API. API rozlicza je w tokenach. Proste zapytanie o sesje z ostatnich 7 dni kosztuje kilka tokenów, a tabela z kilkoma wymiarami, rokiem danych i porównaniem do poprzedniego okresu – znacznie więcej.
Limity są liczone dla usługi GA4, a część z nich dla pary „projekt i usługa”. Ponieważ żądania wysyłane przez Looker Studio pochodzą z tego samego narzędzia, w praktyce wszystkie raporty podłączone do jednej usługi dzielą wspólne pule. Jeden ciężki raport agencji potrafi więc zablokować dashboard zarządu.
| Limit Data API | Usługa standardowa | Usługa GA4 360 |
|---|---|---|
| Tokeny na usługę dziennie | 200 000 | 2 000 000 |
| Tokeny na usługę na godzinę | 40 000 | 400 000 |
| Tokeny na projekt i usługę na godzinę | 14 000 | 140 000 |
| Równoczesne żądania na usługę | 10 | 50 |
| Błędy serwera na projekt i usługę na godzinę | 10 | 50 |
| Żądania potencjalnie objęte progami na godzinę | 120 | 120 |
Wartości dotyczą stanu na październik 2026; Google może je zmieniać, więc przy planowaniu dużych wdrożeń sprawdź aktualną dokumentację Data API. Najczęściej wyczerpuje się limit godzinowy dla projektu i limit równoczesnych żądań – ten drugi zwłaszcza na stronach z kilkunastoma wykresami ładowanymi jednocześnie.
Ostatni wiersz tabeli ma znaczenie przy usługach z włączonymi sygnałami Google. Zapytania, które mogą podlegać progom danych, mają osobny, niski limit. Od 15 czerwca 2026 sygnały Google są oddzielone od ad_storage i sterują raportami behawioralnymi; co to oznacza dla progów i jakie ustawienia sprawdzić, opisujemy w tekście o oddzieleniu Google Signals od ad_storage.
Jak rozpoznać błąd limitu i inne błędy ładowania danych
Nie każdy pusty wykres to limit API. Zanim zaczniesz przebudowywać raport, ustal, z którym problemem masz do czynienia.
| Objaw | Najczęstsza przyczyna | Co zrobić |
|---|---|---|
| Komunikat o przekroczeniu limitu, część wykresów działa | Wyczerpana pula tokenów lub zbyt wiele równoczesnych żądań | Odczekaj, odchudź stronę, wydłuż odświeżanie |
| Błąd konfiguracji zbioru danych | Utrata dostępu właściciela źródła do GA4 albo usunięte pole | Sprawdź uprawnienia i pola w źródle danych |
| Wykres pokazuje błąd niezgodnych pól | Połączenie wymiaru i danych o różnych zakresach, np. produktu z sesjami | Zmień wymiar lub dane na zgodne zakresem |
| Wiersz „(other)” w tabeli | Wymiar o bardzo dużej liczbie wartości, np. pełny adres strony | Skróć zakres dat, użyj wymiaru o mniejszej liczbie wartości lub BigQuery |
| Niższe liczby niż w GA4, brak małych wierszy | Progi danych przy sygnałach Google | Sprawdź tożsamość raportowania i ustawienia sygnałów |
| Długie ładowanie bez komunikatu | Rok danych z wieloma wymiarami, łączenie kilku źródeł GA4 | Skróć zakres, podziel wykres, użyj wyodrębnienia |
Przy błędzie konfiguracji zbioru danych najczęściej winne są uprawnienia. Jeśli źródło danych korzysta z uprawnień właściciela, a ta osoba straciła dostęp do usługi GA4 albo odeszła z firmy, raport przestaje działać dla wszystkich. Dlatego źródła danych w raportach firmowych powinny należeć do konta zespołowego lub osoby, która zostanie w organizacji na dłużej.
Szybkie poprawki w raporcie, które zmniejszają zużycie limitów
Większość problemów z limitami da się rozwiązać bez zmiany źródła danych. Poniższe kroki wykonaj w tej kolejności, sprawdzając po każdym, czy raport ładuje się stabilnie.
- Podziel stronę na kilka stron. Narzędzie ładuje wykresy tylko z bieżącej strony, więc 20 wykresów rozłożonych na cztery strony obciąża API mniej niż 20 na jednej.
- Skróć domyślny zakres dat. Raport otwierany z zakresem 28 dni zużywa mniej tokenów niż raport z ostatnimi 12 miesiącami. Dłuższy zakres użytkownik może wybrać sam.
- Usuń zbędne wymiary. Każdy dodatkowy wymiar w tabeli zwiększa liczbę wierszy i koszt zapytania. Pełny adres strony zamień na ścieżkę albo grupę treści.
- Ogranicz porównania. Porównanie do poprzedniego okresu na każdej karcie wyników zwiększa liczbę zapytań. Zostaw je tam, gdzie naprawdę jest potrzebne.
- Unikaj łączenia GA4 z GA4. Połączenie dwóch źródeł GA4 w jednym wykresie to kilka zapytań zamiast jednego. Jeśli możesz, zastąp je jednym źródłem z odpowiednimi polami.
- Wydłuż czas odświeżania danych. W ustawieniach źródła danych zostaw domyślny, dłuższy interwał. Krótsze odświeżanie oznacza więcej zapytań przy każdym otwarciu.
- Ogranicz ręczne odświeżanie przez oglądających. Od czerwca 2026 edytor może pozwolić oglądającym odświeżać dane; w raportach z dużym ruchem lepiej tej opcji nie włączać.
- Przenieś ciężkie analizy do eksploracji GA4 albo do osobnego raportu, który otwiera tylko analityk.
Załóżmy, że dashboard sklepu ma na stronie głównej 14 wykresów, w tym 6 kart wyników z porównaniem rok do roku, i otwiera go równocześnie pięć osób w poniedziałek rano. To kilkadziesiąt równoczesnych żądań przy limicie 10 – błędy są wtedy niemal pewne. Ta sama treść rozłożona na trzy strony, z porównaniem tylko na dwóch kartach, zwykle ładuje się bez problemu. Wskazówki, jak ułożyć taki raport od początku, znajdziesz w poradniku o dashboardzie e-commerce w Looker Studio.
Wyodrębnianie danych: migawka zamiast zapytań na żywo
Łącznik wyodrębniania danych (Extract Data) pobiera wybrane wymiary i dane z GA4 raz, zapisuje je jako migawkę i automatycznie odświeża według harmonogramu: codziennie, co tydzień lub co miesiąc. Oglądający korzystają z migawki, więc ich wizyty nie zużywają limitów Data API.
Wyodrębnienie ma limit rozmiaru 100 MB i stały zestaw pól wybranych przy konfiguracji. Nie nadaje się do danych z bieżącego dnia ani do raportów, w których użytkownik dowolnie zmienia wymiary. Dobrze sprawdza się w dashboardach zarządczych z kilkoma KPI dziennie według kanału i urządzenia. Przy konfiguracji wybierz tylko potrzebne pola i rozsądny zakres dat, np. ostatnie 13 miesięcy, żeby zmieścić się w limicie i mieć porównanie rok do roku.
Jeśli w raporcie używasz pól obliczeniowych, utwórz je w źródle opartym na wyodrębnieniu, a nie w oryginalnym źródle GA4. Formuły, które przydadzą się w takim raporcie, zebraliśmy w artykule o polach obliczeniowych w Looker Studio.
BigQuery jako źródło zamiast łącznika GA4
Najtrwalszym rozwiązaniem problemu limitów jest przeniesienie raportu na dane w BigQuery. Zapytania do hurtowni nie korzystają z Data API, więc żadna liczba wykresów ani oglądających nie wywoła błędu limitu. Dodatkowo znikają progi danych i wiersz „(other)”, bo pracujesz na surowych zdarzeniach.
Koszt tego rozwiązania to praca na początku i kontrola wydatków później. Potrzebujesz eksportu GA4 do BigQuery – konfigurację opisujemy w przewodniku, jak połączyć GA4 z BigQuery – oraz tabel pośrednich z dziennymi agregatami. Raport podpięty bezpośrednio do surowych tabel eksportu będzie działał, ale może kosztować setki dolarów miesięcznie. Jak tego uniknąć, wyjaśniamy w tekście o kosztach BigQuery i tabelach pośrednich.
Pamiętaj też, że liczby z BigQuery nie będą identyczne z interfejsem GA4, bo eksport nie zawiera danych modelowanych w ramach Consent Mode i liczy unikalne wartości dokładnie, a nie szacunkowo. Ustal z odbiorcami raportu, które źródło jest obowiązujące.
Inne obejścia: Arkusze, automatyzacje, GA4 360 i dashboardy w GA4
Jeśli BigQuery to dla Ciebie zbyt duży krok, masz kilka pośrednich rozwiązań. Każde z nich ogranicza liczbę zapytań do GA4, przesuwając pobieranie danych na harmonogram.
- Arkusze Google jako bufor. Dane z GA4 pobierane raz dziennie przez dodatek do Arkuszy, skrypt albo automatyzację trafiają do arkusza, a raport korzysta z arkusza. Przykład takiego przepływu z modelem językowym opisujemy w artykule o automatyzacji raportów w n8n, a wariant dla Google Ads w tekście o automatycznych raportach do Arkuszy i Slacka.
- Łączniki partnerskie. Część z nich pobiera dane według harmonogramu i przechowuje je u siebie. Nadal korzystają z Data API, ale rzadziej i w kontrolowany sposób.
- GA4 360. Dziesięciokrotnie wyższe limity rozwiązują problem w dużych organizacjach, ale to decyzja kosztowa wykraczająca daleko poza raportowanie.
- Dashboardy w GA4. Od 9 września 2026 proste zestawienia KPI możesz zbudować bezpośrednio w GA4, bez łącznika. Kiedy to wystarczy, a kiedy nie, porównujemy w artykule o dashboardach w GA4 i Looker Studio.
Wybór zależy od tego, ile osób korzysta z raportu i jak świeże dane są potrzebne. Raport dla kilku osób, otwierany raz w tygodniu, zwykle wystarczy odchudzić. Raport dla całej firmy, otwierany codziennie, warto oprzeć na wyodrębnieniu lub BigQuery. Kolejne poradniki znajdziesz w podtemacie Dashboardy w Looker Studio, a definicje metryk takich jak sesja w słowniku.
Najczęściej zadawane pytania
Dlaczego Looker Studio pokazuje błąd przekroczenia limitu GA4?
Łącznik GA4 pobiera dane przez Data API, które ma dzienne i godzinowe limity tokenów oraz limit równoczesnych żądań dla usługi. Raport z wieloma wykresami, długim zakresem dat i kilkoma oglądającymi jednocześnie szybko je wyczerpuje. Limity są wspólne dla wszystkich raportów korzystających z tej samej usługi GA4.
Czy mogę zwiększyć limity API GA4 dla Looker Studio?
W standardowej wersji GA4 nie da się wykupić wyższych limitów Data API. Wyższe limity, mniej więcej dziesięciokrotnie, ma GA4 360. W pozostałych przypadkach trzeba zmniejszyć liczbę zapytań: odchudzić raport, użyć wyodrębniania danych, buforować dane w Arkuszach albo przenieść raport na dane z BigQuery.
Czy wyodrębnianie danych rozwiązuje problem limitów?
W dużej mierze tak. Wyodrębnienie pobiera dane z GA4 raz, zapisuje migawkę do 100 MB i odświeża ją codziennie, co tydzień lub co miesiąc, więc oglądający nie wysyłają zapytań do API. Ograniczenia to stały zestaw pól, limit rozmiaru i brak danych z bieżącego dnia.
Czy raport oparty na BigQuery ma jakieś limity?
Nie podlega limitom Data API GA4, więc liczba wykresów i oglądających nie powoduje błędów przekroczenia limitu. Każde zapytanie do BigQuery jest jednak rozliczane według przeskanowanych danych. Dlatego raport należy podłączać do małych tabel z dziennymi agregatami, a nie bezpośrednio do surowych tabel eksportu GA4.
Skąd w tabeli bierze się wiersz „(other)”?
Wiersz „(other)” pojawia się, gdy wymiar ma bardzo dużo unikalnych wartości, np. pełny adres strony z parametrami albo wyszukiwane hasło, a GA4 grupuje rzadkie wartości w jedną pozycję. Pomaga skrócenie zakresu dat, wybór wymiaru o mniejszej liczbie wartości lub praca na surowych danych w BigQuery.