Seit überall über Mobil geredet wird, kommt immer wieder die Frage auf: Wie genau tracke ich denn meine Apps? Die Antwort darauf ist mehrere Blogpostings wert.
Was ist eigentlich gemeint?
Zwei Punkte in der Frage sind erklärungsbedürftig: „Wie tracke ich“ und „Apps“.
Fangen wir doch mal mit dem zweiten Punkt an, „Apps“. Was genau eine App sein soll, ist erstmal gar nicht so eindeutig klar.
Der Unterschied zwischen „mobile web“ (wie die Amerikaner es nennen) und „App“ ist relativ einfach definiert: „mobile web“ ist, wenn der Benutzer es sich mit einem Browser ansieht, „App“ ist, wenn er’s installiert.
Innerhalb der Kategorie „App“ gibt es aber eine ganze Reihe verschiedener Modelle, die tatsächlich unterschiedlich getrackt werden.
Mir fallen grundsätzlich 3 Modelle ein (eine absolut willkürliche Einteilung, die sich am besten aus der Sicht Webanalyse rechtfertigen läßt):
- Native Apps – solche die spezifisch für eine Plattform geschrieben sind
- HTML5 Apps – solche die Inhalte aus dem Internet nachladen und auf HTML, CSS, JavaScript und anderen Webtechnologien basieren
- Other Apps – solche die mit plattformübergreifenden Toolkits geschrieben wurden aber nicht auf HTML basieren
Der erste Punkt, wie tracke ich sowas, hat eine allgemeine Antwort und eine die vom Modell abhängt.
Generell sind Apps, was die Analyse angeht, von Websites gar nicht so weit entfernt. Die Benutzer rufen sie auf, navigieren zwischen verschiedenen Bildschirmen, tippen Werte in Formulare und beenden die App wieder. Viele der Konzepte aus der Webanalyse lassen sich 1:1 übertragen.
Hinzu kommen interessante Möglichkeiten, Werte über längere Zeiträume zu tracken, da Apps nicht wie Browser simple Cookies speichern können, sondern prinzipielle alles, was der Entwickler will. Damit kann man z.B. analysieren, wie lange eine App schon installiert ist oder wann sie zum ersten Mal oder zuletzt benutzt wurde.
Wie also tracke ich Apps?
Die technische Antwort auf die Frage wie das Tracking funktioniert, hängt wenig überraschend vom Modell ab.
Native Apps
Für Native Apps, die in Obective C für iOS, in Java für Android oder Blackberry, in .NET für Windows Phone, XBox oder in C für Symbian programmiert sind, kann man sich aus SiteCatalyst die entsprechende „AppMeasurement Library“ runterladen.
Die Library wird im Code gebunden und stellt dann Funktionen oder Methoden zur Verfügung, mit deren Hilfe man direkt tracken kann. Das Tracking wird also schlicht in die App rein programmiert.
Die AppMeasurement Libraries für iOS und Android enthalten ein paar über das grundlegende Tracken hinausgehende Ansätze, z.B. die oben erwähnten Analysen über Installations- und Nutzungszeitpunkte.
Man kann die Libraries so konfigurieren, daß sie Trackingcalls zwischenspeichern, falls das Gerät gerade keine Netzanbindung hat. Damit kann man die Benutzung der App auch offline tracken.
Man findet die AppMeasurement Libraries in SiteCatalyst unter Admin > Admin Console > Code Manager. Aus dem Dropdown wählt man sich dann die entsprechende Library aus.
Update: Die Libraries bekommt man jetzt über die Developer Connection.
HTML-basierte Apps
Üblicherweise bestehen solche Apps aus einem kleinen Starter, der dann innerhalb einer Browser-ähnlichen Umgebung HTML-Seiten anzeigt. Man könnte auch sagen: Die Dinger funktionieren genau wie Websites, bloß daß man sich den Browser nicht aussuchen kann.
Dazu kommt, daß Teile der (oder sogar alle) Inhalte nicht wie üblich per HTTP aus dem Internet geladen werden sondern im Paket mit dem Starter geliefert werden, also über den App Store / Play Store oder wie auch immer das gerade heißt.
Eine HTML-basierte App kann daher genau wie eine Website getrackt werden: Man integriert JavaScript Code und die s_code.js Datei für SiteCatalyst einfach in alle Teile der App.
Eine Besonderheit bei Apps die bei „herkömmlichen Webseiten“ weniger stark vorkommt ist die starke Verzahnung mit JavaScript und dynamischen Inhalten. Viele HTML-basierte Apps haben nur eine einzige HTML-Datei, den Rest erledigen sie über Ausblenden und Anzeigen sowie Nachladen oder Ersetzen von Inhalten der Seite.
Auch diese Art von Struktur läßt sich mit Webanalysetools tracken. Die Idee ist zu definieren, welche dieser Änderungen tatsächlich „als eine neue Seite“ gewertet werden sollen und welche eher analog zum Klicktracking.
Wenn man das einmal entschieden hat, kann man dem Entwicklerteam sagen, an welchen Stellen (in welchen Eventhandlern) es s.t() verwenden muß und wo s.tl(). Viel mehr Unterschiede gibt es nicht.
Die bestehenden Entwicklungsumgebungen unterstützen noch keine automatische Einbindung von Trackingcode, aber ich denke das wird kommen. Zumindest für PhoneGap (Disclaimer: Gehört zu Adobe) könnte ich mir gut vorstellen, daß eine Integration mit SiteCatalyst auf dem Fahrplan steht. (Noch ein Disclaimer: Ich kenne niemanden bei PhoneGap und weiß das nicht. Ich vermute es nur.)
Andere Apps
Die Gruppe der Apps die mit plattformübergreifenden Toolkits geschrieben sind aber nicht auf HTML basieren ist vom Standpunkt einer Webtrackingimplementierung her am kompliziertesten.
(Ausnahmen: Apps die in Silverlight, Flash/Flex oder AIR geschrieben sind. Für die gibt es nämlich auch AppMeasurement Libraries.)
Man kann auch solche Apps tracken, und zwar auf verschiedene Arten. Die Data Insertion API wäre eine Möglichkeit, also das Versenden von GET oder POST Requests per HTTP. Das funktioniert analog zum server-side Tracking auf einem Webserver.
Eine andere Möglichkeit wäre, einen JavaScript Interpreter in die App einzubetten, der sich nur um’s Tracking kümmert. Das dürfte aber in den allermeisten Fällen totaler Overkill sein.
Gemeinsamkeiten
Allen Modellen gemeinsam ist, daß man sich vorher ein paar Dinge überlegen sollte:
Soll der Traffic in die gleiche Report Suite laufen wie der von der Website? Oder lieber getrennt? Was sind eigentlich die Ziele der App? Ohne die zu wissen kann man später nur schlecht optimieren. Wie lang sind die Entwicklungszyklen? Und ändert sich das Tracking von Version zu Version so stark, daß man besser eine neue Report Suite anlegt?
Soll offline getrackt werden oder nicht? Falls ja, dann muß der Traffic zwingend in einer anderen Report Suite landen als der Websitetraffic. Falls nein gehen eventuell interessante Daten verloren.
Aufgrund der Logistik (App Store / Play Store / …) ist es auch schwierig bis unmöglich, Kampagnen zu analysieren, die auf Appdownloads abzielen. Keiner der Märkte bietet zur Zeit die entsprechenden Tools oder Einsichten. Wer nicht personalisierte Kampagnencodes generieren kann und die Benutzer später an einem Login wiedererkennt, wird zur Zeit keine Kampagnen tracken können.
Dennoch ist Apptracking wichtig. Die Zugriffe von mobilen Endgeräten steigen nachwievor und bisher ist noch niemanden so 100% klar, was Benutzer mit einem vergleichsweise kleinen Bildschirm und langsamer Anbindung eigentlich genau auf Webseiten oder in Apps tun.
Hier liegt noch viel Potential vor uns, denke ich.
Pingback: Visitors & hybride Apps | Webanalyse auf Deutsch