Kraschrapporter och appanalys

Därför rapporteras krascher sällan

En krasch är ett dåligt ögonblick för användaren, och att rapportera den är en insats hen inte har något skäl att göra. Många krascher inträffar bara på vissa enheter, systemversioner eller nätverkslägen som aldrig testats, så de syns aldrig när du själv använder appen. En del fel är inte ens krascher: en vy som fryser, en betalning som tyst misslyckas, en inloggning som går i cirkel. Utan data ser de ut som att användarna tappar intresset.

Appbutikerna visar en del krasch- och prestandadata i App Store Connect och Google Play Console, och Google Play väger in stabilitet i hur appar presenteras. Den datan är bra som kontroll, men den kommer sent och saknar detaljerna en utvecklare behöver.

Verktyg för kraschrapporter

Verktyg	Styrkor	Tänk på
Firebase Crashlytics	Gratis, vanligt, bra för både native och plattformsoberoende appar	Del av Googles ekosystem; gå igenom datainställningarna
Sentry	Starkt för React Native och webb tillsammans, prestandaspårning, möjlighet till EU-lagring	Betalnivåer när volymen växer
App Store Connect / Play Console	Inbyggt, inget SDK behövs	Fördröjt och mindre detaljerat

Oavsett val avgör tre saker om rapporterna blir användbara. Ladda upp felsökningssymboler eller källkartor vid varje release, annars går stackspåren inte att läsa. Märk varje rapport med appversion, så att du ser om en rättning fungerade. Och lägg till brödsmulor, en kort logg över vad användaren gjorde före kraschen, utan personuppgifter som namn eller meddelanden.

En liten plan för händelser

Analys går snett när teamet spårar allt och läser ingenting. Börja i frågorna ni behöver svar på och definiera sedan bara de händelser som besvarar dem. Skriv ner planen: händelsens namn, när den skickas och vilka egenskaper den bär.

Slutför nya användare introduktionen? Spåra att introduktionen startat och slutförts.
Når de kärnhandlingen? Spåra den handling som definierar nyttan, till exempel bokning gjord eller order lagd.
Var misslyckas de? Spåra fel som visas för användaren, som misslyckad betalning eller inloggning.
Kommer de tillbaka? Använd verktygets vy för återkommande användare baserat på appöppningar.
Vilken version kör de? Skicka med appversion på varje händelse.

Tio välnamngivna händelser besvarar fler frågor än tvåhundra automatiska.

Integritet och samtycke

Kraschrapporter och analys läser data från användarens enhet, vilket inom EU omfattas av reglerna om elektronisk kommunikation, i Sverige lagen om elektronisk kommunikation, utöver GDPR. Data som är nödvändig för att leverera tjänsten användaren bett om får samlas in utan samtycke; kraschrapportering med minimal data anses ofta passa där. Analys för produktutveckling eller marknadsföring kräver i regel samtycke, och allt som används för annonsering eller spårning mellan appar kräver samtycke och på iOS även Apples spårningstillstånd.

Håll personuppgifter borta från kraschrapporter och händelser: inga namn, mejladresser eller fritext.
Välj lagring inom EU där verktyget erbjuder det, och teckna personuppgiftsbiträdesavtalet.
Be om samtycke till analys i appen, och respektera ett nej.
Se till att integritetsuppgifterna i appbutikerna stämmer med vad SDK:erna faktiskt samlar in.

Butikernas integritetsuppgifter går vi igenom i appintegritet, GDPR och butiksetiketter.

En veckovis hälsokoll

Andelen kraschfria användare för senaste versionen, jämfört med den förra.
Nya typer av krascher sedan förra veckan, sorterade efter antal drabbade användare.
Fel som visats för användare, särskilt vid inloggning och betalning.
Det viktigaste flödet: introduktion slutförd och kärnhandling nådd.
Nya recensioner i butikerna, lästa tillsammans med kraschdatan.

När ni inte behöver köpa hjälp: har appen få användare och en utvecklare tittar redan i Crashlytics varje vecka är ni täckta. När ingen äger frågan, eller nya releaser gång på gång ger krascher, hör det hemma i ett avtal för appunderhåll. Boka ett kort samtal så kontrollerar vi vad er app redan rapporterar.

Vanliga frågor

Gör kraschrapportering appen långsammare?

Inte märkbart. Verktygen samlar data lokalt och skickar den i bakgrunden, oftast vid nästa appstart efter en krasch.

Behövs samtycke för kraschrapportering?

Ofta inte, om datan är minimal och bara används för att hålla appen fungerande. Analys för produktbeslut eller marknadsföring kräver i regel samtycke inom EU. Dokumentera resonemanget oavsett.

Ska vi välja Firebase eller Sentry?

Båda fungerar bra. Crashlytics är gratis och vanligt för rena mobilappar; Sentry passar team som även vill ha webbfel och prestanda på ett ställe, och erbjuder lagring inom EU.

Vad är en bra andel kraschfria sessioner?

Sikta på att den absoluta majoriteten av sessionerna är kraschfria och, viktigare, att andelen håller sig stabil eller förbättras för varje release. Sjunker den efter en release, stanna och rätta.