Markus Baersch

Bevor Universal Analytics Ende 2023 den Zugriff auf die bisher gesammelten Daten durch komplette Einstellung des Dienstes unmöglich macht, wünschen viele Anwender eine Sicherung. Sei es, um die künftig in GA4 oder einem anderen Tool gesammelten Daten mit historischen Werten zu vergleichen oder um eine separate Datenbank anzulegen, in der zumindest bei Bedarf auf die alten Zahlen zurückgegriffen werden kann.

Davon ausgehend, dass ein Import von GA Daten in ein anderes Webanalyse-Werkzeug (m. E. einschließlich GA4, falls so etwas noch kommen sollte) kaum einen Sinn ergibt, weil die grundlegenden Konzepte zweiter Lösungen i. d. R. schlichtweg inkompatibel sind, soll hier vor allem betrachtet werden, welche Daten in welcher Form aus Universal Analytics extrahiert und gesichert werden können. Vorher aber: Warum das Ganze überhaupt?

Braucht man überhaupt eine Sicherung?

Grundsätzlich mag es bereits reichen, wenn es statische Fassungen von Data Studio Reports oder ein paar exportierte Übersichten aus Universal Analytics gibt, um die eigene Neugier zu befriedigen. Oder um einfache Reports grundlegender Kennzahlen auf Monatsbasis weiter fortführen zu können. Ja, Universal Analytics geht weg und man mag vielleicht schon seit sehr langer Zeit damit gearbeitet und Daten gesammelt haben. Aber was davon wird wirklich gebraucht? Wann hat man das letzte Mal in Daten aus 2015 schauen müssen, um eine heute relevante Frage zu beantworten - und in welcher Eintauchtiefe sind dazu Daten erforderlich?

Die allererste Frage muss also sein, was genau benötigt wird... und über welchen Zeitraum. Danach kann man sich darum kümmern, wie die Daten aus UA herauskommen (und wo sie hin sollen). Wobei das endgültige Ziel der Daten nicht so gewichtig ist, wie die Frage nach der "Befreiung" aus GA. Denn wenn die benötigten Informationen einmal in ausreichender Zusammenstellung und Detailtiefe in einem Standardformat untergebracht sind - sei es eine SQL Datenbank, Big Query oder nur ein paar Excel- oder CSV Dateien -, ist es ungleich einfacher, aus diesem Format eine beliebige Zielanwendung oder Datenbank zu bedienen - oder für Auswertungen historischer Daten wieder Tools wie Data Studio & Co. zuzuführen.

Wege zum Datenexport

Um an die Daten in Universal Analytics zu kommen, existieren grundsätzlich zwei Optionen: Der Export von beliebigen bestehenden oder benutzerdefinierten Reports oder die Extraktion über APIs. Wobei man APIs nicht unbedingt manuell ansteuern muss, sondern darüber Verbindungen zu Data Studio, Google Sheets u. a. bestehen, die eine Extraktion ermöglichen.

Dazu gehört unter anderem das Google Analytics Spreadsheet Add-on oder der Universal Analytics Query Explorer - beide sehr hilfreich, wenn man nicht aufgrund der Menge an verschiedenen Reports oder zu bedienenden Properties individuelle Programmierung vorziehen muss, weil manuelle Arbeit schlichtweg zu aufwändig wird.

Selbst ohne diese Hilfsmittel kann theoretisch ein Export direkt aus GA als Quelle dienen - dazu sind Standardformate wie CSV / TSV und Excel im Angebot. Reports direkt aus GA exportieren ist damit zwar en ein möglicher, aber i. d. R zu mühseliger Weg, um alle gewünschten Daten zu retten, bevor sie Ende 2023 nicht mehr zugänglich sein werden. Eine echte Lösung seitens Google gibt es noch nicht - und eine Migration von UA Daten nach GA4 ist wie eingangs schon angesprochen aus mehreren Gründen sowohl unsinnig als auch unwahrscheinlich. Jedenfalls ab einem gewissen Grad der Granularität der Daten. Extraktion via Query Explorer oder Google Spreadsheet Add-on sind da i. d. R. bessere Lösungen weil man hier einfacher an Ergebnisse gelangt. Doch auch auf diesem Weg bekommt man nicht "alle" Daten.

