6 praktijkvoorbeelden van productanalyse in actie

Datagedreven productmanagement. Dat is wat de coole kinderen tegenwoordig doen, toch? Je hebt misschien gegoogeld en ontdekt dat ‘datagedreven’ zijn draait om het uitgebreide gebruik van productanalyse in de dagelijkse workflow van deze productmanagers.

Maar de vraag is: wat doen ze met de analysegegevens? Hoe gebruiken ze die in de praktijk?

Gelukkig heb ik een lijst samengesteld met 6 gebruiksscenario’s voor productanalyse om je te inspireren.

Wat is productanalyse en waarom zou je je er druk om maken?

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, waardoor je een volledig beeld krijgt van de staat van je product en van klant- of gebruikersgedrag.

Je kunt productanalyse voor je product inschakelen door een gespecialiseerde tool voor productanalyse in te stellen die de activiteit van je gebruikers monitort en je rapporten over gebruikersinteracties stuurt.

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, kunnen we enkele praktische toepassingen van productanalyse gaan verkennen.

Voorbeeld 1: je UI opruimen van functies die niemand gebruikt

Goede producten zijn niet de producten die meer functies hebben dan hun concurrenten. Producten met te veel functies worden namelijk meestal moeilijk te navigeren voor hun gebruikers en onmogelijk te onderhouden voor hun productontwikkelingsteam.

Daarom zorgen goede productteams ervoor dat hun producten alleen functies bevatten die waarde toevoegen voor hun gebruikers. Om dit te doen, 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 verwijderen waard zijn. Het is eenvoudig: controleer het gebruik ervan met een tool voor productanalyse!

Een gebeurtenisgebaseerde tool voor productanalyse 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. Als je deze gebeurtenissen hebt ingesteld voor de productfuncties die je wilt meten, hoef je alleen nog maar een rapport over het gebruik van die functie te maken.

Laten we dit illustreren met een voorbeeld. Stel dat je Spotify leidt, de muziekstreamingdienst die velen van ons gebruiken, en dat je wilt weten 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 de betreffende functie geselecteerd: “Willekeurig afspelen”, samen met de basisfunctie (meestal de kernactie van je product of de 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.

Daarna hebben we een eenvoudige formule toegevoegd die het percentage nummerstreamers berekent dat de functie voor willekeurig afspelen heeft gebruikt.

Door deze grafiek te bekijken, 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 UI op te ruimen.

Voorbeeld #2: Problemen met de gebruikerservaring vinden en oplossen die je installatie- of AHA!-momenten verstoren

De eerste stappen die je gebruikers in je product zetten, hebben een sterke invloed op hun retentie en levenslange waarde. Dit is in ieder geval wat ik herhaaldelijk 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 hogere retentie.

Voor de duidelijkheid: gebruikers bereiken hun installatiemoment wanneer ze alle noodzakelijke configuraties bij het aanmelden hebben uitgevoerd (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 een directe overschrijving uitvoeren met je betaalapp).

Het komt meestal vrij vaak voor dat er problemen met de productervaring zijn in de gebruikersreis, waardoor minder mensen hun installatie- en gewoonte-momenten bereiken. Het goede nieuws is echter dat je ze eenvoudig kunt vinden met een analysetool of UX-heatmaps zoals deze. Met dit soort gegevens kunnen teams zien waar gebruikers afhaken, welke stappen voor frictie zorgen en hoe ze de conversie kunnen verbeteren.

Gerelateerd artikel: 10 beste UX-ontwerptools voor productontwikkelaars

Productanalyse-trechters 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 installatie- en AHA!-momenten), is het gebruik van trechters. Een trechter is een lijst met gebeurtenissen in een specifieke volgorde, waarin 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:

1. Weergave van de aanmeldpagina.
2. Het e-mailadres van de gebruiker in het veld invullen.
3. Op de verzendknop klikken.

Zoals we kunnen zien, hebben meer dan 1.200 gebruikers de aanmeldpagina geopend. Slechts 17% van die 1.200 gebruikers heeft echter het e-mailadres ingevuld, en 90% van degenen 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 een gebruikerstest van ons aanmeldscherm uitvoeren of de sessieherhaling in Heap bekijken, de realtime video-opname van de interactie van de gebruiker met je product.

In het geval van het e-mailveld kom je er misschien achter 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 functies meten tijdens de geleidelijke uitrol

Hoe vaak heb je een nieuwe, opvallende functie aan je product toegevoegd die een complete mislukking was (dus het gebruik niet verbeterde of het zelfs verminderde)? 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 eerst naar een klein aantal gebruikers uit te rollen, te controleren of ze de functie gebruiken (en of deze je belangrijkste statistieken, zoals retentie of levenslange waarde, verbetert) en de functie vervolgens, ervan uitgaande dat deze 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 analysetoolfuncties bevat, zoals Amplitude.

Experimenten instellen en uitvoeren met geavanceerde productanalysesoftware zoals Amplitude

Amplitude beschikt over geavanceerde functionaliteit met de naam 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 onderwerp 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 nu dat je een videogids hebt toegevoegd als onderdeel van het introductieproces van je product en dat je het aantal mensen dat op afspelen klikt en de video bekijkt, wilt vergroten. Hiervoor heb je twee oplossingen ontworpen, waarbij de video op twee verschillende plaatsen in het introductieproces verschijnt.

