Google Gadgets tracken

Gadgets für Googles personalisierte Seite iGoogle werden sehr rege genutzt: Schon aus den Gründen, weil sich die Minianwendungen im Google Desktop und auch in externen Webseiten einbinden lassen. Folgende Lösung zählt Aufrufe eines selbst entwickelten iGadget.

Counter auch für Gadgets?
Es ist generell nicht verkehrt zu wissen, wie oft die programmierte und veröffentlichte Applikation seitens Nutzern aufgerufen wurde – egal für welche Zwecke diese Statistiken verwendet werden, ob für Marketing oder eigenes Gewissen.

Cache ist unser Feind
Doch in diesem Fall gibt es einen kleinen Hacken an der Sache: Google, wie auch die anderen Anbieter der personalisierten Startseiten wie zum Beispiel Netvibes oder Pageflakes, cached die Gadgets extrem, um so Maximum an Performance zu gewährleisten. In diesem Fall liefern – auf dem eigenen Webserver installierte – Auswertungstools, die das AccessLog als Quelle nutzen, nicht ganz zuverlässige Zahlen, da das Gadget bei jeder Einblendung nicht ebenfalls jedes Mal vom eigenen Server geholt wird.

Googles interner Dienst
Bei dieser Problematik helfen uns gerne externe Tracking-Tools wie zum Beispiel Google Analytics. Der Vorteil liegt auf der Hand: Analytics wird als externe Datei per JavaScript ins Gadget (oder auch beliebige andere Webseite) eingebunden – diese wird immer nachgeladen, auch wenn das eigentliche Gadget aus dem Cache kommt.

Gadget-Schnittstelle
So gut, wie Google eben ist, besitzt die Google Gadgets-API auch eine interne Implementierung für eine saubere und zuverlässige Unterstützung von Analytics. Um das Gadget nun bei Ananytics zu führen, reichen zwei kurze Befehle:

<Require feature="analytics" />

<script>_IG_Analytics("UA-Analytics-ID", "/pfad");</script>

Was ist was?
Require-Eigenschaft wird oben im Head des Gadgets unter ModulePrefs definiert und veranlasst den Parser die notwendige JS-Bibliothek nachzuladen. Die Analytics-ID ist die ID eines bestehenden Projekts aus Analytics-Oberfläche unter dem das Gadget laufen soll. Der Seitenzugriffspfad ist praktisch das virtuelle Kennzeichen, unter welchem später auch die Statistiken aufgeführt werden (siehe auch Downloads zählen mit Analytics).

Gadget als separates Analytics-Profil
Jetzt der nächste Stolperstein: Möchte man das Gadget nicht zu einem bestehenden Projekt bei Analytics hinzufügen, sondern unter einem eigenständigen Profil laufen lassen (für mehr Übersichtlichkeit oder für einen Kunden), braucht man ebenfalls eine eigenständige Analytics-ID, um diese im Gadget auch zu hinterlassen. So weit die Theorie.

Suchen und nicht finden
Doch die Freischaltung der erzeugten ID ist unmöglich. Warum? Das liegt an der Tatsache, dass Analytics bei jeder Erstellung eines neuen Websiteprofils im Hintergrund die Zielseite ansurft, diese parst und nach dem vorgegebenen Code-Block durchsucht. Es wird nicht allein nach der Analytics-ID gefahndet, sondern wirklich nach dem Block – die Formatierung der Blockzeilen spielt dabei übrigens keine Rolle. Wird der Code-Block beim Parsen des Gadgets nicht gefunden (und der wird tatsächlich in unserem Sonderfall nicht gefunden, weil wir ja mit der internen API-Funktion _IG_Analytics() arbeiten, die für uns im Hintergrund einen Aufruf des Code-Blocks startet) wird das eben angelegte Profil nicht freigegeben.

Lösung für den Notfall
Als Ausweg bleibt nur eins: Auf die interne Implementierung von Analytics im Gadget verzichten und den von Analytics vorgegebenen Code-Block einbauen. Aber natürlich nur dann, wenn das Gadget bei Google Analytics wirklich als separates Profil erscheinen und ausgewertet werden soll. Im anderen Fall tauchen die Aufrufzahlen beim hinterlegten Websiteprofil auf und können notfalls auch per Filter differenziert werden.

Aus Erfahrung gut
Diese und viele anderen Erfahrungen sammelte ich bei der Umsetzung des YiGG Gadgtes für iGoogle.