Warum jeder Export ab einem gewissen Grad "tot" ist

• Um wirklich in der Lage zu sein, alle Daten so zu exportieren, dass man damit später wirklich alle denkbaren Ergebnisse reproduzieren kann, die in Universal Analytics als "lebendige" Reports bereitstanden, wäre ein Rohdatenexport erforderlich. Und zwar mit allen benötigten Dimensionen, um daraus anschließend wieder ein vollständiges Bild der einzelnen Sequenzen von Ereignissen (AKA Sitzungen) nachzuvollziehen; einschließlich der dabei erreichten Ziele, der Quelle des Besuchs, Status und Historie der Besucher und so weiter.
• Das geht aber aus mehreren Gründen nicht - solange uns Google dies nicht ggf. doch noch bis zum Wegfall von Universal Analytics anbieten wird. Denn es gilt:
• Nur wer benutzerdefinierte Dimensionen mit Daten zu User, Sitzung und Zeitstempel hat, kann theoretisch auf "Hit-Ebene" etwas exportieren, das an den Status von Rohdaten heranreicht. Aber nur in dem Bereich, in dem diese Dimensionen auch in den Messdaten zu finden sind. Es gibt ältere Properties, die Daten vor dieser Zeit haben und die eigenen Dimensionen sind i. d. R. nicht mehr nutzbar, wenn die selbst definierte Datenaufbewahrungsfrist ggf. schon verstrichen ist.
• Custom Channel Groupings, eigene Definitionen und viele andere Metriken und Dimensionen gab es nicht "schon immer". Daher ist eine Extraktion von Daten über diese Dimensionen und Werte nur dann möglich, wenn der Zeitraum dies zulässt. Es muss daher ggf. in mehreren Schritten und unterschiedlicher Detail-Tiefe exportiert und dann sinnvoll zusammengeführt werden.
• Das Default Channel Grouping, Quelle/Medium etc. sind oft nur in weniger zurückliegenden Zeiträumen als Detailebene in den Export Daten zu nutzen, weil eben davor nur noch aggregierte Daten existieren - je nach Einstellung zur Aufbewahrung. Auch User und Sitzungen auf Dimensionsebene von Seiten sind somit für frühere Zeiträume ggf. nicht mehr zu finden.
• Hilfreich: Quelle / Medium ist durchgehend verfügbar; erhöhen aber die Anzahl der Datensätze schnell, selbst wenn nur monatlich Daten abgerufen werden sollen. Das sorgt für eine größere Anzahl einzelner Abfragen, da sowohl Reports in GA als auch die API ihre Limits haben.
• Um an ungesamplete Daten zu kommen, sind daher je nach Granularität und Anzahl der Zeilen mehrere Durchgänge über kleinere Zeiträume erforderlich. Und selbst diese Methode hat bei umfangreichen Daten in GA ihre Grenzen.
• Events, Ziele, E-Commerce... vieles gab es am Anfang noch nicht und kann daher evtl. nicht über die ganze Zeit ermittelt und abgerufen werden
• Die Ausweisung von Nutzern in bestimmten Reports war nicht immer möglich. Das macht es erforderlich, auf User zu verzichten und stattdessen z. B. "nur" die neuen Nutzer als Ersatz-Metrik neben Sitzungen, Absprungrate etc. abzurufen.

Was weg ist, ist weg

Spätestens jetzt "rächt" es sich, dass man in aktiven Properties irgendwann 2018 normalerweise eine begrenzte Datenaufbewahrung aktiviert hat, denn auf diese Weise verschwindet je nach Einstellung nach einigen Monaten die Fähigkeit, in GA tiefer in Reports einzusteigen. "Drill Down" auf bestimmte Dimensionen ist dadurch nicht mehr möglich. Hier ein Beispiel für eine alte Universal Property mit Daten seit 2005 für den April 2006 nach Kanälen in der Akquisitions-Übersicht:

