Measuring a Mobile App: Analytics, Crash Reports and Privacy

Decide what you need to know

Start with questions, not tools. For most business apps they are simple: do people finish signing up, do they complete the main task (an order, a booking, a report), where do they give up, do they come back, and does the app crash. Write down the handful of actions that answer those questions, and what counts as success for each. Every extra data point you collect has to be declared to the stores and covered in your privacy policy, so collecting less is easier as well as more respectful. If sign-up completion is one of your questions, our app onboarding guide covers how to design that first run.

Analytics events

Mobile analytics works with events: named actions such as a completed sign-up or purchase, often with a few details attached. Google Analytics for Firebase is a common choice and works much like Google Analytics 4 on a website; see our Google Analytics 4 guide for the web side. Its events documentation says that Analytics "automatically logs some events for you", that an app can log up to 500 different event types, and that there is no limit on the total volume of events. It also notes that event names are case-sensitive, so two names that differ only in capitals count as two different events.

• Use recommended events where they fit. Firebase defines recommended events for common app types such as retail, travel and games, and says using them gives the most detail in reports.
• Keep a written event plan: each event's name, when it fires and what details it carries. Agree it before development, and keep names consistent between iPhone and Android.
• Keep personal data out of events. Names, email addresses and phone numbers do not belong in event details.
• Test before release and check that events arrive once, not twice.

Crash reports and stability

Crash reporting tells you when the app fails on real devices, which test devices will never fully cover. Firebase Crashlytics, for example, describes itself as a "lightweight, realtime crash reporter" for Apple, Android, Flutter and Unity apps that groups crashes and highlights the circumstances leading up to them. Other crash reporting services work in a similar way.

On Android, stability also affects how Google Play treats the app. The Android vitals documentation says the core vitals, which include the user-perceived crash rate and the user-perceived ANR (app not responding) rate, "affect your app's visibility on Google Play", with bad behaviour thresholds both overall and per device. They are shown in Play Console. Our guide to mobile app maintenance covers keeping an app healthy after launch.

• Set up crash reporting before the first public release, not after the first bad review.
• Upload the files your crash tool needs to show readable reports, as its documentation describes.
• Review crashes after each release and fix the ones affecting the most people first.

Consent and turning collection off

Depending on where your users are and what you collect, you may need consent before analytics starts, as with cookies on a website; our privacy policy and cookie consent guide explains the general rules. Your tools should let you wait. Firebase's page on configuring Analytics data collection describes disabling collection "to get end-user consent before collecting data" through a setting in the app, then switching it on once the person agrees, and switching it off again later if needed. It names Google's consent mode as the recommended way to turn personalised advertising on and off.

Whatever you choose, give people a way to change their choice later from the app's settings, and make sure the app works the same either way.

Tracking and Apple's App Tracking Transparency

Apple's User Privacy and Data Use page says that from iOS 14.5 an app needs the user's permission through the App Tracking Transparency (ATT) framework "in order to track them or access their device's advertising identifier". Apple defines tracking as linking user or device data from your app with data from other companies' apps, websites or offline properties for targeted advertising or advertising measurement, or sharing it with data brokers.

• Third-party code counts. Apple's examples include an analytics SDK that reuses the data it collects from your app to target ads in other developers' apps, "even if you don't use the SDK for these purposes".
• Without permission, the advertising identifier is all zeros and you may not track the person.
• The prompt needs a purpose string explaining why you want to track. The ATT framework documentation lists the key for it in the app's settings.
• In the EU, Apple says that from iOS and iPadOS 27.2 developers can use an alternative version of the prompt, which is the only version available in Germany, France, Italy, Poland and Romania, and that users in the EU can be asked again one year after their previous choice. The rules on when permission is needed stay the same.

Plenty of apps do not track in Apple's sense at all: first-party analytics used only to improve your own app is not tracking under that definition. If you do not track, you do not show the prompt. If you advertise or use ad networks, check each SDK's behaviour before deciding.

Privacy labels, manifests and Data safety

Both stores show what an app collects on its listing, based on what you declare:

• App Store privacy labels. Apple's App privacy details page says the information is required to submit new apps and updates, must include the practices of third-party partners whose code you integrate, and must be kept accurate and up to date. Its data types include crash data and performance data, and its purposes include analytics and app functionality.
• Privacy manifests. Apple's privacy manifest documentation describes a file in the app and in third-party SDKs that records the types of data collected and the "required reasons" APIs used. Apple says Xcode combines these manifests into one report to help you write accurate labels.
• Google Play Data safety. Android's guide to declaring your app's data use explains that the Play Console Data safety form is where you tell users which data your app collects and shares, and that if a third-party SDK or library collects or shares user data, "you must reflect this collection and sharing in the Data safety form".

Adding an analytics or crash SDK therefore means updating the labels, the Data safety form and your privacy policy together. Our guide to publishing to the App Store and Google Play covers the rest of the store submission.

Checklist

• A short list of questions the data must answer, and the events that answer them.
• A written event plan with consistent names on iPhone and Android, and no personal data in events.
• Crash reporting live from the first release; crashes reviewed after each update.
• Android vitals checked in Play Console.
• Collection waits for consent where needed, and people can change their choice in the app.
• A decision on whether the app or any SDK tracks in Apple's sense; ATT prompt and purpose string only if it does.
• App Store privacy labels, privacy manifests, the Play Data safety form and the privacy policy all match what the app and its SDKs collect.

If you also send notifications, our guide to push notifications in mobile apps covers the permission and the rules for them.

Frequently asked questions

What should I measure in a mobile app?

Start with a few questions: do people finish signing up, do they complete the main task, where do they give up, do they come back, and does the app crash. Log the events that answer those, and set up crash reporting from the first release.

Do I need the App Tracking Transparency prompt for analytics?

Only if the app tracks in Apple's sense: linking data from your app with other companies' apps, websites or offline data for targeted advertising or advertising measurement, or sharing it with data brokers. Apple's examples include an analytics SDK that reuses your app's data to target ads elsewhere, so check each SDK.

Do analytics and crash SDKs need to be declared to the stores?

Yes. Apple requires your App Store privacy details to include the practices of third-party code in your app, and Android's guidance says that data collected or shared by a third-party SDK must be reflected in the Play Data safety form.

Can I wait for consent before collecting analytics?

Yes. Firebase documents a setting that keeps Analytics collection off until you switch it on in code, for example after the person agrees, and lets you switch it off again later.

Why do crashes matter for Google Play?

Android's documentation says core vitals, including the user-perceived crash rate and ANR rate, affect an app's visibility on Google Play, with bad behaviour thresholds overall and per device.

Building or looking after an app and want clear numbers from it? See how we approach mobile app development, see all our services, or email info@creahive.com.