Bestäm de tre frågorna innan något mäts. Be sedan byggverktyget räkna tre händelser — inte människor — och kontrollera med ett prov att räkningen ökar med exakt ett per genomförd omgång. Räkna bort dina egna besök innan du tittar på ett enda tal. Använd sedan en tydlig och verksamhetsviktig skillnad mellan två räknare till att välja nästa användartest, en ändring i taget. Händelsekvoten är en ledtråd, inte ett bevis på hur många personer som hoppade av.
Tre frågor, och ordningen är halva svaret
Frågorna ska stå på papper innan mätningen finns. Annars öppnar du en tabell, letar efter ett tal som ser bra ut och hittar alltid ett — mätningen blir då en bekräftelse på det du redan hade tänkt bygga, inte ett besked. De tre frågorna är: öppnas appen alls, registreras handlingen appen finns till för, och mellan vilka två steg är skillnaden störst.
Ordningen spelar roll därför att varje räknare ger sammanhang åt nästa. Jämför två appar som båda registrerar hundra öppningar på en månad. I den första registreras 12 starter och 3 slutföranden. I den andra registreras 60 starter och 4 slutföranden. En ägare som bara räknar slutföranden ser två nästan likadana resultat, men nästa prov bör börja på olika ställen: i den första appen mellan öppning och start, i den andra mellan start och klart. Ett användartest får sedan visa varför räknarna skiljer sig.
Det är också därför fråga tre är sist. En skillnad mellan två steg hjälper inte om nästan inga händelser har registrerats över huvud taget. Då måste du först kontrollera att räkningen fungerar och att länken faktiskt har nått fram.
Prov: skriv de tre frågorna på ett papper och sätt en mening efter varje: ”Om svaret blir lågt gör jag ___.” Kan du inte fylla i den meningen för en av frågorna ska du inte mäta den — ett tal du inte tänker agera på är bara något att oroa sig över.
Beställ en räkning av händelser, inte av människor
Om appen redan sparar något — en bokning, en anteckning, ett konto — kan det finnas en befintlig databas där räknarna ryms. Det du beställer är tre rader per dygn: ett datum, ett händelsenamn och ett antal. Ingenting mer. Det håller beställningen avgränsad, och den ska stå ordagrant, för det räcker att skriva ”lägg in statistik” för att få tillbaka något helt annat än du tänkte dig.
Lägg till en enkel användningsräkning i appen. Ändra inget annat. Räkna tre händelser, med en rad per händelse och dygn: 1. APP_OPPNAD någon öppnade appens startsida 2. UPPGIFT_STARTAD någon började på [det appen finns till för] 3. UPPGIFT_KLAR någon slutförde samma sak Så ska räkningen fungera: - Spara bara datum, händelsens namn och ett antal. Ingen IP-adress, inget namn, ingen mejladress, ingen enhetsuppgift och ingenting annat som kan knytas till en enskild person. - Räkna varje händelse en gång per gång den inträffar. Räkna inte om när samma sida laddas om. - Lägg till en sida på /matning som bara jag kommer åt när jag är inloggad och som visar de tre raderna per dygn för de senaste 30 dygnen. - Lägg till /?matning=av som gör att just den här webbläsaren inte räknas, och /?matning=pa som slår på räkningen igen. Innan du börjar: svara på om du kan göra det här med appens befintliga databas. Om det kräver en extern mät- eller analystjänst ska du inte lägga till någon sådan. Säg det i stället och vänta på mitt besked.
Prov: gå igenom appen en gång från startsidan till färdig uppgift och öppna sedan /matning. Alla tre raderna för i dag ska ha ökat med exakt ett. Ökar en rad med två räknar appen samma sak på två ställen — typiskt både när sidan laddas och när knappen klickas — och den raden fortsätter då att visa för högt. Rätta det innan du läser av. Öppna också /matning i ett privat fönster där du inte är inloggad; syns talen där är sidan inte skyddad.
Den här artikeln säger vad du ska be om, inte vad reglerna kräver. Beställningen ovan begränsar tabellen till aggregerade dygnsräknare och ber uttryckligen att identifierande uppgifter inte ska sparas. Det är en dataminimerande avgränsning, inte en juridisk bedömning. Vad som gäller så snart en app ändå behandlar personuppgifter — och vad du då måste informera om — står i guide 7 om säkerhet och personuppgifter. Svarar verktyget att det behöver koppla in en extern mättjänst är det inte längre samma fråga: stanna, och läs guiden innan du säger ja.
Räkna bort dig själv, annars ljuger den första veckan
I början kan den som byggde appen stå för en stor del av öppningarna. Du öppnar den för att kontrollera en textrad, för att visa den för någon, för att se om ändringen slog igenom. Trettio egna öppningar och fem andra öppningar ger 35 registreringar, och sex av sju är dina. Utan uteslutning kan den första veckan se ut som en succé och den andra som ett ras — fast det enda som ändrats är att du slutade titta.
Markören sitter i den webbläsare där du öppnade /?matning=av. Den följer alltså inte med till mobilen, till surfplattan eller till en annan dator, och den försvinner i privata fönster och när du rensar webbläsardata. Gör därför uteslutningen på varje enhet du faktiskt använder för att titta på appen, och notera dagen då provet nedan gick igenom.
/?matning=av i den webbläsare du brukar använda. Prov: adressen svarar med appens vanliga startsida. Får du ett felmeddelande eller en tom sida byggdes aldrig uteslutningen, och resten av provet är meningslöst./matning. Prov: dagens tre rader står stilla. Har någon rad ökat räknas du fortfarande.Stryk allt som ligger före den dagen. Det underlaget blandar appens användning med ditt eget provande. Och gör om steg 1 varje gång du rensat webbläsaren eller bytt enhet — ett bortglömt uteslutningsprov kan få en avläsning att plötsligt se oförklarligt stark ut.
”Öppnade appen” är inte ”använde appen”
Skillnaden mellan de två första raderna kan leda till ett dyrt felbeslut. Ta en förening som publicerat en app där medlemmar ska anmäla sig till aktiviteter. Efter tre veckor visar APP_OPPNAD 240. Ägaren drar slutsatsen att appen används flitigt och att det som behövs är mer innehåll, och lägger två helger på att skriva in fler aktiviteter. UPPGIFT_STARTAD står på 11.
Det bevisar inte att 229 personer aldrig hittade fram: samma person kan stå för flera öppningar. Det visar bara att starter registrerades mycket mer sällan än öppningar. Ägaren har ändå fått ett bättre nästa prov än ”skriv mer innehåll”: sätt en person framför startsidan och se om hen hittar vägen till anmälan. Först om provet visar att vägen är otydlig finns det stöd för att flytta anmälan och läsa av igen.
Det generella mönstret är att ett tal som främst går upp när länken sprids säger mer om exponering än om appens kärnuppgift. Händelsen som är knuten till handlingen appen finns till för visar åtminstone om just den handlingen inträffar — men fortfarande inte hur många unika personer som utförde den.
Prov: säg appens syfte i en enda mening — ”appen finns till för att medlemmar ska kunna anmäla sig till aktiviteter” — och peka på vilken av de tre raderna som mäter just den meningen. Om ingen rad gör det mäter du fel sak, och ingen mängd data kommer att rätta det.
Läs siffrorna som en trappa, inte som ett betyg
Räkna om raderna till kvoter mot föregående räknare, inte mot en påhittad totalsumma. Med 240 öppningar, 11 starter och 9 slutföranden blir kvoten 4,6 procent från öppning till start och 82 procent från start till klart. Det är händelsekvoter, inte andelen personer som gick vidare. Skillnaden mellan steg ett och steg två är både tydlig och viktig för appens syfte, så övergången från startsidan till uppgiften är det första stället att prova med en människa. Välj inte mekaniskt den största råa differensen: en händelse med hög volym kan annars dominera utan att vara det viktigaste problemet.
Att 11 starter registrerades efter 240 öppningar betyder inte att formuläret är dåligt, och inte heller att 229 personer gav upp. Det ger en hypotes: vägen från startsidan till formuläret kan vara svår att hitta. Prova just den vägen innan du ändrar den.
Ändra en sak i taget. Två samtidiga ändringar ger en förändring du inte kan tillskriva någon av dem, och samma resonemang som i artikeln om att göra en sak i taget gäller här.
Prov: skriv upp en hel måndag–söndag före ändringen och en hel måndag–söndag efter, och jämför kvoterna. Notera utskick och andra toppar separat. Lika långa perioder med samma veckodagar tar inte bort all osäkerhet, men hindrar dig från att blanda en vardagshelg med två arbetsveckor och kalla skillnaden en effekt av appändringen.
Små tal ljuger på två sätt
Det första sättet är den delade länken. Du lägger länken i en gruppchatt på en tisdag. Onsdagen visar 80 öppningar, torsdagen 6, fredagen 2. Toppen kan vara effekten av ett enda inlägg som passerade förbi, inte en tillväxtkurva. Notera därför alltid i avläsningen vilken dag du delade länken eller skickade ett utskick, och läs kurvan utan den dagen när du vill veta hur appen används i vardagen.
Det andra sättet är entusiasten. En räkning som bara räknar händelser kan inte skilja 40 personer som öppnat appen en gång från en person som öppnat den fem gånger om dagen i åtta dagar. Det är priset för att inte spara något som pekar ut en enskild person, och för en liten app är det ett pris värt att betala. Kompensera i stället utanför mätningen: fråga tre personer som du vet har fått länken om de använt appen den senaste veckan. Tre ja mot 40 öppningar betyder något helt annat än tre nej mot samma 40.
Prov: lägg fingret över den högsta dagen i tabellen. Ändras din slutsats när den dagen försvinner vilar slutsatsen på ett enda dygn, och då är den inte färdig. Gör ingen ändring på grund av den dagen ensam. Samla i stället fler hela veckor med samma veckodagar och skriv upp varje utskick, så att nästa jämförelse går att tolka.
Vad du gör med svaret
Avläsningen ska sluta i exakt en mening om vilken övergång du provar härnäst. Skriv ned den, annars glider mätningen tillbaka till att vara något du tittar på.
PERIOD: [datum] till [datum], [antal] dygn UTESLUTNING AV EGNA BESÖK VERIFIERAD: [datum då provet gick igenom] UTSKICK ELLER DELAD LÄNK UNDER PERIODEN: [nej / ja, vilken dag] APP_OPPNAD: [antal] UPPGIFT_STARTAD: [antal] kvot mot öppnade: [ %] UPPGIFT_KLAR: [antal] kvot mot startade: [ %] STÖRSTA SKILLNADEN LIGGER MELLAN: [steg X och steg Y] ÖVERGÅNGEN JAG PROVAR NU: [en enda övergång] NÄSTA AVLÄSNING: [datum, lika många dygn som ovan]
När du ser mellan vilka räknare skillnaden är störst är nästa åtgärd inte att gissa varför. Sätt en person framför appen och be hen göra just den övergången, enligt det femminuters användartestet. Räkningen har då gjort sitt jobb: den har talat om var du ska titta, så att det kvalitativa provet inte slösas bort på en annan del av appen.
Var metoden inte räcker
Räkningen svarar på de tre frågorna du bestämde i början, och på inga andra. Sagt rakt ut:
Det här får du inte veta av tre rader i en tabell
- Aldrig varför. Tabellen visar 240 öppningar och 11 starter. Den säger inte hur många personer som står bakom talen, eller om skillnaden beror på en osynlig knapp, obegriplig text eller upprepade öppningar.
- Inte de som aldrig kom. Är alla tre raderna nära noll kan länken ha nått få personer, räknaren vara trasig eller appen ha använts lite. Tabellen ensam skiljer inte alternativen åt.
- Inte en person från tio. Det är ett medvetet val, inte en brist, men det betyder att ordet ”användare” inte får användas om dessa tal.
- Inte om det blev bra. En uppgift kan vara räknad som klar och ändå fel ifylld, dubbelinskickad eller ångrad efteråt.
- Inte vad som gäller i ditt fall. Om mätningen ska omfatta något mer än rena räkningar är det en fråga för guide 7, inte för den här artikeln.
Metoden är alltså en kompass, inte en dom: den pekar ut vilken övergång du ska prova med en människa, och inte mer än så.
Du har tre nedskrivna frågor med en handling knuten till varje, en räkning som ökar med exakt ett per genomförd omgång, ett daterat uteslutningsprov som gått igenom på varje enhet du använder, ett protokoll för en period med lika många dygn som nästa, och en enda nedskriven övergång att prova där skillnaden mellan räknarna är störst.
Begreppen kontrollerades 13 augusti 2026. Google Analytics definition av händelseräkning skiljer antalet registrerade händelser från användarmått, och definitionen av totala användare räknar unika användare. Länkarna förklarar gränsdragningen; de är inte en rekommendation att installera tjänsten. Webbläsarmarkörens beteende följer MDN:s dokumentation av Web Storage och HTML-standardens avsnitt om lokal lagring.