Wie man sieht, weist der Report selbst keine Zahlen mehr auf, obgleich diese lt. Grafik "da zu sein" scheinen. Im Ergebnis findet man hier aber weder in benutzerdefinierten Reports noch per API Zahlen, wenn die Dimension des Kanals verwendet werden soll. Zudem wurden ggf. mehrfach die Properties gewechselt oder gar Altdaten gelöscht, weil man sich erst zu spät mit IP Anonymisierung oder anderen Dingen befasst hat und im Zuge der DSGVO daher einen Neustart im Tracking umsetzen musste.

Anhand der eigenen Fragestellungen und Analyseverfahren muss daher bestimmt werden, was genau an Dimensionen und Kennzahlen in welcher Zusammenstellung für welchen Zeitraum benötigt wird - und vorhanden ist. Da die Möglichkeit von lebendigen Reports, die beliebig auf Basis von Rohdaten neu segmentiert und zusammengestellt werden können, nicht mehr existiert, sobald UA als Tool zum Zugriff auf die Daten wegfällt, kann das je nach eigenen Anforderungen eine ganze Menge Arbeit und Tabellen bedeuten. Hunderte von Tabellen und Exportvorgängen, um genau zu sein.

Fragen zur Export-Vorbereitung

Damit nicht erst dann ein böses Erwachen zu befürchten ist, wenn keine Korrektur bzw. Ergänzung der Daten mehr möglich ist, empfiehlt sich zumindest eine Vorbereitung und ggf. frühzeitige Erprobung des Ernstfalls anhand des erforderlichen Minimalumfangs: Dem Aufbau einer Reporting-Variante, die auf exportierten Daten statt Universal Analytics basiert. In den tatsächlich verwendeten Tools zum Reporting oder Analyse von Daten jenseits der Universal Benutzeroberfläche.

Selbst wenn es später einen einfacheren, besseren oder vollständigeren Weg geben wird, bevor uns GA3 genommen wird, ist man auf diese Weise vorbereitet und kann einschätzen, wo ggf. noch Lücken bestehen oder mehr Detailgrad benötigt wird. Dazu kann man sich anhand einer Frageliste vorbereiten und die benötigten Reportvarianten zusammenstellen:

• Wo sollen Daten am Ende landen und was will man damit machen? Die eigene Nutzung (in Form aller aktiver Nutzer) muss dazu analysiert werden!
• Reichen Pageviews oder welche zentralen Events (selten alle) und Ziele müssen ausgewertet werden ?
• Was ist mit Site Search Daten?
• Wie werden Daten zu Zielen + ggf. E-Commerce benötigt, um mit den neuen Daten (aus GA4) gemeinsam ein übergreifendes Reporting zu ermöglichen?
• Sind Timings oder gar App-Tracking Daten aus UA wichtig?
• Daten zu AdSense, Google Ads, AdExchange, Publisher-Daten und andere verbundene Dienste: was wird benötigt - oder kann stattdessen ggf. alternativ aus dem jeweils anderen System direkt entnommen werden?

Daraus ergibt sich eine Zusammenstellung von verschiedenen Reports, die auf Daten in einer bestimmten Dimensionsaufteilung und zeitlicher Auflösung erfordern.

• Welche Kennzahlen auf welcher zeitlichen Detailebene (Tagesbasis, Wochen, Monate?) werden benötigt?
  • für den ganzen Zeitraum
  • für die letzten x Monate
• Dimensionen und Segmente:
  • Zeit allein als Detailgrad genügt nicht. Was ist mit Sprachen, Browsern, Betriebssystem, Mobile vs. Desktop?
  • Und Content-Groupings, wenn diese nicht anhand der URLs nachträglich wiederhergestellt werden können?
  • Oder komplexeren Segmenten, die genutzt werden? Auch danach sind Daten differenzierbar abzurufen, wenn erforderlich

Steigende Detailtiefe mit der Zeit

Es ist sinnvoll, für ältere Zeiträume nicht zu viel Zeit zu investieren, um Daten zu extrahieren, die ohnehin kaum mit aktuelleren Daten vergleichbar sind. Wie viele Relaunches haben stattgefunden in den letzten 15 Jahren; inkl. Umstellung der Struktur der Website, anderen URLs, Systemwechsel etc.? Vergleichbarkeit ist deshalb jenseits von "Big Picture-Metriken" wie Usern, Sitzungen, Seitenaufrufen etc. selten noch gegeben.

