Ein kleiner Nachtrag zum Thema Apps: Im letzten Artikel war zu lesen, daß Apps sich gar nicht so sehr von Websites unterscheiden, was die Analyse angeht. Es gibt natürlich im Detail doch Unterschiede. Zum Beispiel kann man im Web nicht verläßlich messen, wann eine Seite verlassen wird, bei einer App geht das.
Und dann gibt es noch einen fundamentalen Unterschied: Apps sind ein relativ neues Transportmedium. Das bedeutet, daß die App selber analysiert werden sollte, also der Umstand, daß es sich um eine App handelt.
Ähnlich wie es für viele Branchen „best practice“ Lösungen gibt (also quasi Schablonen für die sinnvollsten oder erfolgversprechendsten Kennzahlen und Analysen), enthalten auch die AppMeasurement Libraries „best practice“ Code, der speziell auf die Analyse von Apps zugeschnitten ist.
Best Practice Plugin
Das best practice plugin erblickte als Zusatz für iOS Tracking das Licht der Welt und wurde zunächst beim Summit 2011 in Salt Lake City vorgestellt. Damals war es noch ein freier Zusatz, den man aus der Knowledge Base herunterladen konnte. Mittlerweile hat es das Plugin in die AppMeasurement Libraries für iOS und Android geschafft, ist also quasi Teil des Produkts.
Das Plugin trackt automatisch (wenn man es nicht zügelt) 7 events, 13 eVars und 3 props:
Name | Standardwert | Beschreibung |
appInstallEvent | event1 | Triggered on first run after installation (or re-installation).Feuert beim ersten Start nach der Installation (oder Neuinstallation) |
appUpgradeEvent | event2 | Triggered on first run after upgrade (anytime the version number changes).Feuert beim ersten Start nach Versionswechsel |
dailyEngagedUserEvent | event3 | Triggers an event when the application is used on a particular day.Feuert beim ersten Start am Tag |
monthlyEngagedUserEvent | event4 | Triggers an event when the application is used during a particular month.Feuert beim ersten Start in einem Kalendermonat |
appLaunchEvent | event5 | Triggered on any run that is not an install or an upgrade. This also triggers when the application is brought out of the background.Feuert wenn die App startet oder aufgeweckt wird |
appScreenViewEvent | event6 | Provides a replacement for page view.Kann als Alternative zum eingebauten PageView Event genutzt werden |
appCrashEvent | event7 | Triggered when the application does not exit gracefully. Event is sent on application start after crash (the application is considered to crash if quit is not called).Feuert beim Start, wenn die App beim letzten Mal nicht normal beendet wurde |
Name | Standardwert | Beschreibung |
appInstallDateEvar | eVar1 | Date of first launch after installation. MM/DD/YYYYDatum des ersten Starts nach Installation |
appIdEvar | eVar2 | Stores the Application name and version in the following format: [AppName] [BundleVersion] For example, myapp 1.1Name und Version der App |
engagedDaysLifetimeEvar | eVar3 | Stores the number of days the application is used.Anzahl der Tage, an denen die App genutzt wurde |
daysSinceFirstUseEvar | eVar4 | Number of days since first run.Anzahl der Tage seit erstem Start |
daysSinceLastUseEvar | eVar5 | Number of days since last use.Anzahl der Tage seit letztem Start |
appLaunchNumberEvar | eVar6 | Number of times the application was launched or brought out of the background.Anzahl der Starts oder Aufweckvorgänge |
hourOfDayEvar | eVar7 | Measures the hour the app was launched. 24 hour numerical format. Used for time parting to determine peak usage times.Day parting: zu welcher Stunde wurde die App gestartet |
dayOfWeekEvar | eVar8 | 3 character day when the application was used.Day parting: an welchem Wochentag wurde die App gestartet |
appEnvironmentEvar | eVar9 | Contains the current iOS version.Betriebsystemversion (z.B. iOS 5) |
daysSinceLastUpgradeEvar | eVar10 | Number of days since the application version number has changed.Anzahl Tage seit letztem Versionswechsel |
appLaunchNumberSinceLastUpgradeEvar | eVar11 | Number of launches since the application version number has changed.Anzahl Appstarts seit letztem Versionswechsel |
engagedDaysMonthEvar | eVar12 | Total count of days the application was used in the last month.Anzahl der Tage im letzten Monat, an denen die App genutzt wurde |
engagedDaysLastUpgradeEvar | eVar13 | Total count of days the application was used since last upgrade.Anzahl der Tage seit Versionswechsel, an denen die App genutzt wurde |
Name | Standardwert | Beschreibung |
appIdProp | prop1 | Stores the Application name and version in the following format: [AppName] [BundleVersion] For example, myapp 1.1Name und Version der App |
appLaunchNumberProp | prop2 | Number of times the application was launched or brought out of the background.Anzahl der Starts oder Aufweckvorgänge |
appLaunchNumberSinceLastUpgradeProp | prop3 | Number of launches since the application version number has changed.Anzahl Appstarts seit letztem Versionswechsel |
PageName | n/a | Contains „appName (appVersion) useType“ where useType is either Install, Upgrade, or Launch.Wird auf „AppName (AppVersion) StartTyp“ gesetzt, dabei ist „StartTyp“ entweder „Install“, „Upgrade“ oder „Launch“ |
Das sind erstmal eine ganze Menge Daten…
Wer nicht alle diese Daten benötigt oder sie eigentlich in andere Variablen schreiben möchte, kann das tun: alle in den Tabellen angegebenen Variablen sind Defaults, die man ändern oder auch weglassen kann..
Wozu braucht man all diese Daten?
Analysen
Einer der Gründe für die Entwicklung des Plugins und nachwievor eine der interessantesten Analysen ergibt sich, wenn man eVar4 (daysSinceFirstUse) und eVar5 (daysSinceLastUse) gruppiert:
eVar4 teilt man in 2 Gruppen: „vor kurzem zum ersten Mal benutzt“ oder „Neubenutzer“ und „schon seit längerem benutzt“ oder „Altnutzer“. eVar5 teilt man ebenfalls in 2 Gruppen: „vor kurzem benutzt“ oder „aktiver Benutzer“ und „vor längerer Zeit zum letzten mal benutzt“ oder „inaktiver Benutzer“.
Wo genau man die Grenzen zwischen „vor kurzem“ und „vor längerer Zeit“ zieht, hängt von der App selber ab, aber eventuell auch vom Inhalt. Die Adobe Summit App etwa ist nur ein paar Tage wirklich intensiv in Benutzung, danach nicht mehr.
Aus den genannten Klassifizierungen ergibt sich eine Aufteilung in 4 Quadranten. Ziel einer jeden App ist, möglichst viele Benutzer in den Quadranten „aktive Altnutzer“ zu motivieren.
Wer die Quadranten als Segmente anlegt, kann sich z.B. ansehen, ob die aktiven Altbenutzer die App anders nutzen als solche, die nicht zu Altnutzern werden. Dazu kann man z.B. eVar11 heranziehen (appLaunchNumberSinceLastUpgradeEvar) oder eVar6 (appLaunchNumberEvar). Interessant ist in diesem Zusammenhang auch eVar3 (engagedDaysLifetimeEvar).
App-spezifisch
Wie oben erwähnt ist das Plugin Teil der AppMeasurement Libraries (zur Zeit für iOS und Android). Das ist auch sinnvoll, weil man neben dem eigentlichen Inhalt der App auch die Interaktion mit der App als solcher erforschen sollte. Apps sind wie gesagt noch recht neu.
Ich würde allerdings argumentieren, daß eine ähnliche Analyse auch für Websites sinnvoll sein könnte. Ich kenne keinen deutschen Webanalysten, der einen Quadranten wie oben analysiert, dabei wäre das in einigen Branchen durchaus eine gute Idee, allen voran bei Tageszeitungen!
Der große Vorteil beim Apptracking ist natürlich, daß man für die Identifizierung eines Benutzers nicht auf Cookies angewiesen ist. Die App speichert stattdessen eine Benutzernummer, welche wesentlich stabiler ist.
(Man wird als neuer Benutzer gezählt, wenn man eine App de- und dann wieder neu installiert. Die früher auf iOS Geräten nutzbare UUID des Telefons wird von den AppMeasurement Libraries seit einiger Zeit nicht mehr benutzt.)
So oder so sind Kennzahlen wie Unique Visitors oder Visits beim Apptracking präziser.
Auch auf lange Sicht hilft die stabilere Benutzeridentifizierung. Auswertungen wie die 4 Quadranten oben sind nur dann wirklich aussagekräftig, wenn die Benutzer auf lange Zeit wiedererkannt werden können. Mit Apps geht das.
Man könnte fast sagen: Apptracking ist der ideale Bereich in dem Analysten alle möglichen Dinge ausprobieren können, weil die Daten sauberer sind als im Web. Wer die Möglichkeit hat, Apps zu tracken, sollte dort investieren und all die Dinge testen, die er schon immer testen wollte.
Wer weiß: Manches davon läßt sich hinterher vielleicht auch im Web umsetzen.