En titt på Play Store / App Store på en hvilken som helst telefon vil avsløre at de fleste installerte apper har fått oppdateringer utgitt i løpet av den siste uken. Et besøk på nettstedet etter noen uker kan vise noen endringer i layout, brukeropplevelse eller kopi.

Programvareprodukter i dag sendes i iterasjoner for å validere antagelser og hypoteser om hva som gjør produktopplevelsen bedre for brukerne. Til enhver tid kjører selskaper som booking.com (hvor jeg jobbet før) hundrevis av A / B-tester på nettsteder for nettopp dette formålet.

For applikasjoner levert over internett, er det ikke nødvendig å bestemme utseendet til et produkt 12-18 måneder i forveien, og deretter bygge og til slutt sende det. I stedet er det helt praktisk å frigjøre små endringer som gir verdi til brukerne når de implementeres, og fjerner behovet for å gjøre antakelser om brukerpreferanser og ideelle løsninger - for enhver antagelse og hypotese kan valideres ved å utforme en test for å isolere effekten av hver endring.

I tillegg til å levere kontinuerlig verdi gjennom forbedringer, tillater denne tilnærmingen et produktteam å samle kontinuerlig tilbakemelding fra brukerne og deretter korrigere kurset etter behov. Å lage og teste hypoteser hvert par uker er en billigere og enklere måte å bygge en kurskorrigerende og iterativ tilnærming til å skape produktverdi .

Hva er hypotesetesting?

Mens du sender en funksjon til brukerne, er det viktig å validere antagelser om design og funksjoner for å forstå deres innvirkning i den virkelige verden.

Denne valideringen gjøres tradisjonelt gjennom produkthypotesetesting, der eksperimentatoren skisserer en hypotese for en endring og deretter definerer suksess. For eksempel hvis en dataproduktleder hos Amazon har en hypotese om at visning av større produktbilder vil øke konverteringsfrekvensen, og suksess er definert av høyere konverteringsfrekvenser.

En av de viktigste aspektene ved hypotesetesting er isolering av forskjellige variabler i produktopplevelsen for å kunne tilskrive suksess (eller fiasko) til de endringene som er gjort. Så hvis vår Amazon-produktsjef hadde en ytterligere hypotese om at visning av kundeanmeldelser rett ved siden av produktbilder ville forbedre konvertering, ville det ikke være mulig å teste begge hypotesene samtidig. Hvis du gjør det, vil årsaken og effekten ikke tilskrives riktig. derfor må de to endringene isoleres og testes hver for seg.

Dermed bør produktbeslutninger om funksjoner støttes av hypotesetesting for å validere ytelsen til funksjonene.

Ulike typer hypotesetesting

A / B-testing

De vanligste brukssakene kan valideres ved randomisert A / B-testing, der en endring eller funksjon frigjøres tilfeldig til halvparten av brukerne (A) og holdes tilbake fra den andre halvdelen (B). Når vi kommer tilbake til hypotesen om at større produktbilder forbedrer konverteringen på Amazon, vil halvparten av brukerne få vist endringen, mens den andre halvparten vil se nettstedet som det var før. Konverteringen blir deretter målt for hver gruppe (A og B) og sammenlignet. I tilfelle en betydelig økning i konvertering for gruppen som viser større produktbilder, vil konklusjonen være at den opprinnelige hypotesen var riktig, og endringen kan rulles ut til alle brukere.

Multivariat testing

Ideelt sett bør hver variabel isoleres og testes separat slik at endelig tilskrives endringer. Imidlertid kan en slik sekvensiell tilnærming til testing være veldig treg, spesielt når det er flere versjoner å teste. For å fortsette med eksemplet, i hypotesen om at større produktbilder fører til høyere konverteringsfrekvenser på Amazon, er 'større' subjektivt, og flere versjoner av 'større' (f.eks. 1,1x, 1,3x og 1,5x) kan trenge å bli testet.

I stedet for å teste slike tilfeller sekvensielt, kan en multivariat test vedtas, der brukerne ikke blir delt i to, men i flere varianter. For eksempel består fire grupper (A, B, C, D) av 25% av brukerne hver, hvor A-gruppe brukere ikke vil se noen endring, mens de i variantene B, C og D vil se bilder større etter 1,1x, 1,3x og 1,5x. I denne testen testes flere varianter samtidig mot den nåværende versjonen av produktet for å identifisere den beste varianten.

Før / etter testing

Noen ganger er det ikke mulig å dele brukerne i to (eller i flere varianter), da det kan være nettverkseffekter på plass. For eksempel, hvis testen innebærer å avgjøre om en logikk for å formulere bølgepriser på Uber er bedre enn en annen, kan ikke driverne deles inn i forskjellige varianter, ettersom logikken tar hensyn til etterspørsel og tilbudsmisforhold for hele byen. I slike tilfeller må en test sammenligne effektene før endringen og etter endringen for å komme til en konklusjon.

Imidlertid er begrensningen her manglende evne til å isolere effekten av sesongmessighet og eksternalitet som på annen måte kan påvirke test- og kontrollperioder. Anta at det blir gjort en endring i logikken som bestemmer overspenningspriser på Uber t , slik at logikk A brukes før og logikk B brukes etter. Mens effekten før og etter tid t kan sammenlignes, er det ingen garanti for at effektene bare skyldes logikkendringen. Det kunne ha vært en forskjell i etterspørsel eller andre faktorer mellom de to tidsperiodene som resulterte i en forskjell mellom de to.