Dimensionen jenseits der Zeit selbst sind zudem oft erst später interessant. So ist z. B. eine Differenzierung nach Gerätetyp irrelevant in den Jahren, bevor der Anteil mobiler Besucher nennenswerte Größe erreicht hat. Hat man mit diesen Vorbereitungen eine Liste aus unterschiedlichen Tabellen generiert, die benötigt werden - z. T. in verschiedenen Varianten mit unterschiedlichen Kombinationen von Metriken und Dimensionen, geht es an den Export. Dabei sind die Daten idealerweise nur einmalig abzurufen und dann ggf. noch zu konvertieren / Bereinigen, um sie anschließend dort zu versenken, wo sie gebraucht werden. Dabei beantwortet sich schnell die Frage, ob sich Automatisierung oder programmierte Nutzung der API lohnt oder Report-Exportdaten (ggf. über benutzerdefinierte Reports aus UA direkt) ausreichend sind.

Die nächsten Abschnitte zeigen exemplarisch, wie man vorgehen kann, um Daten in lokal gespeicherten Dateien über den Query Explorer oder via Google Sheets zu speichern

Daten über Google Sheets abrufen

Wenn das oben angegebene Add-on für Google Sheets installiert ist, kann es dazu verwendet werden, beliebige Daten aus GA abzurufen, die über die API bereitgestellt werden. Zur Nutzung in einem neuen Tabellen-Dokument über Erweiterungen - Add-ons - Add-ons aufrufen via Suche nach "Google Analytics" die entsprechende Erweiterung installieren.

Danach kann im Erweiterungen-Menü mittels des neuen Untermenüs "Google Analytics" ein neuer Report angelegt werden. Der Name des Reports wird bei der späteren Ausführung des Reports als Tabellenblatt-Bezeichnung verwendet. Für die ausgewählte Datenansicht kann aus Listen ausgewählt werden, welche Metriken nach welchen Dimensionen abgerufen werden sollen.

Nach Abschluss der Definition und Klick auf "Create Report" wird zunächst ein neues Tabellenblatt mit der Konfiguration angelegt (das wiederholt sich, wenn man mehrere Reports auf gleichem Weg anlegt). Hier sind nun die Einstellungen wie der Zeitraum (im Format yyyy-mm-dd) anzupassen, der per Standard auf die letzten 30 Tage eingestellt ist. Dazu - und zur Definition der darunter zu findenden Felder - wird das Format der API verwendet. Durch Anpassung der Zeilen zu Metriken und Dimensionen kann der Report also hier jederzeit verfeinert werden, solange man im Rahmen der definierten Limits bleibt. Es können z. B. nicht mehr als zehn Metriken auf einmal abgerufen werden. Hilfreich ist dabei der Explorer für Universal Analytics Dimensionen und Metriken, in dem gezielt Einträge gesucht und dann anhand des "API Namens" hinzugefügt werden können. Vor der Durchführung ggf. noch das Limit anpassen oder entfernen, um die Konfiguration abzuschließen.

Die Ausführung des / der Reports wird wieder über das Erweiterungs-Menü via "Run Reports" gestartet. Das Ergebnis erscheint auf einem eigenen Arbeitsblatt und liefert neben den einzelnen Zeilen des Reports und einem Summenblock zudem eine Übersicht über den Umfang. Hier zeigt sich ob Sampling die Daten beeinträchtigt hat. Mit diesen Angaben ist ein mehrfaches Nachjustieren der Reports möglich. Dabei ist es sinnvoll, sich eingangs auf diejenigen Metriken zu beschränken, welche auch in den Standardreports von UA zu sehen sind und dann schrittweise ggf. weitere Metriken oder Dimensionen hinzuzufügen und stets zu vergleichen, ob der Umfang des Reports nach jeder Ergänzung noch den Erwartungen entspricht, oder ob ein hinzugefügter Detailgrad dazu führt, dass die Daten nur noch einen Teil der ausgewählten Zeit umfassen.

