6 kommentarerHar man inte koll på hur sina kunder beter sig i ens butik i dagsläget är det omöjligt att göra förändringar som garanterat leder till förbättringar.
Du måste ha statistik, du måste ha bra statistik och du måste ha koll på statistikens innebörd. Jag har tidigare förlitat mig på Google Analytics som har många bra funktioner för e-handlare. Dock är det svårt att förstå hur man implementerar deras funktioner och dels är det dumt att förlita sig på tredje part när ett bra statistikverktyg ska ingå i en bra e-handelslösning. Jag har nu på allvar påbörjat arbetet med min egen lösning och nu ska jag presentera hur jag tänkt.
Startsidan
I dagsläget visas en vald preferens på intervall i tabellform och diagramform. Jag har valt att visa orders/säljvärde i den ena grafen samt unika besökare/sidvisningar i den andra.
Funnelanalys
Här har jag valt ett intervall på 5 och valt att visa tidsenheten månader. De olika värdena är bara en bråkdel av det jag mäter i min statistik, men jag har inte lagt in all data i denna tabellen än. Den skulle bli väldigt stor då.
Per default visas en funnelanalys (flaskhalsanalys) baserad på följande upplägg. Blå fält är konverteringsgrader:
Unik Besökare -> Kategorivisningar -> Produktvisningar -> Lägga vara i kundkorg -> Gå till Kassan -> Slutföra ordern
Den är såklart inte helt korrekt eftersom det inte är en given funnel mellan kategorivisning och produktvisning. Jag ska kompensera för detta i framtida versioner.
Värdena man kan läsa av är UB= Unika Besök, SV = Sidvisningar, KV=Kategorivisningar, PV=Produktvisningar, CA=Cart Addition (Antal unika kunder som lagt en vara i kundvagn), CP = Cart Products Amount (Antal tillägg i kundvagn totalt), CO=Check Out (Kunder som sett kassan), Orders= Slutförda orders, Sales=Omsättning, Snitt=Snittordervärde. Anledningen till de konstiga värdena i feb-april är att jag inte mätte allting korrekt då. Statistiken har varit ett work in progress.
A/B/C/D/E… -testing
Evolution stödjer att man kör ett oändligt antal versioner av sin butik och visar dessa slumpmässigt för olika kunder för att mäta effekter av förändringsarbete. Ovan visar när jag testade skillnaden mellan att låta kunder lägga produkterna i kundvagnen direkt i kategorivisningen jämfört med att bara låta dem göra det på produktens egna sida.
Produktförsäljning
Denna statistikfunktion visar försäljningsvärde och antal sålda enheter av olika produkter under ett visst tidsintervall. Här saknas lite diagramfunktioner och konverteringsinformation. Jag vill veta hur varje produkt konverterar genom att jämföra unika visningar med hur många som lägger produkten i kundvagnen och till sist slutför en order med produkten. På detta sätt kan jag avgöra om en produkt är intressant, men för dyr, eller om en produkt är dåligt promotead men konverterar jättebra.
Framtiden
Förhoppingsvis bär framtiden med sig en kurs i hur man skriver bra SQL-kod, för mina statistikfunktioner har alltid en tendens att bli fruktansvärt slöa. Angående funktionerna så blir det utökning, customization och förbättring som gäller, men redan nu är jag väldigt nöjd med det jag kan få ut ur mitt statistikprogram.
juni 27th, 2008 at 4:07 e m
Du skall få två tips från dryg-hjalmar.
A/B-testning är inte tänkt att visas slumpmässigt. Den skall låsas till en viss user mha cookies. Annars vet du inte hur användaren påverkas om han besöker först A-sidan och sedan B-sidan.
Angående SQL kan jag rekommendera att du aggregerar data. Dvs summera inte all din data varje gång utan ha bakgrundsprocesser som summerar ihop datan per dag, vecka, månad så att du snabbt och enkelt kan ta ut dina vanligaste rapporter. När man gör den typen av databasdesign är det viktigare att titta på funktionerna du behöver än normalisering och dylikt tjafs.
juni 27th, 2008 at 4:08 e m
Det ser föresten skitgrymt ut, coolt att du har orkat fixa allt det där. Det hade jag aldrig orkat. Men så är jag helt såld på analytics också. Den dagen de stänger mitt analyticskonto eller gör något knasigt där är dagen mitt liv tar slut.. typ
juni 27th, 2008 at 4:23 e m
Men Hjalmar jag har ju förklarat att jag gör selektionen slumpmässigt OM kunden inte besökt sidan förut.
Om du går in på sidan 20 dagar senare från ditt första besök får du självklart samma konfiguration förutsatt att den fortfarande är aktiv i A/B-testet.
Jag kör aggregering på Trivia och det är smidigt men jag förlorar realtidsvisningen då eller hur? Det är lite därför jag vill ha eget statistiksystem och inte Analytics. Jag vill se allting i realtid, det äger, men blir skitslött
juni 27th, 2008 at 4:53 e m
Fördelen med att köra det aggregerat är att du har det i en egen tabell om inte en egen databas. Då behöver du inte bekymra dig om locks. Dvs om en skrivning sker medans din läsning/summering pågår så pre-empas läsningen tills skrivningen är klar.
Om du kör aggregeringen per dag varje timme. Per vecka och månad varje dag (mitt i natten) så förlorar du ju aldrig mer än max 23h59m statistik på veckorapporterna. Det kanske inte spelar så stor roll med en dag hit eller dit i en månadsrapport.
Det finns mig veterligen ingen perfekt lösning, du kan ju försöka dig på att summera det från live-tabellen och det summerade datat men det är krångligt att göra på ett bra sätt tror jag (du får göra det i userland/php antagligen).
juni 27th, 2008 at 4:54 e m
En lösning är att ha en separat statistik daemon som ligger och summerar allt data i realtid i minnet och som kan svara på dina requests via ett anrop. Lite overkill för ditt system antagligen.
juni 27th, 2008 at 5:06 e m
Jag brukar köra dagssamanställningar kombinerat med en enkel ”livesida” där saker som är tidskritiska men som inte kräver så mycket av databasen visas. Det blir någon slags kompromiss mellan statistikberoendet och vad som är praktiskt…
juni 27th, 2008 at 5:44 e m
Datorer är billigt som fan. Köp en galet snabb server med tri-ultra-quad-processorer och 50 terrabyte minne. Inte värt att koda saker effektivt när man kan köpa sig ur problemet. Okej kanske inte alltid sant. Men fan va skönt att datorkraft är så satans billigt. Min tid är fan inte det.
Ola (Proffesionell Databasprogrammerare)
juni 27th, 2008 at 9:20 e m
En detalj som du kanske känner till men som många väldigt rutinerade systemutvecklare missar är att skapa korrekta index i databasen. Gör garanterat under för dina svarstider och jag gissar att storleken på dina databaser inte hindrar att du kör dina rapporter mot levande data. Med summeringstabeller/aggregerade värden börjar underhåll och komplexitet dra iväg lite väl för att motivera nyttan (något bättre svarstid).
Din blogg har blivit given läsning även om jag inte pysslar med e-handel. Bra inspiration och skön mentalitet!
juni 27th, 2008 at 10:09 e m
Jag administrerar ett tiotal sidor med wordpress i grunden, och jag har inte enkom positiva erfarenheter från Analytics. Jag har provkört 5 olika statistikprogram, och alla visar olika data, Ananlytics verkar missa en hel del av trafiken. Adsense visar också andra siffror.
Måste vara skönt att skapa ett eget system från grunden, så att du vet att du kan lita på datan.
juni 27th, 2008 at 10:26 e m
Analytics sorterar ut skit ur din trafik. Så vad du får med andra verktyg är helt enkelt sämre data, men kanske fler besökare från rysslands utkanter.
juni 29th, 2008 at 12:22 e m
Det är ju också mycket lätt att gömma sig (som besökare) från GA. Ett exempel är att lägga till ”127.0.0.1 http://www.google-analytics.com” i hosts-filen. Det finns ju också flera plugins t Firefox som gör samma sak. Eftersom Analytics är det vanligaste statistikverktyget är det flest besökare som ”gömmer” sig för det. Statistiken ska man ta med en nypa salt, och tänker man på det är Analytics riktigt bra.
juni 29th, 2008 at 3:04 e m
Ja, analytics äger precis som många säger. Mitt system stödjer analytics och dess konverteringsfunktioner, men jag vill undvika upplåsning av statistik hos tredje part och dessutom ha statistik i realtid.