De wijzigingen, die uit het gesprek met de interne Stakeholder volgden, beïnvloedden ook de metrieken die uitgelezen worden. De eerste lijst aan metrieken die opgesteld is was van invloed op de content zelf, de gestreamde video’s en afbeeldingen. Hoewel een groot aantal van deze metrieken ook werkt bij het uitlezen bij de metrieken van een App, gelden voor Apps andere metrieken.
De lijst van het aantal metrieken die bij Apps uitgelezen worden is een stuk langer. Gezien deze metrieken gelden voor het uitlezen van de App waarin ze zijn geprogrammeerd, zijn niet al deze metrieken toepasbaar. Enkele van deze metrieken zijn: App downloads, actieve gebruikers en sessie intervallen.
De screencasting functionaliteit en het uitlezen van metrieken zitten in een andere App dan waar de metrieken voor verzameld dienen te worden. De screencasting functionaliteit en data onttrekking behoren beide tot de App die ontwikkeld wordt en is als het ware een transparante laag over de App die gestreamd moet worden en waarvan de data verzameld worden.
Gezien de interne stakeholder tijdens het gesprek heeft laten weten welke metrieken hij van belang acht zullen dit ook de metrieken zijn waarop in dit onderdeel gefocust wordt.
Aantal gebruikers
Waar normaal gesproken het aantal downloads en het aantal actieve gebruikers de indicatie bieden hoeveel gebruikers er zijn zal dit nu niet mogelijk zijn.
Het aantal downloads wordt onder andere verkregen via Google Play. Echter wordt de uitlezende App maar een keer gedownload op het streamende device. Daarbij heeft deze App geen rechten tot inzage van de andere geïnstalleerde Apps.
Het aantal actieve gebruikers is soortgelijk aan het aantal downloads. In tegenstelling tot het aantal downloads, dat aangeeft hoe vaak een App gedownload is, geeft deze metriek het aantal gebruikers dat regelmatig de App gebruikt. Zo kan het aantal downloads op een miljoen gebruikers staan terwijl er maar duizend actieve gebruikers zijn.
Gezien de telefoon in een standaard komt te staan voor het scherm, waarop de content getoond wordt. Is het mogelijk om de telefoon een oorsprong te geven bij het opstarten van de App. Iedere keer dat de telefoon de oorsprong verlaat is een moment waarop iemand het apparaat vastpakt en doorspit. Dit moment kan vervolgens geteld worden als gebruiker.
Een nadeel aan deze manier van detecteren is dat er ook groepen gebruikers zijn die de telefoon aan elkaar doorgeven. Deze groepen worden vervolgens geregistreerd onder een en dezelfde gebruiker. Dit zou nog verbeterd kunnen worden mits de overdracht van het apparaat een gemeenschappelijk patroon heeft. In deze situatie zou de App kunnen controleren of de wijziging in gyroscopische data aan dit patroon voldoen en een nieuwe gebruiker detecteren.
Het tweede nadeel is de situatie waarbij een gebruiker het apparaat terugzet en zich bedenkt. In deze situatie zou de gebruiker de telefoon een tweede keer oppakken en twee keer geregistreerd worden.
Gezien alle varianten die door de gebruiker getest worden, dezelfde bovengenoemde nadelen bevatten en de overige factoren aan elkaar gelijk blijven, zouden deze nadelen nauwelijks invloed moeten hebben op het onderlinge verschil. Dit doordat het aantal gebruikers pas veelzeggend is als de waarden ver uit elkaar liggen. Bij kleine verschillen zoals de volgende situatie waarbij versie A vijf personen meer heeft dan versie B speelt dit effect een grote rol. Versie B zou in dit geval meer gebruikers kunnen hebben. Echter als dit verschil zo klein is heeft de waarde van het aantal gebruikers geen belangrijke rol in de beslissing welke versie beter de aandacht trekt.
Totale duur van ingebruikname || sessieduur
Hoewel de interne Stakeholder vraagt om de totale sessie duur is het ook raadzaam om een stapje verder te gaan. Behalve de totale sessie duur wil ik ook een gemiddelde sessieduur weergeven.
De sessie duur is de tijd die de gebruiker besteedt binnen de App totdat de App inactief wordt of je hem sluit. Deze waarde is voornamelijk handig om de CTA (Call To Action) mee te bepalen. Mocht de gemiddelde duur in de app vijf minuten zijn dan wil je rond deze vijf minuten ook de gewenste handeling (het bellen van een telefoonnummer, een download of zelfs de reclame) plaatsen.
Een goed voorbeeld bij dit soort metingen is van Spotify Free. Zelf gebruik ik Spotify zeer kort. Ik open de App en in veel gevallen klik ik direct op de startknop om verder te gaan in de afspeellijst. Veel langer ben ik niet in de App. Mijn sessieduur is erg kort en de CTA die hierbij hoort zal dus snel moeten volgen. En dat klopt. Vrijwel direct bij openen heb ik de eerste reclame te pakken. Deze reclame moet volledig bekeken worden wil ik de komende 30 minuten reclame vrij zijn.
Ook hier kan de originele manier van sessieduur niet gebruikt worden. Ik kan de App wel starten en de teller laten lopen maar dat zou zinloos zijn. De streamende App blijft “altijd” draaien en wordt maar eenmalig gestart. Dit zou dus leiden tot een zeer lange sessie. Om daadwerkelijke sessies te meten kan gebruik worden gemaakt van dezelfde code die voor het aantal gebruikers geschreven moet worden.
De sessie duur is namelijk zoals voorheen aangegeven per gebruiker. Deze kan hierdoor gestart worden zodra de gebruiker geregistreerd wordt. Oorspronkelijk was het einde van de sessie bij inactiviteit of het sluiten van de App. Twee dingen die niet meer van toepassing zijn nu de detectie niet in dezelfde app zit. Maar ook hier kan gekeken worden naar de oplossingen zoals bij het aantal gebruikers. Zodra er van gebruiker gewisseld wordt stopt natuurlijk de sessie voor de volgende sessie start. En zodra het apparaat weer teruggeplaatst wordt in het standaard (de oorsprong) stopt de sessie.
Een nadeel van deze methode is dat de sessie niet gekoppeld zit aan de App. Mocht de gebruiker de App verlaten dan blijft de sessie doorgaan. Om dit toe te passen zal iets de gebruiker moeten dwingen om de App niet te verlaten. Een van de mogelijkheden hiervoor is om in de demo App de back button, home button en recent apps button te overriden en een combinatie toe te voegen waarmee je alsnog de App uit kunt. Niet de mooiste oplossing maar wel functioneel.
Conversie
Een conversie is de gewenste actie die verwacht wordt van de gebruiker. Vaak wordt van tevoren een functie gekoppeld aan de functie in de App. Deze toegevoegde functie verstuurt vervolgens het signaal dat het doel getriggerd/bereikt is. De Streamende App kan helaas geen code toevoegen aan de bestaande demo App. Een functie koppelen aan een bestaande functie zal daarom niet gaan.
Om dit te bereiken zijn er drie mogelijke opties waarvan er twee onderzoek naar prestaties nodig hebben.
- Voeg een bestaande analytics tool toe aan de demo App voor deze op het apparaat gezet wordt. Voorbeelden hiervan zijn Fabric (de events functionaliteit ervan) en Google Play, die gebruik maakt van Firebase.
- De exploitant dient van tevoren input te geven over het doel. (Deze varianten vereisen verder onderzoek)
- De exploitant geeft het pad van tevoren aan door in een surfaceview opeenvolgend op de (x, y) locaties te drukken waarop de gebruiker hoort te drukken om bij het doel te komen. De x, y coördinaten worden vervolgens opgeslagen en vergeleken met de x, y coördinaten van de gebruiker op het moment van handelen. Als de volgorde van de x, y coördinaten en de coördinaten zelf binnen de afwijking blijven houdt dit in dat de gebruiker bij het doel kwam.
- De exploitant geeft een afbeelding op van het einddoel, button, tekst, imageview, etc. Op iedere klik van de gebruiker wordt het scherm afgezocht naar dezelfde image die de exploitant uploadt. Als deze voorkomt worden de x, y ervan opgeslagen. Zodra de gebruiker op deze x, y binnen de afwijking drukt heeft de gebruiker het doel behaald.
Optie 1 heeft als voor- en nadeel dat de problemen buiten het project vallen. Als er iets niet werkt zoals het hoort moet het gecommuniceerd worden met een externe partij. Daarbij komt er nog een groot nadeel dat deze data alleen verstuurd worden zodra internet gekoppeld is. Ook dient hiervoor nog een extra tool gebruikt te worden om de vastgelegde data te tonen. Naast al deze nadelen dient de exploitant ook contact te hebben met de programmeurs, omdat de programmeurs de code voor de events moeten programmeren en misschien zelfs op de tool de conversie doelen aan moet zetten als de exploitant dit niet zelf kan.
Optie 2 heeft als nadeel dat het pad overeen kan komen zonder het doel te behalen. Zo kan de gebruiker op een en hetzelfde scherm blijven en alles aan tikken. Nu is deze kans vrij klein maar wel aanwezig. Daarbij is het voor de exploitant niet gemakkelijk het pad qua x, y coördinaten uit het hoofd te kennen en in die volgorde in te drukken in het surfaceview input scherm.
Optie 3 is de meest gebruiksvriendelijke omdat deze alleen een afbeelding van de exploitant vereist. Ook hier zit een nadeel dat het “doel” misschien niet het bedoelde doel is. Als de afbeelding van de knop bijvoorbeeld een save button is en deze button vaker voorkomt wordt door iedere save button het doel behaald. Optie 3 werkt dus als het ware alleen voor unieke elementen. Omdat deze optie op zoek gaat naar een afbeelding op het scherm kan deze code behoorlijk zwaar zijn voor het systeem.
Momenteel raad ik deze functie dan ook af. Voor verder onderzoek raad ik optie 3 aan omdat ik hier de meeste potentie in zie.
Bibliografie
Answers Events. (2018, 11 2). Opgehaald van Fabric for Android: https://docs.fabric.io/android/answers/answers-events.html
Helmy, Y. (2018, 11 2). 12 Mobile App Metrics You Should Be Measuring. Opgehaald van Instabug blog: https://instabug.com/blog/6-mobile-app-metrics-look/
Kearl, M. (2018, 11). 10 Essential Mobile App KPIs And Engagement Metrics (And How To Use Them). Opgehaald van Braze magazine: https://www.braze.com/blog/essential-mobile-app-metrics-formulas/
Rhodes, W. (2018, 11 1). 28 Metrics That Matter for Your App. Opgehaald van Savvy: https://savvyapps.com/blog/mobile-app-analytics
Track app conversions with Google Play. (2018, 11 2). Opgehaald van Google Ads Help: https://support.google.com/google-ads/answer/6255257?co=ADWORDS.IsAWNCustomer%3Dfalse&hl=en