App Analytics: What to Track Without Becoming Invasive
A client came to us with an existing app logging over 400 distinct analytics events, most of which nobody on the product team could explain the purpose of. Before adding anything new, we did an audit and cut it to around 60 events tied to specific product questions the team actually wanted answered — funnel steps, feature adoption, error rates — rather than logging everything that seemed potentially useful someday.
We draw a hard line between behavioral analytics and anything that resembles surveillance. Session duration, screen views, and button taps are fair game; we avoid logging free-text input content, exact GPS coordinates when a coarser radius answers the product question, or scroll depth on sensitive content like a mental health app's journal entries, even in aggregate, because the privacy risk outweighs the marginal product insight.
App Tracking Transparency on iOS and Android's more recent privacy sandbox changes forced a real architectural split: analytics needed for the product to function — crash reporting, core funnel metrics — run regardless of ATT consent using anonymized, non-cross-app identifiers, while anything used for ad attribution or cross-app tracking is gated properly behind the consent prompt and simply doesn't fire if declined.
On-device aggregation is underused. For a step-counting feature, we didn't need raw per-second accelerometer data on our servers — we computed the daily step count on-device and only synced the aggregate, which reduced both our data liability and the bandwidth cost, while still answering every product question the client actually had.
The practical test we now apply to any new event before it ships: can someone on the team state, in one sentence, the decision this data will inform? If not, it doesn't go in. That discipline has kept dashboards usable and kept privacy reviews, increasingly required for App Store and Play Store data-safety labels, from turning into multi-week audits after the fact.
