GA4-Zugriffe mit der User Groups API verwalten

Management Summary
Die User Groups API verwaltet Teams und Mitgliedschaften innerhalb einer Google-Marketing-Platform-Organisation. Das hilft bei Analytics-Projekten mit wechselnden Zuständigkeiten: Zugänge lassen sich geordnet vorbereiten und beim Ausscheiden wieder prüfen. Gruppenverwaltung und Zugriffsrechte erfüllen dabei unterschiedliche Aufgaben. Erst der Abgleich mit den wirksamen Rechten zeigt, welcher Zugang zu einem Analytics-Konto oder einer Property tatsächlich besteht.
Inhalt
Ein Teamwechsel beginnt mit einer Liste
Ein Projekt endet, eine Agentur wechselt, ein neues Team übernimmt die Auswertung. Die Berichte bleiben bestehen, die Zuständigkeiten ändern sich. Genau hier hilft eine gepflegte Gruppenverwaltung: Ein fest benanntes Team lässt sich leichter kontrollieren als eine Sammlung einzelner Einladungen.
Was seit Oktober neu ist
Google hat die User Groups Admin API am 5. Oktober 2026 angekündigt. Gruppen lassen sich anlegen, lesen, ändern und löschen; zusätzlich stehen Funktionen für Mitgliedschaften bereit. Die technische Schnittstelle gehört zur Google Marketing Platform Admin API. Die dokumentierten Ressourcen verwenden derzeit v1alpha. Eine Versionsbindung und die Prüfung späterer Änderungen gehören deshalb zum Betrieb.
Gruppe und Berechtigung getrennt betrachten
Eine Gruppe enthält zunächst einen Namen, eine Beschreibung und Mitgliedschaften. Eine Gruppenrolle wie Member oder Owner beschreibt die Stellung innerhalb dieser Gruppe. Daraus folgt nicht automatisch eine bestimmte Analytics-Rolle wie Viewer oder Editor. Die Zugriffsverwaltung des jeweiligen Kontos oder der Property legt den Zugang fest. Für die neuen API-Funktionen nennt Google User Admin oder Org Admin als Voraussetzung auf Organisationsebene.

Ein überschaubarer Ablauf
Der Einstieg ist ein lesender Bestandsabgleich. Für jede Gruppe werden Kennung, Zweck, verantwortliche Stelle und Mitgliedschaften festgehalten. Anschließend folgt eine Soll-Liste aus der zuständigen Projektverwaltung. Der Vergleich zeigt fehlende Mitglieder, nicht mehr benötigte Mitgliedschaften und Gruppen ohne klaren Zweck. Änderungen erfolgen in kleinen, überprüfbaren Schritten; nach jedem Schreibschritt folgt ein erneuter Abruf.
Warum Entfernen allein nicht genügt
Ein fiktives Beispiel: Ein Projektkonto besitzt Zugang über die Gruppe Analyse und zusätzlich direkt auf einer Property. Nach dem Entfernen aus Analyse bleibt der direkte Zugang bestehen. Dasselbe gilt sinngemäß für andere weiterhin wirksame Zuweisungen. Beim Offboarding muss deshalb die effektive Berechtigung geprüft werden. Ein erfolgreicher Löschaufruf bestätigt nur die einzelne Änderung.
Ein sinnvoller Prüfbericht
Ein interner Bericht braucht keine lange Liste persönlicher Daten. Gruppenschlüssel, Änderungstyp, betroffene Ressource, Zeitpunkt und Prüfergebnis genügen häufig für den technischen Nachweis. Personenbezogene Mitgliederdaten gehören in eine zugriffsgeschützte Ablage. Wiederholte Läufe sollen denselben Soll-Zustand herstellen, statt identische Gruppen erneut anzulegen.
Measurement Summary
Vorgeschlagen werden drei Prüfgrößen: Abweichungen vom freigegebenen Mitgliederbestand, Gruppen ohne dokumentierte Zuständigkeit und nach dem Offboarding verbleibende Zugriffswege. Der Beitrag beschreibt einen dokumentationsgestützten Ablauf. Ein authentifizierter Schreibtest in einer Kundenorganisation wurde nicht durchgeführt.
Fragen und Antworten
Erteilt eine neue Gruppe sofort Zugriff auf GA4?
Die Gruppe allein belegt keinen Zugriff. Entscheidend sind die Zuweisungen auf Konto- oder Property-Ebene und die daraus entstehenden effektiven Rechte.
Reicht das Entfernen aus einer Gruppe beim Offboarding?
Weitere direkte oder geerbte Berechtigungen können bestehen bleiben. Der Abschluss erfordert daher eine Kontrolle aller wirksamen Zugriffswege.
Ist ein öffentliches Verwaltungswerkzeug sinnvoll?
Für echte Mitgliedschaften wäre eine Anmeldung mit weitreichenden Rechten nötig. Als erster Schritt eignet sich ein interner, lesender Soll-Ist-Abgleich besser.


