App Analytics That Respect Users

There are two failure modes in app analytics. The first is flying blind: shipping features for months with no idea whether anyone uses them, making roadmap decisions from gut feel and the loudest review. The second is the default fix for the first — bolting on an SDK that hoovers up everything, auto-captures every tap, and phones home with data you couldn't enumerate if a user asked. The second failure mode is worse: it buries the few numbers that matter under thousands that don't, it creates privacy and compliance debt that compounds quietly, and users increasingly notice and resent it — the platform privacy labels have made "what this app collects" a public fact rather than a secret.

The good news, which took me a while to believe: the respectful version is also the more useful version. Restraint isn't the tax you pay for ethics; it's what makes the dashboard readable.

Start from decisions, not from data

The test for whether something deserves tracking isn't "might this be interesting?" — almost everything might be interesting, which is why "interesting" is a useless filter. The test is "what decision would this number change?"

A small app genuinely needs to answer only a handful of questions. Do people come back after the first day, and the first week? Which core features get used, and which are dead weight worth cutting? Where do people abandon the one flow that matters — onboarding, checkout, first sync? Did the latest release break or improve any of that? That's roughly it. Everything else is curiosity wearing a business-intelligence costume.

Each question maps to a small set of events. In practice, an app with fifteen well-chosen events produces better decisions than one with five hundred auto-captured ones, for the simple reason that someone actually looks at fifteen. Write the event list down before touching an SDK — each event's name, when it fires, what properties it carries — and treat it like an API contract, reviewed when it changes. Analytics rot comes from events added ad hoc by whoever was in the file that week, until the data means nothing and nobody remembers why screen_view_v2_final exists alongside screen_view_new.

The event contract has a second payoff you'll appreciate later: it is your privacy documentation. Store declarations, policy updates, and "what do you collect?" support emails all get answered by one small file.

What not to collect

The respectful line is simpler than the compliance industry makes it sound: track what people do with your features, not who they are or what they wrote.

Concretely, that means feature-level events — export_pdf_tapped, budget_created, search_used — and never the content: not the note's text, not the search query, not the budget's amounts. In a budget app, "user created an expense" is product analytics; the amount and description are the user's private financial life, and there is no roadmap decision that needs them. The same boundary rules out fine-grained behavior capture (keystrokes, session replay) for a consumer app, and identifiers designed to follow users across other companies' apps. Screen-view counts are fine; a replayable recording of someone's evening is not.

This isn't only ethics — it's engineering hygiene with teeth. Data you don't collect can't leak, can't be breached, can't be subpoenaed, doesn't need a retention policy, a deletion pipeline, or a paragraph in your privacy label. Every field you decline to collect is risk that simply doesn't exist. The cheapest data protection ever invented is absence.

Two practical upgrades that cost almost nothing: aggregate where you can — you need how many users hit the paywall this week, almost never which ones — and keep raw events for a bounded window. After ninety days, the trends have been extracted and the individual rows are pure liability; let them expire.

Crash reporting is different — and diagnostics still deserve care

Users broadly expect apps to phone home when they crash; fixing bugs is so obviously in everyone's interest that crash reporting is the one category of telemetry I'd call non-negotiable — shipping without it means your crash rate is whatever your angriest reviews say it is.

But "diagnostics" is also where surveillance most often sneaks in dressed as engineering. Breadcrumb trails that log every screen transition with full parameters, "context" attachments that bundle user content into the report, logs that were never scrubbed — each added by a well-meaning developer debugging one incident, each now a standing collection of things you promised not to collect. Apply the same decision test: a stack trace, OS version, and device model change what you fix this week; the user's document attached to the report does not. Configure the crash SDK's data collection deliberately — they're all configurable, and their defaults are not your privacy policy.

Be honest in the store and in the app

Both stores now require privacy declarations — Apple's privacy "nutrition labels" and Google's Data safety section — and they must match what your app including its SDKs actually does. That last clause is where apps get burned: a third-party SDK's collection is your declaration, including the behaviors buried in its documentation that you didn't read. Fill the forms in from your event contract and your dependencies' actual behavior, not from optimism; mismatches surface in store review or, worse, in press.

Beyond compliance, the trust move is a privacy policy a human can read — "we count how often features are used; we never see your notes" is one sentence and worth more than ten pages of boilerplate — and, where practical, an analytics opt-out toggle in settings. Almost nobody flips the toggle; its value is what its existence says about how you operate. For simple counters, on-device analytics deserve a look too: computing "used feature X this week" locally and syncing only the aggregate is often all the product insight you needed, with nothing personal ever leaving the phone.

If you serve EEA/UK users, consent requirements add a layer on top of all this — but note how much smaller that problem becomes when the data is feature counts instead of behavioral profiles. Restraint simplifies compliance too.

The takeaway

Decide what questions you actually need answered, write a small event contract, track feature usage but never content, keep crash reporting configured with the same restraint, bound your retention, and declare all of it honestly in both stores. You end up with a dashboard you actually read, a privacy story you could tell to a user's face without flinching, and one less category of risk on your books. Respectful analytics isn't a constraint on understanding your app — it's how you get an understanding worth having, from users who'd nod along if they saw how it works.