Google Analytics - Implementieren Interpretieren Profitieren

Seitenaufrufe mehr, was die Darstellbarkeit und Vergleichbarkeit des Erfolgs von Internetseiten erschwert.
Datenspeicherung und Datenhandling obliegen dem Site-Betreiber  
Log Files werden automatisiert vom Webserver, auf dem die Website gespeichert ist, mitgeschrieben. Die anfallenden Daten können bei großem Traffic-Volumen beträchtliche Speicherkapazitäten in Anspruch nehmen. Schließlich generiert jeder Seitenaufruf (egal, ob von realen Usern oder von Suchmaschinen-Bots) zu speichernde Daten. Diese Speicherkapazitäten müssen vom Webserver-Betreiber vorgehalten und ggf. ausgebaut werden. D. h.: Je erfolgreicher der Internetauftritt wird, desto mehr Kapazitäten müssen bereitgehalten werden, um die entstehenden Log Files speichern zu können. Neben dem Speichern müssen die Daten auch noch aufbereitet werden. Wie am Beispiel der Log Files (siehe Listing 3.1) dargestellt, sind die Daten in der Rohversion recht unleserlich. Um sie in Grafiken – Balkendiagrammen, Kuchencharts – oder anschaulichen Tabellen darstellbar zu machen, müssen die Daten aufbereitet bzw. neu angeordnet werden. Diese Arbeit übernimmt in der Regel eine Software, doch gilt es die Daten einzupflegen, was einen zusätzlichen Aufwand für den Betreiber von Internetseiten bzw. Webservern bedeutet.
Updates müssen selbst durchgeführt werden  
Weil die protokollierten Log Files bei dem Webserver-Betreiber gespeichert und unter Umständen weiterverarbeitet werden, muss man eventuelle Updates selbst durchführen. Dies beinhaltet sowohl die datenverarbeitende Software als auch die Updates des Webservers selbst. Dem Webserver-Betreiber obliegt die Verantwortung vernünftig handhabbarer und analysierbarer Daten, was regelmäßige Updates sicherstellen müssen.
    All diese Nachteile sind eklatant und können die Vorteile nicht aufwiegen. Der Traffic soll möglichst realistisch dargestellt werden, was unter den gegebenen Umständen nicht möglich ist, da es meist zu einer zu niedrigen Zählung kommt. Diese Probleme können unter Umständen mit einigen Tricks umgangen werden. Dennoch bleiben viele Nachteile, die dazu geführt haben, dass sich das Page Tagging bis heute weitestgehend im Web-Analytics-Umfeld durchgesetzt hat.
3.2.2 Page Tagging
    Die Page-Tagging-Lösung hat als Grundlage den Einbau eines (meist) JavaScript-Codes auf jeder einzelnen Seite des zu messenden Webauftritts. Bei Google Analytics sieht dieser Code beispielsweise folgendermaßen aus:
    Listing 3.2  Google-Analytics-Tracking-Code
    
    Wenn dieser Code im Quelltext der Seiten eingebaut ist, wird er jedes Mal aufgerufen, sobald die Seite geladen wird. Besucht also ein User diese Seite, wird der JavaScript-Befehl ausgeführt. Dies führt zu einer Kommunikation zwischen dem eingebauten Code und dem Anbieter dieses Codes. In der Regel ist der Anbieter ein sogenannter Application Service Provider (ASP), d. h., der Website-Betreiber implementiert den Code auf seinen Seiten – gespeichert werden die erhobenen Daten allerdings extern beim Tool-Anbieter. Es muss also eine Verbindung zwischen Code und Anbieter hergestellt werden.

    Bild 3.1   ASP-Modell
    Wie funktioniert dies nun bei Google Analytics?
    Wird der Google-Analytics-Tracking-Code (GATC) ausgeführt, weil ein User eine Webseite besucht, auf der der GATC korrekt eingebunden ist, werden Cookies auf dem Computer des Besuchers gespeichert (mehr dazu in Kapitel 3.3). Der GATC wird initialisiert und erhebt Daten über die Domain, auf der der Code eingebunden ist – Informationen, die sich in den gesetzten Cookies befinden – und protokolliert die Eigenschaften des verwendeten Browsers, die Referrer, Seiteninformationen etc. Sobald dieser Schritt ausgeführt ist, fragt der GATC ein 1 x 1 großes Pixelbild von den Google-Analytics-Servern ab, das sogenannte __utm.gif (namentlich ein Relikt aus alten Zeiten: utm steht für Urchin Tracking Monitor und beinhaltet den Namen des von Google übernommenen Unternehmens Urchin). An diese