Mit einem solchen Ergebnis kann dann die Weiterverarbeitung geschehen, oder direkt auf diesen Google Tabellen z. B. das Reporting im Google Data Studio mit zusammengeführten Alt- und Livedaten aus GA4 aufgebaut werden.

Export via Google Analytics Query Explorer

Den gleichen Umfang an Daten erhält man alternativ über den UA Query Explorer. Während für den großen Überblick aus dem obigen Beispiel nur ein einziger Report erforderlich ist, um ein paar Basismetriken ohne weitere Segmentierung nach Quelle und Medium oder sonstigen Dimensionen für einzelne Monate abzurufen, sieht das anders aus, wenn z. B. Auswertungen zu Seiten oder Events stattfinden sollen. Hier wird man sich i. d. R. auf einzelne Monate oder im Extremfall Tage beschränken müssen. Da ist es sinnvoll, die Anfragen zumindest hier zu erproben - selbst wenn ein Abruf der Daten ggf. durch Automatisierung (siehe unten) und nicht manuell erfolgen sollte.

Ein Beispiel: Der folgende Link führt direkt zum Query Explorer und definiert den Abruf von ausgewählten Metriken zu einzelnen Seiten für einen einzelnen Monat nach Tagen für den April 2018:

• Überblick Seiten April 2018

Damit die Bestückung der Metriken und Dimensionen funktioniert, muss der Explorer ggf. vorher einmal manuell aufgerufen, autorisiert und eine Datenansicht ausgewählt werden, wenn es beim ersten Klick auf den Link nicht funktioniert. Danach sollte aber die Definition übernommen werden und die Auswahl von Metriken und Dimensionen so aussehen:

Weitere Beispiele, die als Startpunkt für die eigenen Reports verwendet werden können:

• Seiten nach Monaten (Gesamt, monatlich für einzelnen Monat): Hier ist zusätzlich der Monat mit eingeblendet, obschon nur Daten für einen einzelnen Monat abgerufen werden. Der Zweck: Wenn Daten nicht auf Tages-, sondern Monatsbasis in mehreren Durchgängen abgerufen werden können und dieser Detailgrad ausreicht, muss eine zusammengeführte Tabelle eine Referenz auf den Monat beinhalten. Bitte zudem bedenken: Wie oben beschrieben ist alles, was mit Sitzungen und Usern zu tun hat, hier potentiell problematisch, wenn relativ alte Daten abgerufen werden sollen. Daher ein wenig mit den Einstellungen und der Auswahl experimentieren, bis das Ergebnis die Anforderungen abdeckt
•  Event-Report (monatlich für einzelnen Monat): Ausgewählte Metriken zu Events nach Kategorie und Aktion (ohne Label)

Nach der Ausführung wird jeweils direkt im Browser das Ergebnis eingeblendet und dann von dort als TSV Datei exportiert werden. Auch hier beachten: Es wird angegeben, ob Sampling im Spiel ist. Ist das der Fall, müssen kleinere Zeiträume her oder weniger / andere Dimensionen (wenn diese angepasst wurden). Das artet allerdings schnell aus, wenn man 365 Exportdateien für ein einziges Jahr und nur diese eine Ansicht erzeugen muss. Daher ist Automatisierung ein logischer nächster Schritt, wenn auf diesem Weg die passenden Anfragen gefunden und erprobt wurden.

Optionen zur Automatisierung

Ab einem gewissen Grad sind die oben gezeigten Mittel oder gar der manuelle Export aus Analytics nicht mehr angemessen. Wo für eine Property (oder genauer: eine Datenansicht) evtl. Hundert oder mehr Exportvorgänge noch zumutbar erscheinen mögen, ist das bei einem Verbund von Websites schlichtweg zu teuer in der Durchführung - und zu fehleranfällig. Daher sollte in vielen Fällen auf Automatisierung gesetzt werden, um die gewünschten Reports für alle Properties in gleichbleibender Qualität und Zuverlässigkeit zu erzeugen. Zudem wird über entsprechende Mittel das Verhindern von Sampling durch Abrufen kleinerer Einheiten und das Zusammenführen und Speichern in großen Tabellen deutlich einfacher.

