Na początku 2026 roku mniej więcej 1 na 3 niskoobjętościowe usługi GA4 uruchamia progowanie danych w co najmniej jednym standardowym raporcie, co oznacza, że GA4 po cichu ukrywa wiersze i raportuje sumę, która nie pasuje do liczb, które widzisz — a większość analityków bierze to za zepsute śledzenie. Progowanie danych to funkcja prywatności, a nie błąd, a naprawa nigdy nie polega na ściganiu fantomowego tagu; polega na zmianie warunków, które każą GA4 tłumić wiersze w pierwszej kolejności.
Ten przewodnik przechodzi przez siedem pytań — czym jest progowanie, jak je rozpoznać, dlaczego uruchamiają je Google signals, jak je łagodzić, czego nie da się odzyskać i jak wybrać swoją reporting identity — abyś działał na przyczynę, a nie na objaw. Aby sprawdzić, jak czysta jest Twoja konfiguracja pomiarowa na każdej osi, uruchom nasz darmowy audyt śledzenia na 5 osiach.
Zaktualizowano 2026-05-16 o aktualne zachowanie progów danych GA4, reporting identity i Google signals zaobserwowane na kontach w USA, Wielkiej Brytanii i Europie.
- Progowanie to prywatność, a nie błąd — GA4 ukrywa wiersze, gdy liczba użytkowników jest zbyt mała, by zachować anonimowość. 2. Sumy biją sumy wierszy — suma pochodzi z pełnego zbioru danych, podczas gdy stłumione wiersze pozostają ukryte, więc kolumna sumuje się do mniej. 3. Google signals to główny wyzwalacz — signals plus tożsamość Blended lub Observed wymuszają najsurowsze progi. 4. Device-based usuwa większość progów — kosztem deduplikacji cross-device i danych demograficznych. 5. Ukryte wiersze przepadły — nie możesz ich odzyskać dla tego raportu, ale eksport do BigQuery omija progi w stylu raportów.
Czym jest progowanie danych w GA4 i dlaczego jest stosowane?
Progowanie danych to pierwsza rzecz do zrozumienia, ponieważ wyjaśnia niemal każdą mylącą lukę w raportowaniu GA4. To celowa kontrola prywatności, a nie awaria śledzenia, i gdy raz ją rozpoznasz, reszta diagnozy układa się na miejsce.
Progowanie danych — GA4 ukrywa jeden lub więcej wierszy z raportu, gdy liczba użytkowników stojących za tymi wierszami jest zbyt mała, by zachować anonimowość osób. Próg jest stosowany w czasie zapytania, więc te same dane mogą być progowane w jednym widoku, a w innym nie.
Uzasadnienie prywatnościowe — Gdy wiersz reprezentuje bardzo niewielu użytkowników i jest rozbity według ujawniającego wymiaru, takiego jak Age lub Gender, jego pokazanie mogłoby skutecznie zidentyfikować osobę. GA4 tłumi te wiersze, aby honorować swoje gwarancje anonimowości, które zaostrzają się, gdy w grę wchodzą sygnały demograficzne lub o zainteresowaniach.
Dlaczego niskoobjętościowe wiersze są najbardziej dotknięte — Wiersze o dużym ruchu agregują wystarczająco wielu użytkowników, by przekroczyć minimum, więc wyświetlają się normalnie. Wiersze, które znikają, to niemal zawsze cienkie wycinki: rzadkie urządzenie, wąski przedział wiekowy lub mała geografia w krótkim zakresie dat.
Nie da się wyłączyć progowania jednym przełącznikiem. Aby zobaczyć, jak współgra z raportowaniem płatnego pozyskiwania ruchu, przeczytaj nasz przewodnik po analizie kohort w GA4.
Jak rozpoznać ikonę progowania i niezgodne sumy?
Gdy już wiesz, że progowanie istnieje, jego rozpoznanie zajmuje sekundy. Dwa pewne sygnały to mała ikona i niezgodność arytmetyczna, której żaden błąd śledzenia nie wytworzyłby tak czysto.
Ikona — Mały pomarańczowy lub szary wskaźnik pojawia się obok tytułu raportu lub tabeli danych, gdy zastosowano próg. Najechanie na niego potwierdza prostym językiem, że progowanie danych jest aktywne i wiersze zostały ukryte ze względu na prywatność.
Luka między sumą a wierszami — GA4 oblicza sumę raportu z kompletnego, niefiltrowanego zbioru danych, a następnie ukrywa wiersze, które spadają poniżej progu, przed renderowaniem. Wynikiem jest suma większa niż widoczne wiersze dodane ręcznie. Różnica to dokładnie stłumiony ruch.
Wykluczanie prawdziwych awarii śledzenia — Prawdziwy problem ze śledzeniem zazwyczaj objawia się jako zera lub dziko błędne liczby wszędzie, a nie jako czysta luka między uczciwą sumą a krótszą listą wierszy. Jeśli suma wygląda poprawnie i tylko podział jest krótki, podejrzewaj progowanie, zanim podejrzejesz tag.
Gdy luka pojawia się konkretnie w konwersjach przypisanych Google Ads, przyczyną może być pomiar, a nie progowanie; nasz przewodnik po rozbieżnościach konwersji rozdziela te dwie sprawy.
Dlaczego Google signals w reporting identity to uruchamiają?
Gdy objaw jest rozpoznany, kolejne pytanie brzmi: co tak naprawdę włącza progowanie. W przeważającej większości przypadków odpowiedzią są Google signals współdziałające z Twoją reporting identity.
Google signals — To ustawienie pozwala GA4 powiązać sesje z zalogowanymi użytkownikami Google, którzy mają włączone spersonalizowane reklamy, wzbogacając raporty o ścieżki cross-device oraz Age, Gender i Interests. To wzbogacenie demograficzne jest dokładnie tym, co podnosi poprzeczkę prywatności i przynosi progowanie.
Reporting identity — GA4 oferuje tożsamości Blended, Observed i Device-based. Blended i Observed obie opierają się na Google signals, by zszywać użytkowników, więc obie dziedziczą surowszy próg. Device-based ignoruje signals w raportowaniu i dlatego unika większości progów demograficznych.
Kompromis — Przełączenie tożsamości na Device-based usuwa większość progów i sprawia, że sumy pasują do wierszy, ale rezygnujesz z deduplikacji cross-device i wymiarów demograficznych, które dają signals. Signals nadal zbierają dane do odbiorców w tle; po prostu przestają zasilać te raporty.
To prawdziwy wybór między bogatszymi danymi a raportowaniem bez progów, a nie darmowa naprawa. Aby poznać nadrzędną instalację konwersji, od której to zależy, zobacz naszą konfigurację importu konwersji GA4.
Jak łagodzić progowanie bez utraty wglądu w dane?
Nie możesz wyłączyć progowania, ale cztery dźwignie niezawodnie zmniejszają to, jak często gryzie. Stosuj je w kolejności od najmniej do najbardziej zakłócającej, abyś zachował jak najwięcej wglądu.
Rozszerz zakres dat — Krótkie okno 7-dniowe pozostawia wiele wierszy poniżej minimalnej liczby użytkowników. Wydłużenie do 28 lub 90 dni agreguje więcej użytkowników na wiersz, wypychając cienkie wycinki powyżej progu i przywracając je do widoku.
Zmniejsz liczbę wymiarów — Każdy dodatkowy wymiar dzieli tych samych użytkowników na mniejsze kubełki. Raportowanie na jednym lub dwóch wymiarach zamiast czterech utrzymuje każdy wiersz zaludniony, więc usunięcie drugorzędnego podziału często natychmiast ujawnia wiersze.
Usuń wymiary demograficzne — Age, Gender i Interests to najagresywniej progowane pola, ponieważ pochodzą z Google signals. Usunięcie ich z raportu często usuwa ikonę, nawet gdy ogólnie zostawiasz signals włączone.
Używaj Explore świadomie — Explore może progowanie stosować inaczej niż raporty standardowe, więc odbudowanie tego samego pytania jako eksploracji z mniejszą liczbą wymiarów i tożsamością Device-based czasem ujawnia więcej wierszy. Potwierdź, że luka to prywatność, a nie zerowy ruch, względem naszego przewodnika po śledzeniu ruchu z poleceń.
Jakich danych nigdy nie odzyskasz, gdy zostaną ukryte?
Łagodzenie ogranicza przyszłe progowanie, ale ważne jest, by być szczerym co do granic. Niektóre dane po prostu przepadły dla raportu, który je ukrył, a ich ściganie marnuje czas.
Same stłumione wiersze — Gdy GA4 ukryje wiersze dla konkretnego zapytania raportu, nie ma ustawienia, eksportu ani zgłoszenia do wsparcia, które zwróci te dokładne wiersze dla tego widoku. Zostały usunięte przed wyrenderowaniem raportu.
Dlaczego zdarzenia nadal istnieją — Bazowe zdarzenia zostały zebrane normalnie; stłumiona została tylko ich prezentacja. Dlatego zmiana zapytania — szerszy zakres dat, mniej wymiarów, tożsamość Device-based — może pokazać tych samych użytkowników przedstawionych inaczej, mimo że pierwotne progowane wiersze pozostają ukryte.
Furtka ratunkowa BigQuery — Eksport surowych danych zdarzeń do BigQuery daje Ci rekordy na poziomie wierszy, które nie podlegają tym samym progom prywatności w stylu raportów. Zespoły, które potrzebują szczegółowej, kompletnej analizy, coraz częściej traktują BigQuery jako źródło prawdy i używają raportów GA4 do szybkich codziennych widoków.
Zaakceptuj granicę: nie odzyskujesz starych progowanych wierszy, wybierasz inną soczewkę na dane, które zawsze tam były. Zbuduj tę soczewkę poprawnie od początku z pomocą naszego przewodnika po eksploracjach i kohortach.
Tabela diagnostyczna progowania danych w GA4
Przejdź przez tę tabelę od góry do dołu — jest uporządkowana od najszybszych sprawdzeń, które potwierdzają progowanie, po głębsze decyzje o reporting identity i danych szczegółowych.
Gdy suma raportu GA4 wygląda poprawnie, ale wiersze pod nią sumują się do mniej, nie zaczynaj debugować tagów, ponownie wyzwalać zdarzeń ani reinstalować SDK. Ta czysta luka to niemal zawsze progowanie danych, a przebudowa śledzenia marnuje godziny, niczego nie zmieniając. Najpierw najedź na ikonę. Jeśli potwierdzi progowanie, problemem jest reporting identity i wymiary, a nie Twój pomiar — a zła naprawa może zepsuć konfigurację, która działała idealnie.
Wybrać dane cross-device czy raporty bez progowania?
Ostatnia decyzja to prawdziwy kompromis i nie ma uniwersalnie poprawnej odpowiedzi. Wybierz na podstawie tego, który tryb awarii bardziej szkodzi Twoim decyzjom: brakujące wiersze czy podwójnie liczeni użytkownicy.
Wybierz bogatsze dane cross-device, gdy — Dane demograficzne, zdeduplikowane ścieżki i odbiorcy do remarketingu napędzają Twoją strategię. Zostaw Google signals włączone i tożsamość Blended lub Observed, zaakceptuj progowanie niskoobjętościowych wierszy i opieraj się na szerszych zakresach dat i mniejszej liczbie wymiarów, by codzienne raporty były czytelne.
Wybierz raportowanie bez progów, gdy — Interesariusze potrzebują raportów standardowych, których sumy wierszy pasują do całości, a Ty możesz żyć bez szczegółów demograficznych. Przełącz reporting identity na Device-based; progi w dużej mierze znikają, choć niektórzy użytkownicy na wielu urządzeniach liczą się więcej niż raz.
Wybierz BigQuery, gdy — Potrzebujesz zarówno szczegółowości, jak i kompletności. Eksport surowych zdarzeń daje dane na poziomie wierszy bez progów w stylu raportów, pozwalając raportom standardowym GA4 pozostać szybkimi i przybliżonymi, podczas gdy hurtownia trzyma precyzyjny zapis.
Zdecyduj raz, udokumentuj to i utrzymuj raportowanie spójne, by trendy pozostały porównywalne w czasie. Aby przetestować pod presją całą swoją konfigurację, uruchom darmowy audyt śledzenia na 5 osiach SteerAds, a aby utrzymać tagowanie kampanii czyste i spójne, buduj linki naszym narzędziem UTM builder.
Sources
Oficjalne źródła konsultowane na potrzeby tego przewodnika:
-
support.google.com — about data thresholds
-
support.google.com — reporting identity
-
support.google.com — about Google signals
-
support.google.com — about Analytics
FAQ
Czym jest progowanie danych w GA4?
Progowanie danych to mechanizm prywatności, który GA4 stosuje automatycznie, aby ukryć wiersze w raporcie, gdy liczba użytkowników stojących za nimi jest zbyt mała, by zachować anonimowość. Najczęstszym wyzwalaczem jest aktywne Google signals w Twojej reporting identity, ponieważ dane demograficzne i o zainteresowaniach w niskoobjętościowym wierszu mogłyby zidentyfikować pojedynczą osobę. Gdy próg zostaje przekroczony, GA4 usuwa te wiersze z widoku, dlatego suma raportu może być większa niż widoczne wiersze zsumowane ręcznie. Nie da się wyłączyć progu wprost; zmieniasz warunki, które go powodują. Mniej więcej 1 na 3 niskoobjętościowe usługi GA4 widzą progowanie w co najmniej jednym standardowym raporcie.
Dlaczego suma mojego raportu GA4 nie zgadza się z sumą wierszy?
Ponieważ GA4 oblicza sumę z kompletnego, niefiltrowanego zbioru danych, ale następnie ukrywa pojedyncze wiersze, które spadają poniżej progu prywatności, zanim Ci je pokaże. Ukryte wiersze nadal przyczyniają się do sumy, więc kolumna sumuje się do wartości mniejszej niż liczba u góry. To oczekiwane zachowanie, a nie błąd ani problem ze śledzeniem. Mała pomarańczowa lub szara ikona obok tytułu raportu sygnalizuje, że progowanie jest aktywne. Jeśli rozszerzysz zakres dat, usuniesz wymiary demograficzne lub przełączysz reporting identity na Device-based, mniej wierszy spadnie poniżej progu, a widoczna suma zbliży się do całości.
Jak pozbyć się ikony progowania w GA4?
Zmniejszasz warunki, które ją wyzwalają, zamiast ją wyłączać. Po pierwsze, przełącz reporting identity z Blended lub Observed na Device-based, co zatrzymuje używanie Google signals i usuwa demograficzny wyzwalacz prywatności w większości raportów. Po drugie, rozszerz zakres dat, aby każdy wiersz agregował więcej użytkowników. Po trzecie, usuń wymiary demograficzne i o zainteresowaniach, takie jak Age, Gender i Interests, z widoku. Po czwarte, odbuduj analizę w Explore, które często progowanie stosuje inaczej niż raporty standardowe. Żaden z tych kroków nie odzyskuje dokładnie ukrytych wierszy, ale razem zazwyczaj usuwają ikonę z większości codziennych raportów w ciągu kilku minut.
Czy Google signals powodują progowanie w GA4?
Tak — Google signals to najczęstsza pojedyncza przyczyna. Gdy signals są włączone, a Twoja reporting identity to Blended lub Observed, GA4 wzbogaca sesje o dane demograficzne i o zainteresowaniach powiązane z zalogowanymi użytkownikami Google, a ten dodatkowy szczegół wymusza surowszy próg prywatności. Kompromis jest realny: signals dają Ci ścieżki cross-device, raportowanie Age, Gender i Interests oraz odbiorców do remarketingu, ale przynoszą też progowanie. Przełączenie reporting identity na Device-based utrzymuje signals zbierające w tle dane do odbiorców, jednocześnie usuwając je z raportowania, co usuwa większość progów kosztem utraty wymiarów demograficznych w tych konkretnych raportach.
Czy Explore unika progowania lepiej niż raporty standardowe?
Często, ale nie zawsze. Eksploracje w Explore i raporty standardowe mogą stosować progi inaczej, ponieważ odpytują dane z odmienną logiką próbkowania i tożsamości, więc analiza progowana w raporcie standardowym czasem pokazuje więcej wierszy w Explore, a sporadycznie odwrotnie. Pewne korzyści w Explore to używanie mniejszej liczby jednoczesnych wymiarów na wiersz oraz wybór reporting identity Device-based dla eksploracji. Explore pozwala też potwierdzić, czy luka to progowanie, czy faktycznie zerowy ruch. Traktuj Explore jako jeden z 4 sposobów łagodzenia, a nie gwarantowane rozwiązanie, i zawsze sprawdzaj ikonę jakości danych na samej eksploracji.
Czy mogę odzyskać dane, które GA4 ukryło za progiem?
Nie — gdy GA4 ukryje wiersze dla danego zapytania raportu, nie możesz odzyskać tych dokładnych wierszy dla tego widoku i nie ma ustawienia, które je wyeksportuje. Bazowe zdarzenia nadal zostały zebrane, więc czasem możesz zobaczyć tych samych użytkowników przedstawionych inaczej, zmieniając zapytanie: szerszy zakres dat, mniej wymiarów lub reporting identity Device-based. Dla szczegółowej analizy bez progów wiele zespołów eksportuje surowe dane zdarzeń do BigQuery, gdzie progi prywatności na poziomie wierszy nie obowiązują w ten sam sposób. Ale konkretne stłumione wiersze w pierwotnym progowanym raporcie przepadły dla tego raportu i nie da się ich ujawnić wstecznie.
Czy powinienem używać reporting identity Device-based, aby uniknąć progów?
To zależy, co cenisz bardziej. Reporting identity Device-based powstrzymuje GA4 od używania Google signals w raportach, co usuwa większość progów i sprawia, że sumy wierszy pasują do całości — ale tracisz deduplikację cross-device i wymiary demograficzne, więc użytkownik na telefonie i laptopie może zostać policzony dwukrotnie. Blended lub Observed dają bogatsze, zdeduplikowane ścieżki cross-device i dane demograficzne, kosztem progowania niskoobjętościowych wierszy. Jeśli potrzebujesz czystych, kompletnie wyglądających raportów standardowych, wybierz Device-based. Jeśli potrzebujesz dokładności cross-device i sygnałów o odbiorcach, zostaw signals włączone i łagodź progowanie w inny sposób.