Mobile analytics with less data and clearer purpose

Measurement begins with a decision

“Track everything” is not an analytics plan. Start with decisions the team expects to make: whether onboarding is understandable, which study mode helps a learner return, where a purchase flow fails or which release caused a stability change.

For each decision, write the minimum signal needed. If nobody can explain how an event would change the roadmap, remove it. Fewer events are easier to name, test, document and delete.

Create an event contract

An event contract records the event name, trigger, properties, purpose, owner and expected retention. It should also prohibit fields that can accidentally carry free-form personal information. A contract turns analytics from scattered logging into a reviewed product interface.

Use stable nouns and completed actions. “practice_session_completed” is easier to interpret than a stream of screen views. Add context only when it answers a real question, such as content category or completion status.

• Never place email addresses, names, message text or authentication tokens in event properties.
• Separate operational crash data from product-behaviour analytics.
• Define deletion and retention behaviour before the first production event.

Map every SDK to its data path

A privacy inventory should include first-party code and every third-party SDK. Record which data leaves the device, the destination, purpose, configuration controls and whether the provider acts for analytics, advertising, diagnostics or another function.

Review the runtime application, not only the dependency list. Some SDKs change behaviour when a feature or advertising option is enabled. Network inspection and platform privacy reports can help confirm what is actually sent.

Ask at the moment the choice makes sense

A permission or consent dialog should follow an explanation of the user benefit. Asking at first launch, before context exists, often produces a choice based on uncertainty. Delay optional analytics or advertising storage until the appropriate choice has been recorded where required.

Design a path for changing the choice later. Consent is an ongoing state, not a one-time screen. The application should continue to provide its core value when optional measurement is declined.

Keep policy, store answers and code in sync

App Store privacy information, Google Play Data safety answers, in-app notices and the public privacy policy describe the same system to different audiences. Maintain them from one data inventory and review all of them when an SDK, event or purpose changes.

A generic privacy template cannot prove what a particular build does. Name data categories and purposes plainly, describe retention and deletion, and make support contact information current.

Test analytics like product code

Create test cases for event triggers, prohibited fields, duplicate delivery, consent states and deletion. Validate a clean install and an upgrade because identifiers and preferences may migrate differently.

Finally, schedule a periodic audit. An event catalogue that is never removed grows into a historical record nobody can confidently explain.

Worked example: answer a completion question without logging answers

Suppose a hypothetical learning app needs to know whether learners abandon short sessions more often than long sessions. The decision is whether to change session length. It does not require the learner’s name, exact answers, date of birth or an unrestricted transcript of interaction. This example describes an event design, not the data practices of a particular released app.

Define the denominator before collecting the completion event. Record a session start and a session completion with the same permitted length bucket and content category. Specify whether an interrupted session resumed the next day counts against its original start cohort. Without that rule, a daily chart can show completions that belong to yesterday’s starts and suggest a false change in behavior.

Use a bounded schema: session_length_bucket accepts short or long; content_category comes from a reviewed list; completion_status accepts completed or abandoned only when the product can establish that state. Avoid labeling an app close as abandonment immediately. The learner may return later, and background termination may never deliver a final event.

If deduplication is needed, define the narrow purpose and lifetime of a session token, and check the analytics provider’s own identifiers. Removing an email field does not make telemetry anonymous when the SDK still attaches device or account identifiers. Document those provider fields separately and assess the complete payload leaving the device.

Test collection with optional measurement declined as well as accepted. Inspect network requests after a clean install, a preference change, offline buffering and an upgrade. A screen that says tracking is off is insufficient evidence if queued events are still sent. Keep raw diagnostic payloads out of product dashboards and give every retained dataset a concrete deletion rule and an accountable owner.