Dazu dient die Google Analytics Reporting API, welche nicht nur Client Bibliotheken für Java, Python, PHP oder JavaScript bietet, sondern über passende Anbindungen in R genutzt werden oder Daten direkt oder via Supermetrics in Google Data Studio anliefern kann. Der Aufwand für die Automatisierung der erforderlichen Reports hält sich für einen Entwickler mit diesen Mitteln in Grenzen und amortisiert sich je nach Komplexität der eigenen Export-Vorhaben schnell.

Ein einfaches Beispiel, wie man R und die Bibliothek googleAnalyticsR nutzen kann, um Daten möglichst ohne Sampling und manuelle Zusammenführung auch über größere Zeiträume abzurufen und lokal zu speichern, habe ich auf Github abgelegt: Beispielscript UA Datenexport mit R.

Damit ist auch für Einsteiger der Datenexport aus Universal Analytics deutlich einfacher zu erledigen, als den o. a. manuellen Mitteln. Selbst ohne Vorkenntnisse kommt man mit den Kommentaren und bei Bedarf dem folgenden Video sicher klar, das die Verwendung schrittweise demonstriert.

Wie? Keine Patentlösung? 🙁

Nein. Ich halte es auch für falsch - ja, sogar gefährlich -, wenn ein vorgefertiges Tool versucht, unter all den oben aufgezählten sehr individuellen Rahmenbedingungen zu versuchen, allen denkbaren Anforderungen gerecht zu werden. Zu schnell hat man sich fälschlicherweise darauf verlassen, dass alles da sein wird, was man ggf. später einmal braucht.

Ich halte es daher für unabdingbar, sich mit den eigenen Anforderungen auseinanderzusetzen und selbst dafür zu sorgen, dass man alles hat, was man wirklich braucht. Wenn man denn etwas braucht (siehe Anfang). Aus reiner Sammler-Leidenschaft weiterhin möglichst viel Altdaten zu konservieren, wird keine Business-Fragen aufwerfen oder gar beantworten. Deshalb ist die Planung einer Datensicherung ein guter Mosaikstein für einen Umstieg von Universal auf etwas anderes, der am Ende idealerweise zu besseren Daten und deren Nutzung führt, statt nur maximale Kontinuität dessen zu gewährleisten, was evtl. vorher vermutlich schon reichlich Optimierungsbedarf hatte.

Tipp zum Schluss: Was man sonst noch sichern sollte

Will man die Daten in einigen Jahren noch verstehen und richtig interpretieren können, sind weitere "Metadaten" hilfreich. Was zum Beispiel nutzt das Wissen über die Erreichung von Zielen, wenn niemand mehr weiß, woraus dieses Ziel bestand? Auch bei der nachträglichen Auswertung von Zielen auf Basis der gesicherten Ereignisse und Seitenaufrufe ist das Wissen über die Zieldefinition erforderlich. Da man in GA nicht mehr nachsehen kann, braucht man daher eine gesicherte Fassung.

Bei wenigen Zielen kann man dies einfach in Prosa und einem Dokument formlos konservieren. Viele Properties machen diese Strafarbeit allerdings schnell zeitraubend. Zudem sind nicht nur Ziele interessant. Benutzerdefinierte Dimensionen sind ohne Kontext über den Scope kaum nutzbar. Und den Namen anhand eines Index auch übermorgen noch nachvollziehen zu können, kann wesentlich sein. Um Informationen wie Einstellungen, Ziele etc. für mehrere Properties in einem Google Sheet zu konservieren, kann man daher auf ein "inoffizielles Google Tool" zurückgreifen. Dieses unterstützt darüber hinaus GA4 und kann daher bei einem Umstieg sehr hilfreich sein. Das Tool besteht aus einem Google Spreadsheet nebst Scripts zur Nutzung verschiedener APIs. Eine Beschreibung, Link zu einer Google Gruppe und dem Dokument findet sich bei GitHub.