6 praktijkvoorbeelden van productanalyse in actie
Datagestuurd productmanagement. Dat is wat de coole kinderen tegenwoordig doen, toch? Je hebt misschien gegoogeld en ontdekt dat ‘datagestuurd’ zijn draait om het uitgebreide gebruik van productanalyse in de dagelijkse workflow van deze productmanagers.
Maar de vraag is: wat doen ze met de analytische gegevens? Hoe gebruiken ze die in de praktijk?
Gelukkig heb ik een lijst samengesteld met 6 toepassingen van productanalyse om je te inspireren.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Wat is productanalyse en waarom zou je dit belangrijk moeten vinden?
Productanalyse is het proces van het verzamelen van gegevens over je digitale product (waaronder gebruikersactiviteit, financiële gegevens enzovoort), het analyseren daarvan en het nemen van dagelijkse beslissingen en beslissingen over de productstrategie op basis van je bevindingen.
Het gebruik van productanalyse verhoogt de kwaliteit van de besluitvorming die je als productmanager uitvoert aanzienlijk, omdat je je ideeën of oplossingen kunt onderbouwen en bewijzen met behulp van gegevens.
Als kwantitatieve gegevens vormen deze ook een aanvulling op de kwalitatieve gegevens die je met klantinterviews hebt verzameld. Zo krijg je een compleet beeld van de staat van je product en van klant- of gebruikersgedrag.
Je kunt productanalyse voor je product inschakelen door een gespecialiseerde productanalysetool in te stellen die de activiteit van je gebruikers monitort en rapporten over gebruikersinteracties naar je verstuurt.
Deze tools verzamelen vervolgens de gegevens over gebruikersacties die ze uit je product hebben verzameld en laten je aangepaste rapporten maken om antwoorden te vinden op enkele vragen die je mogelijk hebt over het gebruik van je product.
Nu we weten waar productanalyse over gaat, gaan we enkele praktische voorbeelden van het toepassen van productanalyse bekijken.
Voorbeeld 1: je gebruikersinterface opruimen van functies die niemand gebruikt
Goede producten zijn niet de producten met meer functies dan hun concurrenten. Producten met te veel functies worden juist meestal moeilijk te navigeren voor hun gebruikers en onmogelijk te onderhouden voor hun productontwikkelingsteam.
Daarom zorgen goede productteams ervoor dat hun producten alleen functies hebben die waarde toevoegen voor hun gebruikers. Hiervoor voeg je steeds nieuwe functies toe waarvan je denkt dat mensen ze zullen gebruiken en verwijder je de functies waarvan je weet dat ze niet langer waardevol zijn.
Het volgende voor de hand liggende dilemma is hoe je de functies kiest die het waard zijn om te verwijderen. Het is eenvoudig: controleer hun gebruik met een productanalysetool!
Een op gebeurtenissen gebaseerde productanalysetool zoals Mixpanel gebruiken om op te ruimen
Om het gebruik van een functie te kunnen volgen, moet je er een gebeurtenis voor instellen en deze activeren telkens wanneer de gebruiker met die functie interactie heeft. Ervan uitgaande dat je deze gebeurtenissen hebt ingesteld voor de productfuncties die je wilt meten, hoef je alleen maar een rapport over het gebruik van die functie te maken.
Laten we dit met een voorbeeld illustreren. Stel je voor dat je leiding geeft aan Spotify, de muziekstreamingdienst die velen van ons gebruiken, en dat je wilt begrijpen of het de moeite waard is om de functie voor willekeurig afspelen te verwijderen.
Hiervoor maken we een nieuw Inzichtenrapport dat er als volgt uitziet.
Hier hebben we onze betreffende functie geselecteerd: ‘Willekeurig afspelen’, samen met de basisfunctie (meestal de kernactie van je product of Noordster) waarmee we deze willen vergelijken—in dit geval ‘Een nummer streamen’. Voor beide hebben we de optie ‘DAU tellen’ geselecteerd, zodat we het aantal unieke gebruikers zien dat elke dag willekeurig afspelen gebruikt en nummers streamt.
Vervolgens hebben we een eenvoudige formule toegevoegd die het percentage nummerstreamers berekent dat de functie voor willekeurig afspelen heeft gebruikt.
Door naar deze grafiek te kijken, kunnen we 2 belangrijke conclusies trekken:
- Nauwelijks 0,5% van alle muziekstreamers gebruikt de functie voor willekeurig afspelen.
- Het gebruik van willekeurig afspelen is de afgelopen maand gestaag afgenomen van 1,3% naar 0,5%.
Op basis van deze gebruiksstatistieken kunnen we Willekeurig afspelen beschouwen als een geschikte kandidaat om te verwijderen en onze gebruikersinterface op te schonen.
Voorbeeld 2: problemen met de gebruikerservaring vinden en oplossen die je configuratie of AHA!-momentstromen verstoren
De eerste stappen die je gebruikers in je product zetten, hebben een grote invloed op hun retentie en lifetime value. Dit is in ieder geval wat ik talloze keren heb gezien bij de producten waarvoor ik verantwoordelijk ben geweest.
Elke verbetering in het proces waarmee gebruikers je product instellen en hun AHA!-moment bereiken, zou uiteindelijk leiden tot een hoger retentieniveau.
Voor alle duidelijkheid: gebruikers bereiken hun instelmoment wanneer ze alle noodzakelijke configuraties tijdens het aanmelden hebben voltooid (bijvoorbeeld het verstrekken van creditcardgegevens en het verifiëren daarvan in een betaalapp). Het AHA!-moment is het punt in de gebruikersreis waarop ze voor het eerst het voordeel en de waarde van je product ervaren (bijvoorbeeld direct geld overmaken met je betaalapp).
Het komt doorgaans vaak voor dat er problemen met de productervaring zijn in de gebruikersreis, waardoor minder mensen hun instel- en gewoontemoment bereiken. Maar het goede nieuws is dat je deze problemen eenvoudig kunt vinden met een analysetool of UX-heatmaps zoals deze. Met dit soort gegevens kunnen teams zien waar gebruikers afhaken, welke stappen voor wrijving zorgen en hoe ze de conversie kunnen verbeteren.
Gerelateerd artikel: 10 beste UX-ontwerptools voor productontwikkelaars
Productanalysetrechters in Heap gebruiken om conversieproblemen op te lossen
Een van de meest praktische manieren om gebruikersreizen te volgen en problemen daarin op te lossen (waaronder reizen die leiden tot je instel- en AHA!-momenten), is het gebruik van trechters. Een trechter is een lijst met gebeurtenissen die in een specifieke volgorde zijn geplaatst, waarmee je de conversie van gebruikers van de ene gebeurtenis naar de andere kunt zien.
Zo ziet een trechteranalyse eruit voor een eenvoudige aanmeldpagina met één e-mailveld en een verzendknop.
Voor onze aanmeldpagina volgen we gebruikers voor deze gebeurtenissen:
- Weergave van de aanmeldpagina.
- Het e-mailadres van de gebruiker in het veld invullen.
- Op de verzendknop klikken.
Zoals we kunnen zien, waren er meer dan 1.200 gebruikers die de aanmeldpagina bezochten. Slechts 17% van die 1.200 gebruikers heeft echter zijn e-mailadres ingevuld, en 90% van de gebruikers die hun e-mailadres hebben opgegeven, heeft op de verzendknop geklikt.
Deze trechter vertelt ons dat er iets mis is met het e-mailveld en dat we moeten onderzoeken wat precies.
Hiervoor kunnen we ofwel gebruikerstests uitvoeren met ons aanmeldscherm, of de sessieherhaling in Heap bekijken. Dit is de realtime video-opname van de interactie van de gebruiker met je product.
In het geval van het e-mailveld ontdek je misschien dat de e-mailvalidatie frustrerend is en dat je gebruikers het opgeven nadat ze een paar keer hebben geprobeerd hun e-mailadres in te voeren.
Voorbeeld 3: De impact van een functie meten tijdens de geleidelijke uitrol
Hoe vaak heb je een nieuwe, flitsende functie aan je product toegevoegd die een volslagen mislukking was (oftewel: het gebruik niet verbeterde of zelfs schaadde)? Dit is zelfs de meest getalenteerde PM's minstens een paar keer overkomen.
Omdat we niet altijd weten of de functie die we hebben gebouwd succesvol zal zijn of zal mislukken, is het een goed idee om deze naar een klein aantal gebruikers uit te rollen en te controleren of zij de functie gebruiken (en of deze je belangrijkste statistieken, zoals retentie of lifetime value, verbetert)—en deze vervolgens, ervan uitgaande dat de functie succesvol was, naar alle andere gebruikers uit te rollen.
Je kunt zowel de geleidelijke uitrol als het meten van de impact uitvoeren met een gespecialiseerde productanalyseoplossing die essentiële functies van analysesoftware bevat, zoals Amplitude.
Experimenten instellen en uitvoeren met geavanceerde productanalysesoftware zoals Amplitude
Amplitude beschikt over geavanceerde functionaliteit genaamd Experiments. Je kunt deze gebruiken om A/B-tests uit te voeren of om functies geleidelijk uit te rollen. Ik ga niet in op de details van het maken van een experiment, omdat dat een verhaal voor een andere keer is, maar je kunt de documentatie van Amplitude over deze functie bekijken. Daarin wordt alles beschreven, van API-berichten tot integraties, meldingen en prijzen.
Stel je nu voor dat je een videogids hebt toegevoegd als onderdeel van je productintroductie en dat je het aantal mensen dat op afspelen klikt en de video bekijkt, wilt verhogen. Hiervoor heb je twee oplossingen ontworpen, waarbij de video op twee verschillende plaatsen in de productintroductie verschijnt.
Om te begrijpen of je oplossingen werken (en welke beter werkt), kunnen we een experiment instellen met een gedeeltelijke uitrol van 25% voor variant A en 25% voor variant B.
Wanneer we dit experiment starten en het een tijdje laten lopen om statistisch significante gebruikersgegevens te verzamelen, is dit wat we zien.
De bovenstaande grafiek is een conversietrechter van een bezoek aan de homepage tot het starten van een video. Zoals we kunnen zien, is variant A de winnaar en kan deze de conversie voor het starten van een video met 3,4% optimaliseren.
Afhankelijk van de situatie kun je dit beschouwen als een succes of een mislukking. Voor een conversieratio voor het openen van een video zou ik zeggen dat dit een mislukking is en dat het niet de moeite waard is om deze naar iedereen uit te rollen. Maar als het resultaat van een experiment een stijging van 3,4% in retentie was, zou dat een aanzienlijk succes zijn.
Voorbeeld #4: De productgezondheid monitoren
Producten zijn levende organismen die zich goed kunnen voelen of "ziek" kunnen worden. Om ervoor te zorgen dat je altijd op de hoogte bent van de gezondheid van je product en dat je eventuele problemen ermee kunt identificeren en oplossen, moet je de “hartslag” van je product monitoren in de vorm van een dashboard voor de productgezondheid.
Als gevolg van je monitoring merk je misschien dalingen of pieken op in de belangrijkste productstatistieken en KPI's, zoals WAU of plakkerigheid, die nader onderzoek vereisen. Of je ziet misschien dat de betrokkenheid van je gebruikers geleidelijk afneemt — een signaal dat je product een opfrisbeurt nodig heeft.
Gelukkig is een dashboard voor de productgezondheid iets wat je eenvoudig kunt maken met elke business-intelligencetool (bijv. Mixpanel of Amplitude).
Belangrijke productstatistieken bijhouden met Mixpanel
Dashboards in Mixpanel bestaan uit meerdere gerelateerde rapporten die je naast elkaar plaatst. Voor een dashboard voor de productgezondheid kun je overwegen de volgende rapporten te maken:
- DAU, WAU of MAU voor je belangrijkste actie (bijv. een nummer streamen op Spotify). Je keuze uit deze drie hangt af van de natuurlijke frequentie van de belangrijkste actie. Voor het streamen van nummers is die dagelijks, dus kies je voor DAU.
- Plakkerigheid (DAU/WAU, WAU/MAU, enz.). Hiermee zie je het percentage gebruikers dat betrokken is en terugkeert naar je product.
- Aanmeldingen in de loop van de tijd en conversies van gratis → betaald in de loop van de tijd. Je wilt deze twee in de gaten houden en ervoor zorgen dat ze geleidelijk groeien.
- Klantverloop. Dit is het aantal gebruikers dat je gedurende een bepaalde periode bent kwijtgeraakt. Een stijging hiervan zou je zorgen moeten baren.
- Retentie. Hiermee zie je het aantal gebruikers dat na een bepaalde periode (bijv. 90 dagen) bij je is gebleven.
Zo ziet een typisch dashboard voor de productgezondheid eruit in Mixpanel.
Je kunt gerust andere rapporten aan je dashboard toevoegen als ze de gezondheid van je product weergeven.
Voorbeeld #5: Beslissen of je een release wel of niet uitbrengt wanneer je QA-team een ernstig probleem in de release heeft gevonden
Een van de lastigere productbeslissingen die we moeten nemen, is groen licht geven voor het uitbrengen van een release. En dat is lastig omdat releases bijna nooit vrij van bugs zijn. Het wordt nog ingewikkelder wanneer we een bug vinden die de klantervaring kan schaden.
Maar waarom is het ingewikkeld? Als je een vervelende bug hebt, moet je die toch eerst oplossen voordat je de release uitbrengt? Stel je dan eens voor dat je ontdekt dat je team nog een week nodig heeft om het probleem op te lossen, terwijl je marketingteam al toezeggingen heeft gedaan en voorbereidingen heeft getroffen die moeilijk terug te draaien zijn.
In deze situatie heb je twee keuzes:
- Geef groen licht voor de release en aanvaard de gevolgen van de vervelende bug.
- Geef je marketingteam een sterk argument waarom ze de lancering moeten uitstellen.
Beide opties zien er slecht uit. Maar maak je geen zorgen: het is mogelijk dat de betreffende bug een veel kleinere impact heeft dan je had gedacht en dat je de release zonder grote gevolgen kunt uitbrengen.
Om de impact van een bug te meten, kunnen we gegevens van ons productanalyseplatform gebruiken.
Google Analytics gebruiken om de impact van een bug te berekenen
Stel je voor dat je een bug hebt die af en toe crashes veroorzaakt in je mobiele app op Android 6.0.1 en die de klantreis volledig verstoort. Om de impact van deze bug te begrijpen, moeten we weten hoeveel gebruikers deze versie van Android hebben.
Gelukkig kan Google Analytics, naast gebruiksgegevens, ook gegevens verzamelen en opslaan over de technische aspecten van onze gebruikers, zoals hun apparaattype, versies van het besturingssysteem, schermformaten enzovoort.
Als we dus het rapport “Technische details” openen en de optie “Besturingssysteem met versie” selecteren, zien we dat slechts 1,2% van het totale gebruikersbestand Android 6.0.1 gebruikt.
Hoewel deze gegevens al een aanwijzing zijn om groen licht te geven voor de release, kunnen we nog een stap verder gaan en ook de potentiële financiële impact berekenen door de omzet te controleren die we ontvangen van gebruikers van Android 6.0.1.
Als we de totale omzet van “alle gebruikers” vergelijken met die van “gebruikers van Android 6.0.1”, zien we het volgende.
Blijkbaar leveren de gebruikers die na de release crashes zullen ervaren ons geen omzet op. Daarom zullen we geen financiële gevolgen ondervinden van het uitbrengen van de versie met de bug. Bonus!
Voorbeeld 6: gebruikerscohorten identificeren die je marketinginspanningen waard zijn
Niet al je gebruikers zijn gelijk. Sommigen zijn intensieve gebruikers die verantwoordelijk zijn voor het grootste deel van het gebruik van je product (en ook voor het grootste deel van je omzet), terwijl anderen inactief zijn en er weinig hoop is dat je hen kunt activeren en gelde kunt laten opleveren.
Natuurlijk wil je graag de gebruikers identificeren die je de meeste omzet kunnen opleveren en je marketinginspanningen op hen richten. Maar hoe doe je dat?
Je kunt gebruikmaken van de analysegegevens van je product door verschillende gebruikerscohorten te identificeren en hun belangrijkste gebruiks- en monetisatiemaatstaven te vergelijken.
Cohortanalyse met Amplitude
Cohorten zijn groepen gebruikers die een gemeenschappelijk kenmerk delen. Je kunt cohorten maken op basis van:
- Platform (bijvoorbeeld Mac- en Windows-gebruikers). Ik had een product waarvoor Mac-gebruikers een 30% hogere LTV hadden dan Windows-gebruikers.
- Geografie (bijvoorbeeld gebruikers uit Frankrijk en Griekenland). Afhankelijk van het product kan het in bepaalde landen goed geld opleveren, terwijl het in andere landen onder de verwachtingen presteert.
- Registratiedatum (bijvoorbeeld gebruikers die zich in november en januari hebben geregistreerd). Stel je voor dat je Black Friday-campagne een enorm succes was. Je richtte je op de juiste mensen en je cohort van november heeft een veel hogere LTV dan dat van andere maanden.
- Gebruikersgedrag of gebruik van bepaalde functies (bijvoorbeeld gebruikers die nummers in willekeurige volgorde afspelen en gebruikers die dat niet doen). Bij het bouwen van een functie wil je echt dat de gebruikers ervan een betere betrokkenheid en hogere LTV hebben. Anders was de functie geen succes en is het de moeite waard om ervan af te komen.
Laten we nu een paar cohorten maken in Amplitude en ze vergelijken.
Stel dat je wilt weten of het de moeite waard is om in marketing voor Japan te investeren. We kunnen in Amplitude op deze manier een cohort voor Japanse gebruikers maken.
Vervolgens kunnen we de frequentie van aankoopacties van Japanse gebruikers vergelijken met die van alle anderen.
Zoals we kunnen zien, doen Japanse gebruikers vaker aankopen dan gemiddeld. Daarom is het de moeite waard om je marketingteam te vragen zich op Japan te richten.
Samenvatting
Productanalyse maakt je leven als productmanager gemakkelijker doordat je datagedreven ontwerpbeslissingen kunt nemen en niet uitsluitend hoeft te vertrouwen op je intuïtie en onderbuikgevoel.
Goed geïnformeerde beslissingen nemen op basis van analysegegevens is geweldig, maar daar moet je niet stoppen. Enkele andere geweldige hulpmiddelen die je kunt gebruiken om een betere productmanager te worden, zijn:
- Feedbackloops van klanten om ervoor te zorgen dat iedereen de stem van je klanten hoort.
- Productwireframes om je ontwerp snel en zonder problemen te itereren.
- PRD's om iedereen op één lijn te brengen over de implementatiedetails van de functie, en meer.
- Cursussen in productanalyse zijn waardevolle bronnen met een hoge ROI om je effectiever te maken in je rol.
Naast het lezen van deze handleidingen kun je je ook abonneren op onze nieuwsbrief en ons allerlei nuttige informatie over productmanagement rechtstreeks in je inbox laten bezorgen!