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.
| Event | Trigger | Allowed properties | Decision supported | Review rule |
|---|---|---|---|---|
| onboarding_completed | The final onboarding step succeeds | entry_path, optional_choices | Find where the introduction needs clarification | Product owner confirms every property is necessary |
| practice_session_completed | A submitted session receives a result | topic, completion_status | Compare completion across study modes | Exclude answers, names and free-form text |
| purchase_failed | The store returns a handled failure state | store, product_type, error_category | Prioritise purchase-flow fixes | Keep diagnostic details in the operational system |
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.
Primary references
Store requirements change. These official sources should be checked again before a release decision.