Een gebruiker in een mobiele applicatie houden is een hele wetenschap. De auteur van de cursus beschreef de basisprincipes ervan in ons artikel op VC.ru Maxim Godzi, hoofd Machine Learning bij App in the Air. Maxim vertelt over de tools die in het bedrijf zijn ontwikkeld aan de hand van het voorbeeld van werk aan analyse en optimalisatie van een mobiele applicatie. Deze systematische aanpak voor productverbetering, ontwikkeld in App in the Air, heet Retentioneering. U kunt deze tools in uw product gebruiken: sommige ervan zijn al aanwezig op GitHub.
App in the Air is een applicatie met ruim 3 miljoen actieve gebruikers over de hele wereld, waarmee je vluchten kunt volgen, informatie kunt krijgen over wijzigingen in vertrek-/landingstijden, check-in en luchthavenkenmerken.
Van trechter naar traject
Alle ontwikkelteams bouwen een onboarding funnel (een proces gericht op gebruikersacceptatie van het product). Dit is de eerste stap waarmee u het hele systeem van bovenaf kunt bekijken en toepassingsproblemen kunt opsporen. Maar naarmate het product zich ontwikkelt, zult u de beperkingen van deze aanpak voelen. Met een simpele trechter kun je geen niet voor de hand liggende groeipunten voor een product zien. Het doel van de trechter is om een algemeen beeld te geven van de fasen van gebruikers in de applicatie, om u de statistieken van de norm te laten zien. Maar de trechter zal voorzichtig afwijkingen van de norm verbergen in de richting van voor de hand liggende problemen of, integendeel, speciale gebruikersactiviteit.
Bij App in the Air bouwden we onze eigen funnel, maar door de specifieke kenmerken van het product kwamen we uit bij een zandloper. Toen besloten we de aanpak uit te breiden en gebruik te maken van de rijke informatie die de applicatie ons zelf geeft.
Wanneer u een trechter bouwt, verliest u de onboardingtrajecten van de gebruiker. Trajecten bestaan uit een reeks acties van de gebruiker en de applicatie zelf (bijvoorbeeld het verzenden van een pushmelding).
Met behulp van tijdstempels kunt u heel eenvoudig het traject van de gebruiker reconstrueren en er voor elk van hen een grafiek van maken. Natuurlijk zijn er veel grafieken. Daarom moet u vergelijkbare gebruikers groeperen. U kunt bijvoorbeeld alle gebruikers ordenen op tabelrijen en aangeven hoe vaak ze een bepaalde functie gebruiken.
Op basis van een dergelijke tabel hebben we een matrix gemaakt en gebruikers gegroepeerd op basis van de gebruiksfrequentie van functies, dat wil zeggen op knooppunten in de grafiek. Dit is meestal de eerste stap naar inzicht: je zult bijvoorbeeld al in dit stadium zien dat sommige gebruikers sommige functies helemaal niet gebruiken. Toen we de frequentieanalyse uitvoerden, begonnen we te bestuderen welke knooppunten in de grafiek de “grootste” zijn, dat wil zeggen welke pagina’s gebruikers het vaakst bezoeken. Categorieën die fundamenteel verschillen volgens een criterium dat voor u belangrijk is, worden onmiddellijk gemarkeerd. Hier zijn bijvoorbeeld twee clusters van gebruikers die we hebben verdeeld op basis van de abonnementsbeslissing (er waren in totaal 16 clusters).
Hoe te gebruiken
Door op deze manier naar uw gebruikers te kijken, kunt u zien welke functies u gebruikt om ze te behouden of ze bijvoorbeeld te laten aanmelden. Uiteraard zal de matrix ook voor de hand liggende zaken laten zien. Bijvoorbeeld dat degenen die een abonnement hebben gekocht, het abonnementsscherm hebben bezocht. Maar daarnaast kun je ook patronen ontdekken waar je anders nooit van zou hebben geweten.
We hebben dus volkomen per ongeluk een groep gebruikers gevonden die een vlucht toevoegt, deze de hele dag actief volgt en vervolgens voor een lange tijd verdwijnt totdat ze weer ergens heen vliegen. Als we hun gedrag zouden analyseren met conventionele tools, zouden we denken dat ze simpelweg niet tevreden waren met de functionaliteit van de applicatie: hoe kunnen we anders verklaren dat ze de applicatie één dag hebben gebruikt en nooit meer zijn teruggekeerd. Maar met behulp van grafieken zagen we dat ze erg actief zijn, alleen passen al hun activiteiten in één dag.
Nu is het onze belangrijkste taak om zo’n gebruiker aan te moedigen verbinding te maken met het loyaliteitsprogramma van zijn luchtvaartmaatschappij terwijl hij onze statistieken gebruikt. In dit geval importeren we alle vluchten die hij koopt en proberen we hem ertoe aan te zetten zich aan te melden zodra hij een nieuw ticket koopt. Om dit probleem op te lossen, zijn we ook gaan samenwerken met Aviasales, Svyaznoy.Travel en andere applicaties. Wanneer hun gebruiker een ticket koopt, vraagt de app hen om de vlucht toe te voegen aan App in the Air, en wij zien dit meteen.
Dankzij de grafiek zagen we dat 5% van de mensen die naar het abonnementsscherm gaan, dit opzeggen. We begonnen dergelijke gevallen te analyseren en zagen dat er een gebruiker is die naar de eerste pagina gaat, de verbinding met zijn Google-account initieert, deze onmiddellijk annuleert, weer naar de eerste pagina gaat, enzovoort, vier keer. In eerste instantie dachten we: “Er is duidelijk iets mis met deze gebruiker.” En toen realiseerden we ons dat er hoogstwaarschijnlijk een bug in de applicatie zat. In de trechter zou dit als volgt worden geïnterpreteerd: de gebruiker was niet blij met de reeks machtigingen die de applicatie vraagt, en hij vertrok.
Bij een andere groep verdwaalde 5% van de gebruikers op het scherm waarop de app hen vraagt er één te selecteren uit alle agenda-apps op hun smartphone. Gebruikers selecteerden steeds opnieuw verschillende agenda's en verlieten vervolgens eenvoudigweg de app. Er bleek een UX-probleem te zijn: nadat iemand een agenda had geselecteerd, moest hij rechtsboven op Gereed klikken. Het is alleen zo dat niet alle gebruikers het hebben gezien.
Eerste scherm van App in the Air
In onze grafiek zagen we dat ongeveer 30% van de gebruikers niet verder komt dan het eerste scherm: dit komt door het feit dat we behoorlijk agressief zijn in het ertoe aanzetten van de gebruiker om zich te abonneren. Op het eerste scherm vraagt de app u om u te registreren via Google of Triplt, en er is geen informatie over het overslaan van de registratie. Van degenen die het eerste scherm verlaten, klikt 16% van de gebruikers op ‘Meer’ en komt weer terug. We zijn erachter gekomen dat ze op zoek zijn naar een manier om intern te registreren in de applicatie en die zullen we in de volgende update vrijgeven. Bovendien klikt 2/3 van degenen die meteen weggaan helemaal nergens op. Om erachter te komen wat er met hen gebeurt, hebben we een heatmap gemaakt. Het blijkt dat klanten op een lijst met app-functies klikken die geen klikbare links zijn.
Leg een micromoment vast
Vaak zie je mensen de paden naast de asfaltweg vertrappelen. Retentioneering is een poging om deze paden te vinden en, indien mogelijk, de wegen te veranderen.
Het is natuurlijk slecht dat we van echte gebruikers leren, maar we zijn in ieder geval automatisch patronen gaan volgen die wijzen op een gebruikersprobleem in de applicatie. Nu ontvangt de productmanager e-mailmeldingen als er een groot aantal ‘loops’ optreden – wanneer de gebruiker keer op keer naar hetzelfde scherm terugkeert.
Laten we eens kijken naar welke patronen in gebruikerstrajecten over het algemeen interessant zijn om naar te zoeken om de problemen en groeigebieden van een applicatie te analyseren:
- Lussen en cycli. De hierboven genoemde lussen zijn wanneer een gebeurtenis zich herhaalt in het traject van de gebruiker, bijvoorbeeld kalender-kalender-kalender-kalender. Een lus met veel herhaling is een duidelijke indicatie van een interfaceprobleem of onvoldoende gebeurtenismarkering. Een cyclus is ook een gesloten traject, maar omvat in tegenstelling tot een lus meer dan één gebeurtenis, bijvoorbeeld: vluchtgeschiedenis bekijken - een vlucht toevoegen - vluchtgeschiedenis bekijken.
- Flowstoppers - wanneer de gebruiker vanwege een obstakel de gewenste beweging door de applicatie niet kan voortzetten, bijvoorbeeld een scherm met een interface die niet duidelijk is voor de klant. Dergelijke gebeurtenissen vertragen en verschuiven het traject van gebruikers.
- Bifurcatiepunten zijn belangrijke gebeurtenissen waarna de trajecten van cliënten van verschillende typen worden gescheiden. Dit zijn met name schermen die geen directe overgang of call-to-action naar de doelactie bevatten, waardoor sommige gebruikers er effectief naartoe worden geduwd. Een scherm dat niet direct verband houdt met het kopen van inhoud in een applicatie, maar waarop klanten wel of niet geneigd zijn inhoud te kopen, zal zich bijvoorbeeld anders gedragen. Splitspunten kunnen invloedspunten zijn op het handelen van uw gebruikers met een plusteken - zij kunnen de beslissing om een aankoop of klik te doen beïnvloeden, of een minteken - zij kunnen bepalen dat de gebruiker na een paar stappen de applicatie verlaat.
- Afgebroken conversiepunten zijn potentiële splitsingspunten. Je kunt ze beschouwen als schermen die tot een gerichte actie kunnen leiden, maar dat is niet zo. Dit kan ook een moment zijn waarop de gebruiker een behoefte heeft, maar we kunnen deze niet bevredigen omdat we er simpelweg niets van weten. Trajectanalyse moet het mogelijk maken deze behoefte te identificeren.
- Afleidingspunt - schermen/pop-ups die geen waarde bieden voor de gebruiker, geen invloed hebben op de conversie en trajecten kunnen ‘vervagen’, waardoor de gebruiker wordt afgeleid van gerichte acties.
- Blinde vlekken zijn verborgen punten in de applicatie, schermen en features die voor de gebruiker heel moeilijk te bereiken zijn.
- Afvoerputten – punten waar verkeer lekt
Over het algemeen liet de wiskundige benadering ons toe te begrijpen dat de klant de applicatie op een heel andere manier gebruikt dan productmanagers gewoonlijk denken wanneer ze een standaardgebruiksscenario voor de gebruiker proberen te plannen. Als je op kantoor zit en de coolste productconferenties bijwoont, is het nog steeds erg moeilijk om je de verscheidenheid aan echte veldomstandigheden voor te stellen waarin de gebruiker zijn problemen zal oplossen met behulp van de applicatie.
Dit doet me denken aan een geweldige grap. Een tester loopt een bar binnen en bestelt: een glas bier, 2 glazen bier, 0 glazen bier, 999999999 glazen bier, een hagedis in een glas, -1 glas bier, qwertyuip glazen bier. De eerste echte klant loopt de bar binnen en vraagt waar het toilet is. De bar barst in vlammen en iedereen sterft.
Productanalisten, diep ondergedompeld in dit probleem, begonnen het concept van een micromoment te introduceren. De moderne gebruiker heeft een onmiddellijke oplossing voor zijn probleem nodig. Google begon hier een paar jaar geleden over te praten: het bedrijf noemde dergelijke gebruikersacties micromomenten. De gebruiker raakt afgeleid, sluit per ongeluk de applicatie af, begrijpt niet wat er van hem wordt verlangd, logt een dag later opnieuw in, vergeet het weer en volgt dan de link die een vriend hem in de messenger heeft gestuurd. En al deze sessies mogen niet langer dan 20 seconden duren.
Dus begonnen we te proberen het werk van de ondersteunende dienst zo in te richten dat medewerkers bijna in realtime konden begrijpen wat het probleem was. Tegen de tijd dat iemand naar de ondersteuningspagina komt en zijn vraag begint te schrijven, kunnen we de essentie van het probleem bepalen, wetende wat zijn traject is geweest: de laatste 100 gebeurtenissen. Voorheen automatiseerden we de verdeling van alle ondersteuningsverzoeken in categorieën met behulp van ML-analyse van de teksten van ondersteuningsverzoeken. Ondanks het succes van de categorisering, wanneer 87% van alle aanvragen correct verdeeld zijn in één van de 13 categorieën, wordt er gewerkt met trajecten die automatisch de meest geschikte oplossing voor de situatie van de gebruiker kunnen vinden.
We kunnen updates niet snel vrijgeven, maar we kunnen het probleem wel opmerken en, als de gebruiker het scenario volgt dat we al hebben gezien, hem een pushmelding sturen.
We zien dat de taak van het optimaliseren van een applicatie rijke tools vereist voor het bestuderen van gebruikerstrajecten. Als u bovendien alle paden kent die gebruikers volgen, kunt u de noodzakelijke paden effenen, en met behulp van aangepaste inhoud, pushmeldingen en adaptieve UI-elementen “bij de hand” de gebruiker naar gerichte acties leiden die het beste bij zijn behoeften passen en geld opleveren , data en andere waarde voor uw bedrijf.
Waar u op moet letten
- Als we de gebruikersconversie alleen bestuderen met behulp van trechters als voorbeeld, gaan we de rijke informatie verloren die de applicatie ons zelf geeft.
- Retentieanalyse van gebruikerstrajecten in grafieken helpt u te zien welke functies u gebruikt om gebruikers te behouden of hen bijvoorbeeld aan te moedigen zich te abonneren.
- Retentietools helpen automatisch en in realtime patronen op te sporen die gebruikersproblemen in de applicatie aangeven, en bugs te vinden en te sluiten waar ze moeilijk op te merken waren.
- Ze helpen bij het vinden van niet-voor de hand liggende patronen van gebruikersgedrag.
- Retentietools maken het mogelijk om geautomatiseerde ML-tools te bouwen voor het voorspellen van belangrijke gebruikersgebeurtenissen en statistieken: gebruikersverlies, LTV en vele andere statistieken die eenvoudig in de grafiek kunnen worden bepaald.
We bouwen een gemeenschap rond Retentioneering voor de vrije uitwisseling van ideeën. Je kunt de tools die wij ontwikkelen zien als een taal waarin analisten en producten van verschillende mobiele en webapplicaties inzichten, beste technieken en methoden kunnen uitwisselen. Hoe u deze hulpmiddelen kunt gebruiken, leert u in de cursus Binair district.
Bron: www.habr.com