der
http://www.google-analytics.com/ga.js
in das entsprechende Feld. Sie sehen dann den Code in einer viel besser lesbaren Form.
Früher habe ich immer empfohlen, den Code idealerweise möglichst weit unten auf der Seite einzubauen, damit zunächst der Content der Seite geladen wird, eher der Tracking-Code zur Ausführung kommt. Denn das Surferlebnis der User sollte Vorrang haben vor der Erhebung von Nutzerdaten.
Das asynchrone Tracking läuft jedoch etwas anders ab. Hier werden die Daten quasi zunächst gesammelt und dann später, wenn die Seite komplett geladen ist, gebündelt als „Paket“ an Google übermittelt. Vorstellbar ist dies wie ein Schulbus, der während seiner Route an vielen Stellen Schüler aufnimmt und am Zielort sämtliche Fahrgäste mit einem Schwung auslädt.
Dies hat einen großen Vorteil für die User der Website – keine unnötigen Ladezeiten wegen des Aufrufs eines Web-Analyse-Pixels.
Alternativ zu der bislang vorgeschlagenen Positionierung des Tracking-Codes können Sie bei Bedarf den Code auch in zwei Teile aufteilen. Der eine Teil des Codes sollte dann wie bereits beschrieben im Head-Bereich der Seite integriert sein. Diese Zeilen haben kaum bzw. keine Auswirkungen auf die Ladezeit. Der untere Teil des Codes kann dann weiter unten innerhalb des Body-Bereichs der Website eingebaut werden. Durch diese Aufteilung vermeiden Sie mögliche Verzögerungen bei der Ladezeit der Seite bedingt durch die Kommunikation zwischen dem Code und Google Analytics. Eine Aufteilung des Tracking-Codes in zwei Teile sieht folgendermaßen aus:
Listing 6.3 Aufteilung Tracking-Code
Seiteninhalte
Es gibt immer noch viele Websites, die den alten synchronen Tracking-Code integriert haben. Dies ist grundsätzlich kein großes Problem – jedoch wird dieser von Google nicht mehr bei der Entwicklung neuer Features unterstützt. Ich kann demnach nur empfehlen, auf den asynchronen Code zu wechseln. Hier ist es jedoch wichtig, dass Sie nicht beide unterschiedlichenCodes parallel eingebaut haben. Entweder den einen oder den anderen, nicht aber eine Mischung aus beiden.
Für den asynchronen Tracking-Code gibt es unterschiedliche Darstellungsformen. Die Variablen können entweder separat, zusammen oder als Funktion übergeben werden. Um dies etwas zu verdeutlichen, hier ein kleines Beispiel, wie zwei Zeilen aus dem Standard-Code dargestellt werden können.
Listing 6.4 Separater asynchroner Code:
_gaq.push(['_setAccount', 'UA-XXXXX-X']);
_gaq.push(['_trackPageview']);
Listing 6.5 Multipler asynchroner Code:
_gaq.push(
['_setAccount', 'UA-XXXXX-X'],
['_trackPageview']
);
Listing 6.6 Asynchroner Code als Funktion:
_gaq.push(function() {
var pageTracker = _gaq._createAsyncTracker('UA-XXXXX-X');
pageTracker._trackPageview();
});
6.2
Umbenennung der URLs
Google Analytics orientiert sich bei der Erhebung der einzelnen Seiten per Default an der in der Adresszeile des Browsers dargestellten URL. Diese Information wird über die folgende Codezeile aufgenommen:
Listing 6.7 Asynchroner Tracking-Code:
_gaq.push(['_trackPageview']);
Diese Zeile signalisiert Google Analytics „Nimm die URL, wie sie im Browser steht, als Seitennamen“. (In den Berichten wird dann per Default die URI anstelle der kompletten URL dargestellt, was sich allerdings über Filter verändern lässt und in Kapitel 7.5.3.2 beschrieben wird.)
Diese Darstellungsform funktioniert hervorragend, solange Sie über eindeutige, selbst erklärende URLs verfügen (siehe auch Kapitel 2.2.1 und Kapitel 4.1.1). Ist dies der Fall, sind Ihre URLs verhältnismäßig leicht analysier- und interpretierbar.
Was aber, wenn Ihre URLs kryptisch und – außer für Ihren Webmaster – unverständlich sind? Hierfür gibt es genügend Beispiele. Achten Sie mal aktiv auf URLs – Sie
Kostenlos Online Lesen 
