För att få mer handlingsbara resultat bör marknadsförare frångå sessionsbaserad attributering och börja mäta A/B-tester baserat på intäkt per användare.
Framgångsrik marknadsföring kräver en förmåga att mäta det relativa bidraget från varje aktivitet och kanal till konvertering och inköp under en längre tidsperiod. Många lösningar för A/B-testning och konverteringsoptimering driver dock marknadsförare mot bristfällig attribution för enskilda sessioner och kortsiktig optimering. Som ett resultat anammar marknadsförare missvisande taktik som undergräver effektiviteten i deras marknadsföringskampanjer.
I den här artikeln kommer jag att lyfta fram vikten av att välja rätt KPI för dina experiment och hur du övervinner en central utmaning när det gäller att välja agila KPI:er.
Som nämnts används ”per session”-KPI:er oftare i branschen än KPI:er baserade på ”unika användare”. Detta beror främst på att de är enare att implementera, hålla uppdaterade och optimera mot. De bästa KPI:erna för att uppnå verkliga, långsiktiga intäktsökningar baseras dock på ”per användare”. Därför är det så:
Varje statistisk motor där ute förutsätter att tester (namnliigen ”unika användare” / ”sessioner”) är oberoende. Med oberoende menar vi att var och en har samma sannolikhet att konvertera/ge förväntade intäkter. Det är uppenbart att när samma användare inleder flera sessioner, så ändras sannolikheten för konvertering avsevärt mellan sessionerna. Det finns ett tydligt statistiskt beroende.
I praktiken initierar många användare flera sessioner. Konsekvensen av att dessa antaganden bryts är att tillförlitligheten i det statistiska motorns resultat försämras kraftigt på ett okänt sätt. Så statistisk signifikans, sannolikhet att vara bäst, konfidensintervall och vinnardeklarationer blir därmed mindre tillförlitliga i en okänd utsträckning. Nyckeltalet ”per användare” är mycket mer tillförlitligt eftersom varje användare räknas bara en gång, och antagandet att olika användare är statistiskt oberoende förblir ganska starkt.
Med tanke på de inbyggda fördelarna med per-användar-KPI:er, varför är det ovanligt att fatta beslut med hjälp av KPI:er som har normaliserats utifrån unika (även kallade distinkta) användare? Det visar sig nämligen att det är en betydligt svårare uppgift än det ser ut att räkna distinkta användare i stor skala.
Optimering på företagsnivå innebär ofta en ström av miljontals händelser med upprepade användar-ID:n. Därför kräver det enorma mängder minne att upprätthålla en struktur för datainsikter som gör det möjligt att räkna varje observerat användar-ID endast en gång, i synnerhet när en användare kör flera tester och hanterar flera unika räknare för var och en. Olika algoritmer har föreslagits som, givet ett begränsat minne och en ström av återkommande nummer, ger en approximativ distinkt räkning av dessa objekt. Kronjuvelen är den banbrytande HyperLogLog-algoritmen, som ständigt förbättras av flera aktörer inom analysområdet. Den ligger till grund för många av de andra heta tekniker som vi hör om i dag.
HyperLogLog har dock ett uppenbart problem som förhindrar tillförlitlig användning för A/B-testning. Algoritmen garanterar vad standardfelet blir utifrån den mängd minne som har allokerats till den. Ett exempel på en implementering använder 12 kb per HyperLogLog-räknare, vilket ger ett standardfel på 0,81 %. Det låter jättebra! Men vad innebär det egentligen?
Det innebär alltså att om du simulerar en miljon tester med HyperLogLog för att räkna och beräknar den relativa standardavvikelsen för de approximativa antalen jämfört med verkligheten skulle standardavvikelsen ligga mycket nära 0,81 %. HyperLogLog ger dock inga garantier för det maximala approximationsfelet för en enskild given räknare – det kan vara +0,01 %, –1,5 % eller +4 %! När det gäller analys är detta i allmänhet tillräckligt. När du fattar beslut om vilken A/B-testvariant som är bättre baserat på en skillnad på 2 % i resultatet behöver du veta att detta är en funktion – inte ett fel.
Av denna anledning använder vissa experiment- och personaliseringsplattformar som Experience OS endast exakta antal unika värden när de beräknar KPI:er som används för beslutsfattande.