Grupy użytkowników w GA4: dostęp do konta pod kontrolą

Google dodało do Analytics grupy użytkowników. Wpis w dzienniku zmian z 5 października 2026 ma cztery punkty, więc większość zespołów go pominie. Jeśli dostęp do GA4 nadajesz więcej niż kilku osobom, to najbardziej użyteczna rzecz, jaką Google wydało w tym kwartale.

Większość firm nadal rozdaje dostęp adres po adresie. Przy trzech użytkownikach to działa. Przy trzydziestu nie. Kontraktor kończy pracę, agencja oddaje konto, klient dodaje kogoś z przejętego zespołu, a rok później nikt nie potrafi powiedzieć, kto nadal ma uprawnienia administratora.

Co dodało wydanie z 5 października

Wydanie obejmuje trzy operacje. Możesz utworzyć grupę, zmienić jej dane albo usunąć ją po identyfikatorze. Możesz dodawać użytkowników do grupy i usuwać ich z niej. Każdemu członkowi przypisujesz poziom uprawnień: Member albo Owner.

Do korzystania z API potrzebujesz uprawnienia User Admin albo Org Admin w organizacji, do której należy konto Analytics. Rola Editor na poziomie usługi nie wystarczy.

Grupa należy do organizacji, nie do usługi

Grupa nie należy do konta Analytics ani do usługi, tylko do organizacji, pod którą konto jest podpięte. Jeśli twoje konto nie jest powiązane z organizacją, Analytics poprowadzi cię przez jej utworzenie przy pierwszej próbie.

Grupy widzi tylko organizacja, która je utworzyła. Tworząc grupę, zostajesz jej właścicielem i możesz wyznaczyć kolejnych.

Członkostwo dodaje uprawnienia, nigdy nie odejmuje

Członkostwo się sumuje. Osoba w grupie dziedziczy uprawnienia grupy i zachowuje wszystko, co ma osobno. Grupy dodają dostęp, nigdy go nie zabierają. Przegląd dostępu, który zakłada, że wejście do grupy normalizuje czyjeś uprawnienia, stoi na błędnym założeniu.

Grupa może zawierać użytkowników i inne grupy, więc da się je zagnieżdżać. Przykład z dokumentacji to grupa Wszyscy pracownicy zawierająca grupę Europa. Zagnieżdżanie jest najkrótszą drogą do struktury, której nie da się zaudytować. Buduj jedną warstwę naraz.

Model uprawnień, na którym to siada

Pięć rol działa w całej hierarchii Analytics. Administrator ma pełną kontrolę i zarządza użytkownikami. Editor kontroluje ustawienia usługi, ale nie zarządza użytkownikami, choć widzi ich listę. Marketer tworzy grupy odbiorców, zdarzenia i zdarzenia kluczowe oraz zmienia ustawienia atrybucji. Analityk udostępnia eksploracje. Widz widzi ustawienia i dane.

Uprawnienia dziedziczą się w dół. Nadajesz Editor na poziomie konta i ta osoba jest Editorem w każdej usłudze w koncie, a na poziomie usługi nie da się tego odebrać. Obowiązuje rola najbardziej permisywna. Uprawnienia można dodawać, schodząc w hierarchię, nie można ich odejmować. To najczęstsza przyczyna porządkowania dostępu, które zatrzymuje się w połowie.

Do rol dochodzą dwie restrykcje danych: No Cost Metrics i No Revenue Metrics. Restrykcję można nadać bezpośrednio, ale nie da się zdjąć tej odziedziczonej. Nałożysz No Cost Metrics na poziomie konta i żadne ustawienie w usłudze tego nie odwróci. W raportach ograniczone wartości pokazują się jako zero, więc użytkownik może nie wiedzieć, że liczba, którą czyta, nie jest prawdziwa.

Dwa typy grup i jedna konwencja nazw

Wskazówka Google jest krótka: buduj tylko dwa rodzaje grup. Grupy osobowe odwzorowują strukturę zespołu, grupy ról odwzorowują zakres uprawnień potrzebny do pracy. Ustal też konwencję nazw, żeby odróżnić jedno od drugiego i nie tworzyć duplikatów.

Przykłady z dokumentacji to Direct Reports: Jan Kowalski dla grupy osobowej i Data Analysts: EMEA dla grupy ról. Zacznij od grup ról, bo role zmieniają się rzadko, a ludzie często.

Czego nie włożysz do grupy

Nie wszystkie uprawnienia da się przypisać grupie. W Google Tag Managerze uprawnienie Admin na poziomie konta oraz Approve i Publish na poziomie kontenera muszą zostać na pojedynczych osobach.