Om te begrijpen of je oplossingen werken (en welke beter werkt), kunnen we een experiment opzetten 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 naar het starten van een video met 3,4% optimaliseren.

Afhankelijk van de situatie kun je dit zowel als een succes als een mislukking beschouwen. Voor een conversiepercentage voor het openen van een video zou ik zeggen dat dit een mislukking is en dat het niet de moeite waard is om dit 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 productgezondheid.

Als gevolg van je monitoring merk je misschien dalingen of pieken op in de belangrijkste productstatistieken en KPI's, zoals WAU of kleverigheid, die nader onderzoek vereisen. Of je ziet misschien dat de gebruikersbetrokkenheid geleidelijk afneemt - een signaal dat je product een opfrisbeurt nodig heeft.

Gelukkig is een dashboard voor productgezondheid iets wat je eenvoudig kunt maken met elke business-intelligence-tool (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 productgezondheid kun je overwegen de volgende rapporten te maken:

• DAU, WAU of MAU voor je belangrijkste actie (bijv. een nummer streamen voor Spotify). Je keuze uit deze drie hangt af van de natuurlijke frequentie van de belangrijkste actie. Voor het streamen van nummers is dit dagelijks, dus kies je voor DAU.
• Kleverigheid (DAU/WAU, WAU/MAU, enz.). Hiermee zie je het percentage gebruikers dat betrokken is en terugkeert naar je product.
• Registraties in de loop der tijd en Conversies van gratis naar betaald in de loop der tijd. Je wilt deze twee in de gaten houden en ervoor zorgen dat ze geleidelijk groeien.
• Verloop. Dit is het aantal gebruikers dat je gedurende een bepaalde periode bent kwijtgeraakt. Een toename hiervan zou je zorgen moeten baren.
• Retentie. Dit toont het aantal gebruikers dat na een bepaalde periode (bijv. 90 dagen) bij je is gebleven.

Zo ziet een typisch dashboard voor productgezondheid eruit in Mixpanel.

Je kunt gerust andere aanvullende rapporten aan je dashboard toevoegen als deze de gezondheid van je product weergeven.

Voorbeeld 5: Een beslissing nemen over wel of niet uitbrengen wanneer je QA-team een ernstig probleem in de release heeft gevonden

Een van de moeilijkere productbeslissingen die we moeten nemen, is groen licht geven voor het uitbrengen van de release. Dat is moeilijk 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 de bug op te lossen en dat je marketingteam al toezeggingen heeft gedaan en voorbereidingen heeft getroffen die moeilijk terug te draaien zijn.

In deze situatie heb je twee keuzes:

• Groen licht geven voor de release en de gevolgen van de vervelende bug onder ogen zien.
• Je marketingteam een sterk argument geven waarom zij de lancering moeten uitstellen.

Beide opties zien er slecht uit. Maar maak je geen zorgen, want het is mogelijk dat de betreffende bug een veel kleinere impact heeft dan je had gedacht en dat je de release zonder veel gevolgen kunt uitbrengen.

Om de impact van een bug te meten, kunnen we gegevens uit 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 voor je mobiele app op Android 6.0.1 en daarmee 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, besturingssysteemversie, schermgrootte enzovoort.

Als we daarom het rapport ‘Technische details’ openen en de optie ‘Besturingssysteem met versie’ selecteren, ontdekken 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. Mooi meegenomen!

Voorbeeld 6: gebruikerscohorten identificeren die je marketinginspanningen waard zijn

Niet al je gebruikers zijn hetzelfde. Sommigen zijn zeer actieve gebruikers die het grootste deel van je productgebruik vertegenwoordigen (evenals het merendeel van je omzet), terwijl anderen inactief zijn en er weinig hoop is dat je ze kunt betrekken en te gelde kunt maken.

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 je productanalysegegevens benutten door verschillende gebruikerscohorten te identificeren en hun belangrijkste gebruiks- en omzetstatistieken te vergelijken. 

Cohortanalyse met Amplitude

Cohorten zijn groepen gebruikers die een gemeenschappelijk kenmerk delen. Je kunt cohorten creëren 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 omzet genereren en in andere landen onder de verwachtingen presteren.
• 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 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 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 creëren in Amplitude en ze vergelijken.

Stel je voor 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 creëren.

Vervolgens kunnen we de frequentie van aankoopacties van Japanse gebruikers vergelijken met die van alle anderen.

Zoals we kunnen zien, doen Japanse gebruikers meer 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 eenvoudiger 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:

• Feedbacklussen van klanten om ervoor te zorgen dat iedereen de stem van je klanten hoort.
• Productdraadmodellen om je ontwerp snel en zonder gedoe te verbeteren.
• PRD's om iedereen op één lijn te brengen over de implementatiedetails van de functie, en meer.
• Cursussen productanalyse zijn waardevolle bronnen met een hoog rendement op investering om je effectiever te maken in je rol.

Naast het lezen van deze gidsen kun je je ook abonneren op onze nieuwsbrief en ons allerlei nuttige informatie over productmanagement rechtstreeks naar je inbox laten sturen!