Why measure at all
Without any information, you are guessing. You cannot tell whether people finish onboarding, whether a feature is ever used, or whether a recent update made things worse. Some measurement is genuinely useful. The risk lies in the opposite direction: collecting everything because it is easy, and then holding data you do not need, cannot protect well, and would be uncomfortable explaining.
A sensible principle is to collect the least data that answers your actual questions.
Start with questions, not with data
Before adding any analytics tool, write down what you want to know. Examples:
- Do people get through the first-run screens, or leave partway?
- Which features are used regularly, and which are never touched?
- Where do crashes and slowdowns happen?
- What operating system versions and screen sizes should I support?
Each question points to a small set of measurements. If a number would not change any decision you might make, you probably do not need to collect it.
Prefer aggregate over individual
Most product questions are about groups, not people. “Forty percent of new users reach the third step” (a made-up figure for illustration) does not require knowing who any of them are. Where you can, count events and look at totals, instead of building profiles of individuals.
Some practical habits:
- Avoid recording names, email addresses, precise location, contacts or message contents in analytics events.
- Use a random identifier that is not linked to the person’s account, or no identifier at all if you only need totals.
- Do not tie your analytics to the device’s advertising identifier unless you have a clear reason. The article on advertising identifiers and tracking on phones explains why that identifier is sensitive.
- Keep event names and properties simple, and write down what each one means.
Separate quality data from behavior data
Two kinds of data are worth distinguishing. Crash and performance information helps you repair the app, and it often needs only technical details such as the app version, the phone model and what failed. Crash reports are a good example. Behavioral data about how people move through screens is more personal, and deserves more thought. If you are unsure where to start, begin with quality data.
Be careful with third-party tools
Analytics services are code that someone else wrote, running inside your app. Before adding one, check what it collects by default, where the data goes, and whether you can turn features off. Remember that you are responsible for what you ship, including its data practices. Stores ask developers to describe data collection, including by third-party code, and your answers need to match reality. A free tool may be funded by data collection, which is something to consider when comparing options; the piece on data collected by free apps covers that reasoning from the user’s side.
Tell people plainly
Honest disclosure has two parts. First, your privacy policy should say what you collect and why, in words a person can follow. Second, where the rules of a region or platform require consent, ask for it clearly, and make declining easy and without penalty. The legal requirements vary by place and change over time, so if your app reaches a wide audience or children, it is worth getting qualified advice rather than relying on a general article.
A good test: if you read your own description of what you collect aloud to a user, would it sound reasonable? If it would sound surprising, you may be collecting too much, or explaining too little.
Limit how long you keep it
Old data is a liability. Decide in advance how long you will keep analytics data, and delete or aggregate it after that. Restrict who can see it, and keep it secured. If someone asks you to delete data associated with them, be ready to respond, which is much simpler if you avoided collecting identifying details in the first place.
Interpret with humility
Usage numbers can mislead. A feature that is rarely used may be hard to find rather than unwanted. A drop in activity might reflect a holiday, not a problem. Small user counts produce noisy results. Pair the numbers with direct feedback, which you can gather through a routine of handling user feedback and support requests, and treat figures as hints to investigate, not verdicts.
Avoid measuring for manipulation
Analytics can be used to understand users or to push them. Tracking in order to find which nudges bring people back more often, or which prompts increase spending, moves toward manipulative design. Measure so that you can make the app better for the people using it, and be wary of metrics that reward time spent over value gained. The article on ethical app design looks at this tension more broadly.
A minimal starting setup
For a small app, a reasonable first step is:
- A crash reporting tool configured to avoid personal data.
- A handful of counted events for key steps, such as completing onboarding.
- The store’s own built-in reports, which already show installs and some device information.
- A clear paragraph in your privacy policy.
That is often enough to guide the next few releases, and it keeps your promises about privacy easy to keep.