Praktyczny skutek jest taki, że grupa wszystkich osób pracujących nad kontenerem nie może publikować. Publikacja zostaje odpowiedzialnością konkretnej osoby, więc każda zmiana w kontenerze ma człowieka, którego można o nią zapytać.

Co naprawdę stoi za API

Strona pomocy nazywa nową funkcję User Groups Admin API. W dokumentacji dla deweloperów nie ma API o tej nazwie. Metody należą do Google Marketing Platform Admin API, usługa marketingplatformadmin.googleapis.com w wersji v1alpha, a dziennik zmian dla deweloperów datuje je na 18 września 2026.

Wydanie dodaje czternaście metod w trzech partiach. Pięć dotyczy samych grup: pobranie, lista, utworzenie, aktualizacja i usunięcie. Pięć dotyczy członkostwa, z tym samym zestawem operacji. Cztery dotyczą powiązań ról administracyjnych i pozwalają nadać roli organizacji, takiej jak organization admin albo billing admin, użytkownikowi lub grupie.

Jeden brak zasługuje na uwagę. Grupę i członka można usunąć. Powiązania roli administracyjnej nie usuniesz żadną z wymienionych metod, a ani dziennik zmian, ani strona referencyjna nie opisują takiego wywołania. Dla skryptu offboardingu to luka: nadanie roli administratora organizacji przez API jest możliwe, odebranie jej jednym wywołaniem nie jest udokumentowane.

Całość działa w wersji alpha od 6 marca 2024. Nazwy metod i pola mogą się zmienić bez okresu przejściowego.

Co automatyzować, a czego nie

Realistyczne cele to zadania, które się starzeją: skrypt dodający nowego analityka do grupy ról, skrypt usuwający odchodzącą osobę i wypisujący grupy, w których jeszcze występuje, oraz kwartalne oznaczanie grup bez członków.

Jeden szczegół należy do samego procesu dodawania. Gdy dodajesz użytkownika do grupy, staje się on członkiem organizacji, jeśli wcześniej nim nie był. To zmiana tożsamości, więc powinna być świadomym krokiem z wpisem w logu.

Przy odejściu liczą się dwa mechanizmy. Usunięcie użytkownika z usługi źródłowej usuwa go z jej usług podrzędnych, a usunięcie z usługi podrzędnej tylko tam. Ostatni administrator nie usunie siebie, dlatego grupa z uprawnieniami administratora potrzebuje nazwanego właściciela spoza zespołu, który może odejść.

Strona zgodności

Kontrola dostępu to pytanie o odpowiedzialność, a nie o porządek. Art. 32 RODO wymaga środków technicznych zapewniających poufność, integralność i dostępność danych. Możliwość pokazania, kto co widzi, i odebrania tego dostępu przy odejściu, to dowód, o który pyta organ nadzorczy. Struktura grup z nazwanymi właścicielami jest tym dowodem.

Do tego dochodzi drugie pytanie: czy pomiar wymagający zgody jest oddzielony od reszty danych. Sama grupa tego nie rozstrzyga, ale przegląd dostępu powinien to sprawdzić.

Przegląd dostępu w siedmiu krokach

1. Wypisz wszystkie osoby na poziomie konta i posortuj po roli. Przy każdym administratorze zapisz nazwisko i powód. Czego nie umiesz uzasadnić, jest ustaleniem.
2. Wypisz wszystkie grupy i dopasuj każdą do realnego zespołu albo roli. Grupa bez właściciela lub bez członków jest albo szumem, albo ryzykiem.
3. Znajdź zduplikowany dostęp. Rola bezpośrednia i rola z grupy sumują się, a przegląd musi zapisać sumę.
4. Sprawdź restrykcje. Kto nie powinien widzieć przychodów albo kosztów, ma mieć odpowiednią restrykcję, a odziedziczonej nie zdejmiesz niżej w hierarchii.
5. Sprawdź użytkowników, których nie dodałeś. Podpięte projekty Firebase i konta Google Ads tworzą użytkowników połączonych automatycznie, z rolami, których nikt z zespołu nie nadawał.
6. Przejrzyj konwencję nazw i typy grup. Grupa osobowa z uprawnieniami ról to zwykle pomyłka, nie decyzja.
7. Zapisz wynik do rejestru dostępu z datą. Sam przegląd bez zapisu niczego nie dowodzi.

API jest małe, a wartość nie siedzi w metodach. Siedzi w strukturze, którą nimi zbudujesz. Zdefiniuj grupy ról, nazwij je konsekwentnie, ustaw restrykcje danych tam, gdzie ich miejsce, i zautomatyzuj przyjścia oraz odejścia. Zrób to raz, a dostęp przestanie być coroczną paniką.

Sprawdź, kto dziś ma uprawnienia administratora w twoich kontach Analytics, zanim oprzesz na tym skrypt.