Der Wechsel war kein kosmetisches Update, sondern ein Bruch mit der bisherigen Logik. Universal Analytics dachte in Sitzungen und Seitenaufrufen: Ein Besuch wurde als zusammenhängende Sitzung gemessen, der Seitenaufruf war die zentrale Maßeinheit. GA4 dagegen denkt in Ereignissen (Events): Jede Interaktion – ein Seitenaufruf, ein Klick, ein Scroll, ein Videostart, ein Kauf – ist ein gleichwertiges Ereignis mit eigenen Parametern. Das ist näher an der Realität moderner Nutzung, in der Menschen zwischen Website, App und Geräten wechseln, erfordert aber ein grundlegendes Umdenken bei allen, die UA gewohnt waren.
Drei Eigenschaften definieren Google Analytics 4:
Hinter dem Generationswechsel stehen zwei Treiber. Erstens technisch: Das Sitzungsmodell von UA stammte aus einer Zeit, in der Nutzung gleich „Desktop-Browser mit Cookies“ bedeutete. Apps, datenschutzbedingte Cookie-Einschränkungen und geräteübergreifende Journeys ließen sich darin kaum abbilden. Zweitens regulatorisch: Der zunehmende Druck durch DSGVO, ePrivacy und Browser-seitige Tracking-Beschränkungen zwang Google zu einem Modell, das auch ohne durchgängiges Cookie-Tracking funktioniert – über Modellierung und einwilligungsbasierte Signale.
Kaum ein anderes Web-Werkzeug ist so verbreitet wie Google Analytics. Diese Marktdurchdringung ist Stärke und Schwäche zugleich. Stärke, weil es für GA4 ein riesiges Ökosystem an Schulungen, Vorlagen, Foren und Dienstleistern gibt – fast jede Frage ist schon einmal gestellt und beantwortet worden, und Fachkräfte mit GA4-Erfahrung sind leicht zu finden. Schwäche, weil genau diese Dominanz GA4 zum bevorzugten Prüfobjekt von Datenschutzbehörden und Verbänden macht. Wer GA4 einsetzt, bewegt sich also in einem gut dokumentierten, aber auch besonders beobachteten Umfeld.
Für die strategische Entscheidung bedeutet das: GA4 ist kein „Standard, den man unkritisch übernimmt“, sondern eine bewusste Wahl, die technische Vorteile gegen ein datenschutzrechtliches Restrisiko abwägt. Wer diese Abwägung sauber dokumentiert, Einwilligungen korrekt einholt und die Verarbeitung transparent macht, steht deutlich besser da als ein Unternehmen, das GA4 einfach „weil es alle nutzen“ einbindet. Die folgenden Kapitel liefern die Bausteine für genau diese fundierte Entscheidung.
GA4 ist für die meisten Unternehmen die naheliegende Wahl, wenn sie ohnehin im Google-Ökosystem arbeiten – Google Ads, Search Console, Google Tag Manager. Die Integration ist eng, der Funktionsumfang für ein kostenfreies Werkzeug außergewöhnlich. Gleichzeitig ist GA4 kein Selbstläufer: Unternehmen mit hohen Anforderungen an Datenhoheit, mit Sitz in besonders datenschutzsensiblen Branchen oder mit der klaren Vorgabe „keine US-Dienste“ sollten europäische Alternativen wie Matomo oder Piwik PRO ernsthaft prüfen. Die Entscheidung ist daher selten rein technisch.
In Universal Analytics war die Sitzung (Session) die Grundeinheit. Treffer-Typen wie Seitenaufruf, Ereignis, Transaktion oder Social-Interaktion waren jeweils eigene Kategorien mit eigener Logik. Eine Sitzung endete nach 30 Minuten Inaktivität oder um Mitternacht. Kennzahlen wie Absprungrate oder Sitzungsdauer bauten direkt auf dieser Struktur auf.
In GA4 ist alles ein Ereignis. Es gibt keine separaten Treffer-Typen mehr. Ein Seitenaufruf ist das Event page_view, ein Scroll das Event scroll, ein Kauf das Event purchase. Jedes Event trägt Parameter – kleine Zusatzinformationen wie Seitentitel, Linkziel oder Bestellwert. Diese Vereinheitlichung macht das Modell flexibel: Was gemessen wird, ist eine Frage der Definition, nicht der vorgegebenen Kategorie.
GA4 unterscheidet mehrere Klassen von Ereignissen. Automatisch erfasste Events entstehen ohne Konfiguration, sobald das Tag eingebunden ist – etwa der erste Besuch oder Sitzungsstart. Events aus „Enhanced Measurement“ (verbesserte Messung) lassen sich per Schalter aktivieren und erfassen Scrolls, ausgehende Klicks, Site-Suchen, Videointeraktionen und Datei-Downloads. Empfohlene Events sind von Google vordefinierte, aber selbst auszulösende Ereignisse mit standardisierten Namen – zum Beispiel für E-Commerce. Benutzerdefinierte Events schließlich bilden alles ab, was spezifisch für ein Unternehmen ist.
Diese Hierarchie ist praktisch wichtig: Wer GA4 nur einbindet und nichts weiter tut, bekommt bereits eine brauchbare Grundmessung. Der eigentliche Wert entsteht aber erst, wenn die unternehmensrelevanten Interaktionen – Anfrageformular, Download eines Datenblatts, Klick auf eine Telefonnummer – als saubere, benannte Events definiert werden.
Eine der häufigsten Fragen in der Praxis: „Warum zeigt GA4 ganz andere Zahlen als UA?“ Die Antwort liegt im Modell. UA zählte Sitzungen und Seitenaufrufe nach einer Logik, GA4 zählt Ereignisse und definiert Kennzahlen anders. Die klassische Absprungrate aus UA gibt es in GA4 nicht mehr in gleicher Form – an ihre Stelle tritt die Interaktionsrate (Engagement Rate), die positiv gewendet misst, wie viele Sitzungen als „engagiert“ gelten. Auch der Nutzer-Begriff unterscheidet sich, weil GA4 stärker auf modellierte und einwilligungsabhängige Daten setzt.
Daraus folgt eine wichtige Konsequenz: Ein direkter 1:1-Vergleich historischer UA-Daten mit GA4-Daten ist methodisch nicht zulässig. Die beiden Systeme messen unterschiedliche Dinge. Sinnvoll ist, GA4 ab dem Umstiegszeitpunkt als neue Baseline zu betrachten und Trends innerhalb von GA4 zu vergleichen – nicht GA4 gegen UA.
Die Explorationen sind das, was GA4 von einem reinen Reporting-Werkzeug zu einer Analyseplattform macht. Hier lassen sich Trichteranalysen bauen (Wie viele Nutzer durchlaufen Schritt 1 bis 4 eines Bestellprozesses?), Pfadanalysen erstellen (Welchen Weg nehmen Nutzer durch die Website?) und beliebige Dimensionen und Messwerte kombinieren. Der Preis dieser Flexibilität ist eine steilere Lernkurve: Wer aus UA kommt, empfindet die Explorationen anfangs als sperrig. Mit etwas Übung sind sie jedoch deutlich mächtiger als alles, was UA bot.
Ein zentraler Vorteil von GA4 ist die enge Verzahnung mit Google Ads. Als Key Event markierte Conversions lassen sich direkt für die Kampagnenoptimierung verwenden, Zielgruppen für Remarketing übertragen. Genau hier wird die Datenschutzfrage konkret: Sobald Daten zur Werbeaussteuerung an Google Ads übertragen werden, handelt es sich nicht mehr um reine Reichweitenmessung, sondern um eine Verarbeitung, die eine wirksame Einwilligung voraussetzt. Die technische Bequemlichkeit der Aktivierung und die rechtlichen Anforderungen gehören daher zusammen gedacht.
Technisch besteht eine GA4-Implementierung aus zwei Bausteinen: der Datenstream-Konfiguration in der GA4-Property (sie liefert die Mess-ID) und dem Tag, das diese Mess-ID auf der Website ausliefert. Dieses Tag lässt sich direkt per Code einbinden (Google-Tag, gtag.js) oder – der empfohlene Weg – über den Google Tag Manager verwalten.
Der Google Tag Manager ist ein Container, der zwischen Website und den verschiedenen Mess- und Marketing-Tags sitzt. Statt jedes Tracking-Snippet einzeln in den Quellcode zu schreiben, wird einmal der GTM-Container eingebunden; alle weiteren Tags – GA4, Google Ads, LinkedIn, Meta – werden danach komfortabel in der GTM-Oberfläche verwaltet. Der entscheidende Vorteil: Marketing und Analytics können Messpunkte anpassen, ohne dass jedes Mal die Entwicklung eingebunden werden muss.
GTM arbeitet mit drei Grundbausteinen: Tags (was ausgelöst wird, z. B. ein GA4-Event), Trigger (wann es ausgelöst wird, z. B. bei einem Formular-Versand) und Variablen (welche Werte mitgegeben werden, z. B. der Bestellwert). Den Datenaustausch zwischen Website und GTM übernimmt der Data Layer – eine strukturierte JavaScript-Schnittstelle, über die die Website Informationen an das Tag-Management übergibt. Ein sauber gepflegter Data Layer ist das Fundament jeder robusten GA4-Implementierung.
Eine zunehmend relevante Variante ist das serverseitige Tagging. Dabei läuft der GTM-Container nicht im Browser des Nutzers, sondern auf einem eigenen Server, über den die Daten zuerst geleitet und erst danach an GA4 weitergegeben werden. Das bringt mehr Kontrolle darüber, welche Daten den eigenen Verantwortungsbereich verlassen, und kann – sauber umgesetzt – aus Datenschutzsicht ein Baustein sein. Es ist allerdings technisch aufwendiger, verursacht Hosting-Kosten und ändert nichts an der grundsätzlichen Frage, ob und in welcher Form Daten an Google übermittelt werden. Server-side Tagging ist ein Werkzeug, kein Freibrief.
Der Kern der Abgrenzung lautet: Bei GA4 liegen die Daten in der Google-Infrastruktur, und Google ist als US-Konzern in die Verarbeitung eingebunden. Bei Matomo – insbesondere in der selbst gehosteten Variante – bleiben die Daten vollständig auf eigenen Servern; es findet kein Transfer an Dritte statt. Piwik PRO bietet einen Mittelweg: ein kommerzielles Produkt mit garantiertem EU-Hosting und einem auf europäisches Datenschutzrecht ausgerichteten Funktionsumfang. Für Organisationen, deren oberste Vorgabe „die Daten verlassen unseren Rechtsraum nicht“ lautet, ist das der entscheidende Unterschied.
Eine pauschale Empfehlung gibt es nicht. GA4 ist stark, wenn das Unternehmen ohnehin Google Ads schaltet und die enge Integration sowie der kostenlose Einstieg im Vordergrund stehen – vorausgesetzt, das Consent-Setup ist sauber. Matomo ist die naheliegende Wahl, wenn maximale Datenhoheit und Self-Hosting gewünscht sind und interne IT-Ressourcen für Betrieb und Updates vorhanden sind. Piwik PRO passt für Organisationen, die EU-Hosting und professionellen Support wollen, ohne selbst hosten zu müssen – häufig im öffentlichen Sektor, im Gesundheitswesen oder bei Banken und Versicherungen. In der Praxis ist die Entscheidung oft weniger eine Technik- als eine Governance-Frage.
Ein praktischer Aspekt wird in der Tool-Debatte häufig übersehen: der Betriebsaufwand. GA4 als gehosteter Dienst nimmt dem Unternehmen Updates, Skalierung und Verfügbarkeit vollständig ab – es entsteht kein eigener Wartungsaufwand. Self-Hosted Matomo verlagert diese Verantwortung ins Unternehmen: Server, Updates, Sicherung und Performance müssen selbst gewährleistet werden, was bei großem Traffic durchaus anspruchsvoll ist. Piwik PRO und die Matomo-Cloud liegen dazwischen, weil der Betrieb beim Anbieter bleibt, die Daten aber im europäischen Rechtsraum verarbeitet werden. Die Tool-Wahl ist damit nie nur eine Funktions- oder Datenschutzfrage, sondern auch eine Ressourcen- und Betriebsfrage – und sollte gemeinsam mit IT, Marketing und Datenschutz getroffen werden.
Die Diskussion entzündete sich an mehreren Entscheidungen europäischer Datenschutzbehörden in den Jahren 2022 und 2023, die den Einsatz von Google Analytics in der damaligen Konstellation als problematisch einstuften. Kern der Kritik war der Transfer personenbezogener Daten in die USA und die dortige Zugriffsmöglichkeit von Behörden – die nach dem „Schrems II“-Urteil des Europäischen Gerichtshofs als nicht ausreichend abgesichert galt.
Im Juli 2023 trat das EU-US Data Privacy Framework (DPF) in Kraft, ein neuer Angemessenheitsbeschluss der Europäischen Kommission. Für nach dem DPF zertifizierte US-Unternehmen – Google gehört dazu – gilt der Datentransfer in die USA seither als grundsätzlich zulässig, ohne dass es zusätzlicher Garantien bedarf. Das hat die Lage gegenüber dem Zeitraum vor 2023 deutlich entschärft. Allerdings: Datenschützer bezweifeln, dass das DPF einer erneuten gerichtlichen Prüfung standhält – Parallelen zu den gekippten Vorgängerabkommen „Safe Harbor“ und „Privacy Shield“ sind unübersehbar. Wer auf das DPF baut, baut auf eine derzeit gültige, aber rechtlich nicht endgültig gesicherte Grundlage.
In der fachlichen Diskussion stehen sich zwei Positionen gegenüber. Die eher zustimmende Sicht argumentiert: Mit DPF, abgeschlossenem AVV, deaktivierten Zusatzfreigaben, IP-Behandlung nach Google-Vorgaben und – vor allem – einer sauberen Einwilligung sei GA4 rechtlich vertretbar einsetzbar. Die eher kritische Sicht hält dagegen: Solange ein US-Konzern strukturell Zugriff auf Daten europäischer Nutzer haben kann und das DPF rechtlich angreifbar bleibt, sei ein Restrisiko unvermeidbar; risikoaverse Organisationen sollten europäische Alternativen wählen. Beide Positionen sind ernst zu nehmen – die Wahrheit liegt nicht in einem pauschalen Urteil, sondern in der konkreten Risikoabwägung des einzelnen Unternehmens.
Grundregel: Vor dem Setzen nicht zwingend erforderlicher Cookies und vor dem Laden von Analyse- und Marketing-Tags muss eine aktive Einwilligung der Nutzerin oder des Nutzers vorliegen. Diese Einwilligung wird über ein Cookie-Banner eingeholt, das von einer Consent-Management-Plattform (CMP) gesteuert wird. Die CMP speichert die Entscheidung und gibt sie an das Tag-Management weiter.
Der Consent Mode ist Googles Mechanismus, um das Verhalten der Google-Tags an die Einwilligungsentscheidung anzupassen. Er kennt mehrere Signale – unter anderem für Analyse-Speicherung (analytics_storage) und Werbe-Speicherung (ad_storage). Je nach Einwilligung werden diese auf „granted“ oder „denied“ gesetzt. Liegt keine Einwilligung vor, sendet GA4 im sogenannten Consent Mode v2 – der inzwischen verpflichtend ist, wenn Google-Werbedienste im Spiel sind – nur noch anonyme, cookielose Signale ohne Identifikatoren. Aus diesen Signalen versucht Google, fehlende Daten zu modellieren.
Hier ist Präzision wichtig: Der Consent Mode ist kein Ersatz für die Einwilligung. Er regelt nur, wie sich die Tags verhalten, nachdem die Einwilligungsentscheidung getroffen wurde. Ob die cookielosen Signale ohne Einwilligung gesendet werden dürfen, ist seinerseits eine datenschutzrechtliche Frage, die je nach Auslegung unterschiedlich bewertet wird. Der Consent Mode ist ein technisches Werkzeug, das die rechtliche Grundsatzentscheidung umsetzt – nicht ersetzt.
Es gibt zwei Implementierungsvarianten. Im Basic Consent Mode werden die Google-Tags erst nach erteilter Einwilligung überhaupt geladen – ohne Einwilligung passiert nichts, es werden auch keine cookielosen Signale gesendet. Im Advanced Consent Mode werden die Tags zwar geladen, senden aber ohne Einwilligung nur anonyme, cookielose Pings, aus denen modelliert wird. Der Advanced-Modus liefert mehr Daten, ist aber datenschutzrechtlich der heiklere Weg, weil bereits ohne Einwilligung Signale fließen. Die Wahl zwischen beiden Varianten ist eine bewusste Abwägung zwischen Datenmenge und rechtlicher Vorsicht.
In der Praxis greifen drei Komponenten ineinander: Die CMP holt die Einwilligung ein und stellt sie als Signal bereit. Der Google Tag Manager liest dieses Signal aus und steuert über Consent-Einstellungen und Trigger, ob und wann das GA4-Tag feuert. Wichtig ist, dass die CMP, GTM und GA4 dieselbe Logik abbilden – ein häufiger Fehler ist, dass das Banner „Ablehnen“ anzeigt, das GA4-Tag aber trotzdem feuert, weil der Trigger falsch konfiguriert ist. Eine sorgfältige Prüfung mit dem GTM-Vorschaumodus und einem Netzwerk-Mitschnitt ist daher unverzichtbar.
Bei großen Datenmengen oder komplexen Ad-hoc-Auswertungen greift GA4 auf Sampling zurück: Statt alle Ereignisse auszuwerten, wird eine Stichprobe analysiert und das Ergebnis hochgerechnet. Für grobe Trends ist das unproblematisch, für präzise Einzelwerte – etwa exakte Conversion-Zahlen in einem engen Segment – kann es zu Abweichungen führen. GA4 weist gesampelte Berichte aus; wer es genauer braucht, kommt am Rohdatenexport nach BigQuery kaum vorbei, weil dort ungesampelt ausgewertet werden kann.
Ein oft unterschätzter Punkt ist die Aufbewahrungsdauer. Für ereignisbezogene Nutzer- und Ereignisdaten lässt sich in der GA4-Standardversion nur zwischen begrenzten Zeiträumen wählen – die Voreinstellung ist bewusst kurz. Standardberichte mit aggregierten Daten sind davon weniger betroffen, aber detaillierte Explorationen mit nutzerbezogenen Dimensionen greifen auf die aufbewahrten Rohdaten zurück. Wer langfristige, granulare Auswertungen braucht, muss die Aufbewahrung bewusst konfigurieren und ergänzend Rohdaten exportieren. Hier kollidieren zwei Interessen: möglichst lange Datenhistorie für die Analyse versus möglichst kurze Speicherung aus Datenschutzgründen.
GA4 setzt an mehreren Stellen auf Modellierung. Conversions, die wegen fehlender Einwilligung oder cookieloser Sitzungen nicht direkt gemessen werden können, werden über Verhaltens- und Conversion-Modellierung statistisch geschätzt. Das macht die Berichte vollständiger, verändert aber ihren Charakter: Eine modellierte Conversion ist keine beobachtete Tatsache, sondern eine begründete Schätzung. Für die strategische Steuerung ist das in der Regel ausreichend, für die Abrechnung gegenüber Dritten oder für rechtlich heikle Auswertungen sollte man wissen, welcher Anteil der Zahlen gemessen und welcher modelliert ist.
Aus zahlreichen Projekten hat sich eine klare Reihenfolge bewährt: erst der Measurement Plan (was messen wir und warum), dann die Datenschutz-Grundlage (Rechtmäßigkeit klären, CMP und AVV aufsetzen), dann die technische Implementierung über GTM und schließlich das Reporting. Der häufigste Fehler im Mittelstand ist, mit der Technik zu beginnen und Datenschutz und Zieldefinition nachzuziehen. Das führt regelmäßig zu doppelter Arbeit, inkonsistenten Daten und rechtlichen Lücken.
Bevor GA4 implementiert wird, lohnt eine ehrliche Standortbestimmung: Wie wichtig ist die Google-Ads-Integration? Wie hoch ist die Sensibilität der verarbeiteten Daten? Gibt es interne Vorgaben zu US-Diensten? In manchen Fällen ist das Ergebnis dieser Prüfung, dass Matomo oder Piwik PRO besser passen. Diese Frage am Anfang zu stellen, ist deutlich günstiger, als nach einem Jahr Betrieb das Analytics-System zu wechseln.
