Crash Reporting and App Analytics Basics

Why crashes go unreported

A crash is a bad moment for the user, and reporting it is effort they have no reason to make. Many crashes happen only on certain devices, operating system versions or network conditions you never tested, so they never show up in your own use. Some failures are not even crashes: a screen that freezes, a payment that silently fails, a login loop. Without data, these look like users losing interest.

The app stores do show some crash and performance data, in App Store Connect and Google Play Console, and Google Play weighs stability in how it presents apps. That data is useful as a check, but it arrives late and lacks the detail a developer needs.

Crash reporting tools

Whichever you choose, three things decide whether the reports are useful. Upload debug symbols or source maps with every release, or the stack traces are unreadable. Tag each report with the app version, so you can see whether a fix worked. And add breadcrumbs, a short log of what the user did before the crash, without personal data such as names or messages.

A small analytics event plan

Analytics goes wrong when teams track everything and read nothing. Start from the questions you need answered, then define only the events that answer them. Write the plan down: event name, when it fires, and which properties it carries.

1. Do new users complete onboarding? Track onboarding started and completed.
2. Do they reach the core action? Track the one action that defines value, such as booking made or order placed.
3. Where do they fail? Track errors shown to users, such as payment failed or login failed.
4. Do they come back? Use the tool's retention view based on app opens.
5. Which version are they on? Attach app version to every event.

Ten well-named events answer more questions than two hundred automatic ones.

Privacy and consent

Crash reports and analytics read data from the user's device, which in the EU falls under the ePrivacy rules as well as GDPR. Data that is strictly necessary to provide the service the user asked for may be collected without consent; crash reporting with minimal data is often argued to fit there. Analytics for product improvement or marketing generally needs consent, and anything used for advertising or cross-app tracking needs consent plus, on iOS, Apple's tracking permission.

• Keep personal data out of crash reports and events: no names, emails or free text.
• Choose EU data hosting where the tool offers it, and sign the data processing agreement.
• Ask for analytics consent in the app, and respect a no.
• Make sure the store privacy labels match what the SDKs actually collect.

The store labels are covered in detail in app privacy, GDPR and store labels.

A weekly health check

1. Crash-free users for the latest version, compared with the previous one.
2. New crash types since last week, sorted by number of users affected.
3. Errors shown to users, especially in login and payment.
4. The key funnel: onboarding completed and core action reached.
5. New store reviews, read alongside the crash data.

When not to buy help: if your app has few users and a developer already looks at Crashlytics every week, you are covered. When nobody owns this, or releases keep introducing crashes, it belongs in an app maintenance plan. Book a short call and we will check what your app is already reporting.

Frequently asked questions