Tidsbasert On / Off Testing

Ulempene med før / etter testing kan i stor grad overvinnes ved å distribuere tidsbasert på / av-testing, der endringen blir introdusert for alle brukere i en viss tidsperiode, slått av i en like lang periode, og deretter gjentas i lengre varighet.

For eksempel, i Uber-brukstilfellet, kan endringen vises til sjåfører på mandag, trekkes tilbake på tirsdag, vises igjen på onsdag og så videre.

Selv om denne metoden ikke fjerner effekten av sesongmessighet og eksternalitet, reduserer den dem betydelig, noe som gjør slike tester mer robuste.

Test design

Å velge riktig test for den aktuelle brukssaken er et viktig skritt for å validere en hypotese på den raskeste og mest robuste måten. Når valget er gjort, kan detaljene i testdesignet skisseres.

Testdesignet er ganske enkelt en sammenhengende oversikt over:

• Hypotesen som skal testes: Hvis brukerne viser større produktbilder, vil de kjøpe flere produkter.
• Suksessberegninger for testen: Kundekonvertering
• Beslutningskriterier for testen: Testen validerer hypotesen om at brukere i varianten viser en høyere konverteringsfrekvens enn de i kontrollgruppen.
• Målinger som må instrumenteres for å lære av testen: Kundekonvertering, klikk på produktbilder

I tilfelle hypotesen om at større produktbilder vil føre til forbedret konvertering på Amazon, er suksessverdien konvertering og beslutningskriteriene er en forbedring i konvertering.

Etter at riktig test er valgt og designet, og suksesskriteriene og beregningene er identifisert, må resultatene analyseres. For å gjøre det er noen statistiske begreper nødvendige.

Prøvetaking

Når du kjører tester, er det viktig å sikre at de to variantene som er valgt for testen (A og B) ikke har en skjevhet med hensyn til suksessmåling. For eksempel, hvis varianten som ser de større bildene allerede har en høyere konvertering enn varianten som ikke ser endringen, er testen partisk og kan føre til feil konklusjoner.

For å sikre ingen skjevhet i prøvetakingen, kan man observere gjennomsnittet og variansen for suksessmåling før endringen ble introdusert.

Betydning og kraft

Når en forskjell mellom de to variantene er observert, er det viktig å konkludere med at den observerte endringen er en faktisk effekt og ikke en tilfeldig. Dette kan gjøres ved å beregne betydningen av endringen i suksessmåling.

I lekmannsbetingelser, betydning måler frekvensen testen viser at større bilder fører til høyere konvertering når de faktisk ikke gjør det. Makt måler frekvensen som testen forteller oss at større bilder fører til høyere konvertering når de faktisk gjør det.

Så, tester må ha en høy verdi av kraft og en lav verdi av betydning for mer nøyaktige resultater.

---

Mens en grundig utforskning av de statistiske konseptene som er involvert i produkthypotesetesting er utenfor omfanget her, anbefales følgende handlinger for å forbedre kunnskapen på dette fronten:

• Dataanalytikere og dataingeniører er vanligvis dyktige i å identifisere de riktige testdesignene og kan veilede produktansvarlige, så sørg for å utnytte deres ekspertise tidlig i prosessen.
• Det er mange online kurs om hypotesetesting, A / B-testing og relaterte statistiske konsepter, for eksempel Udemy , Udacity , og Coursera .
• Bruk av verktøy som Googles Firebase og Optimizely kan gjøre prosessen enklere takket være en stor mengde out-of-the-box-funksjoner for å kjøre de riktige testene.

Bruke hypotesetesting for vellykket produktadministrasjon

For kontinuerlig å levere verdi til brukerne, er det viktig å teste forskjellige hypoteser, med det formål flere typer produkthypotesetesting kan brukes. Hver hypotese må ha en tilhørende testdesign, som beskrevet ovenfor, for å definitivt validere eller ugyldiggjøre den.

Denne tilnærmingen hjelper til med å kvantifisere verdien som leveres av nye endringer og funksjoner, fokusere på de mest verdifulle funksjonene og levere inkrementelle iterasjoner.

Forstå det grunnleggende

Hva er en produkthypotese?

En produkthypotese er en antagelse om at en viss forbedring i produktet vil føre til en økning i viktige beregninger som inntekter eller produktbruksstatistikk.

Hva er de tre nødvendige delene av en hypotese?

De tre nødvendige delene av en hypotese er antagelsen, tilstanden og spådommen.

Hvorfor gjør vi A / B-testing?

Vi utfører A / B-testing for å sikre at enhver forbedring i produktet øker våre sporede beregninger.

Hva brukes A / B-testing til?

A / B-testing brukes til å sjekke om produktforbedringene våre skaper den ønskede endringen i beregninger.

Hva er A / B-testing og multivariat testing?

A / B-testing og multivariat testing er typer hypotesetesting. A / B-testing sjekker hvor viktige beregninger endres med og uten en eneste endring i produktet. Multivariat testing kan spore flere varianter av samme produktforbedring.