3 måter å øke retensjonen med eksperimentering

Da vi hadde fått anskaffelsen til å gå bra, bestemte vi oss for å fokusere eksperimenteringen vår på hvordan vi kunne beholde disse nye registreringene for å maksimere fordelene med denne tilstrømningen av nye brukere.

BiggerPockets er en nettressurs for eiendomsinvestorer, med pedagogisk innhold og verktøy utviklet for å hjelpe folk som søker økonomisk frihet gjennom eiendomsinvestering. Jeg driver arbeidet vårt med å optimalisere konverteringsfrekvensen, med fokus på KPI-ene og konverteringstraktene som er viktigst for virksomheten.

Da vi begynte å fokusere på retensjon, lærte vi raskt at det å teste hvordan man beholder brukere er noe helt annet enn å teste registrerings- og konverteringstrakter. Så, for å gi deg et forsprang hvis du ønsker å takle retensjon, er her de største testhindringene vi møtte på og hvordan vi overvant dem.

For å begynne, hva gjør det vanskelig å påvirke og måle retensjon via eksperimentering?

En av de vanskeligste tingene med retensjonstester er tidsforsinkelsen mellom avslutningen av eksperimentet og mottak av alle dataene du trenger for å ta en beslutning. I de fleste A/B-tester skjer starthendelsen og den siste konverteringshendelsen i samme økt. I retensjonstester vil konverteringshendelsene du ønsker å måle sannsynligvis skje uker eller til og med måneder etter den første starthendelsen. Det vil være mange ekstra berøringspunkter mellom eksperimentutløsningen og konverteringshendelsen knyttet til retensjon. Dette gjør det veldig vanskelig å teste raskt og ha et tydelig kontrolleksperiment.

Gitt hvor mye tilbakeholdelsen er i trakten i de fleste selskaper, er det nyttig å gå fra tilbakeholdelse som nøkkelmåling (som vil ha mange andre input utenfor eksperimentet) til å identifisere hvilke atferder som kan endres ved eksperimentering, som fører til høyere tilbakeholdelse. Dette lar deg kjøre mindre tester for å påvirke brukerhendelsene som korrelerer med at brukeren blir beholdt i trakten. Hvis du trenger hjelp til å tenke på hvordan du skal gripe an dette, er et måltre et flott sted å starte.

BiggerPockets-forum

For eksempel, hos BiggerPockets er en av våre viktigste produktfunksjoner våre eiendomsforum. Basert på retensjonsanalyser vi har gjort i Amplitude (vårt produktanalyseverktøy), vet vi at folk som legger ut innlegg på forumene har mye større sannsynlighet for å bli aktive brukere på nettstedet vårt. I stedet for å teste "øker det å oppfordre brukere til å legge ut innlegg på forumene våre 4-ukers retensjon?", kan vi enkelt forenkle dette ved å teste den beste måten å få brukere til å legge ut innlegg i forumene i løpet av den første uken etter registrering.

Så vi kan anta at hvis vi får flere brukere til å legge ut innlegg i forumene, er det mer sannsynlig at de kommer tilbake. Retensjonsdataene våre viser bare at foruminnlegg er korrelert med høyere retensjon, ikke at det nødvendigvis forårsaker høyere retensjon. For å bekrefte dette kan vi kjøre eksperimentet og deretter utføre retensjonsanalyse i Amplitude på testkohorten om en måned eller så for å bekrefte at de som ble eksponert for eksperimentvariasjonene ble retenert i en høyere grad enn kontrollgruppen.

Slik ser en retensjonsanalyse ut i amplitude. Kohorten av brukere som la ut innlegg i forumene i løpet av den første uken (grønn linje) har høyere retensjon.

Vanligvis i A/B-testing måler vi konvertering fra en startende hendelse til en avsluttende «konverteringshendelse». For eksempel kan du på en test av betalingssiden måle konvertering fra lasting av betalingssiden (starthendelse) til innsending av en bestilling (konverteringshendelse). Med retensjon er det ikke en klart definert konverteringshendelse på samme side.

For eksempel, hvis du vil teste retensjonen til brukere som nettopp har registrert seg på nettstedet ditt, bryr du deg ikke nødvendigvis om de kom tilbake neste dag, to dager senere, tre dager senere og så videre. Det du sannsynligvis bryr deg om er om de kom tilbake gjentatte ganger og jevnt over tid. Du kan samle dette til en enkelt beregning, for eksempel «brukeren kom tilbake 3+ ganger i løpet av den første måneden». Det kan imidlertid være vanskelig å finne ut hvor ofte en bruker må komme tilbake til nettstedet ditt for å bli beholdt. For å få en dypere forståelse av hvordan du velger en retensjonsmåling som er meningsfull for produktet ditt, anbefaler jeg at du leser denne bloggartikkelen

Husk denne formelen: Retensjon = (aktivering * engasjement *gjenoppstandelse) der:

Jeg anbefaler på det sterkeste å begrense testene til ett enkelt trinn i retensjonsprosessen (aktivering, engasjement eller gjenoppliving). Jo mindre tidsgapet er mellom at brukeren utfører starthendelsen og konverteringshendelsen, desto raskere får du læring på testen, og desto mindre vil disse konverteringene bli overskygget av eksterne faktorer. For denne typen tester er det nyttig å huske at retensjon er resultatet, ikke målet. Målet er at brukerne skal ha en verdifull opplevelse med produktet ditt.

Du kan se dette mens du tester brukerens onboarding-flyt. I stedet for å teste om en endring i onboarding fører til at brukeren blir beholdt, kan du teste om en endring i onboarding hjelper en bruker med å finne ut hvordan de kan komme i gang med å bruke produktet ditt i løpet av de første 7 dagene. Når brukerne har begynt å bruke produktet, kan du teste måter å generere returbesøk på. Noe som leder meg til mitt neste punkt….

«Naturlig frekvens» refererer til hvor ofte kunden din naturlig støter på problemet som produktet ditt løser. For eksempel er et av BiggerPockets’ kunders problemer at de har et spesifikt spørsmål om utleiere de ønsker å stille til andre utleiere som har opplevd samme situasjon. Vi forventer at de fleste utleiere vil støte på dette problemet omtrent én gang i måneden, noe som gjør deres naturlige frekvens for foruminnlegg omtrent månedlig.

Å prøve å optimalisere til en unaturlig frekvens resulterer vanligvis i at du snurrer deg selv i sirkler mens du spammer brukerne dine med varsler for å lokke dem til å komme tilbake til nettstedet ditt. Det hjelper ikke brukerne dine med å finne verdi i produktet ditt, og det skader forholdet ditt til dem på lang sikt.

Hvis for eksempel BiggerPockets skulle optimalisere for daglig aktive foruminnleggere, ville vi teste feil frekvens. De fleste av kundene våre eier 0–5 utleieeiendommer, og disse eiendomsinvestorene burde ikke ha daglige spørsmål som dukker opp. Hvis de legger ut spørsmål på forumene våre daglig, virker det sannsynlig at de faktisk *ikke* får løst problemet sitt. I stedet vil jeg tro at de må legge ut spørsmålet sitt ganske ofte for å få svar.

Å identifisere produktets naturlige frekvens hjelper deg med å bestemme hvor ofte kunder bør komme tilbake til nettstedet ditt (for mer informasjon om å bestemme produktets naturlige frekvens, sjekk ut denne artikkelen). Fra et testperspektiv hjelper testing med riktig naturlig frekvens deg med å identifisere en enkelt KPI som du kan behandle som konverteringshendelsen (f.eks. kom brukeren tilbake minst én gang i løpet av de første 7 dagene), noe som gjør det enklere for deg å måle den statistiske signifikansen av testene dine.

Vi har funnet ut at det å forstå brukeratferd er mer komplekst for å kunne beholde kundene. Selv om alle kundene dine kan bruke betalingssiden på en lignende måte, kan innholdet eller funksjonen som motiverer dem til å komme tilbake til nettstedet ditt fungere bra for én kundetype og være en katastrofe for en annen. Dette betyr at testanalysen din må være detaljert og nyansert.

Etter hvert som retensjonstesting blir mer kompleks, kan det være fristende å gjøre hypotesen til en boks som fylles ut med tilbakevirkende kraft etter at en test er startet. Jeg kan ikke understreke nok hvor viktig det er å ALLTID formulere hypotesen din tydelig før et eksperiment.

Faren ved å ikke være tydelig på hypotesen din før du starter eksperimentet er at du når slutten av testen og innser at du ikke har noe å lære annet enn at "opplevelse X var verre for kunde Y enn opplevelse Z", uten å egentlig forstå hvorfor du trodde brukerne ville reagere annerledes (eller hvilke brukere du trodde ville handle annerledes).

Dette er spesielt viktig hvis du jobber med et team, når folk ikke alltid sier ifra hvis de ikke forstår hva som testes.

For å bygge sterke hypoteser anbefaler jeg å følge Optimizelys "Hvis ____, så ____, fordi ____." hypoteserammeverk.

Vi sees igjen om noen uker når jeg deler beste praksis for eksperimentering med global navigasjon!

Hvis du er interessert i å fortsette samtalen, kan du finne meg på linkedin eller kontakte meg direkte på alex@biggerpockets.com. Og hvis du er klar til å komme i gang med eksperimentering, ta kontakt med oss ​​i dag.