A tracking plan is a shared document listing every analytics event your app sends, its properties, when it fires and why it matters. Start from the questions you need answered: activation, retention, conversion and revenue. Use one consistent naming convention, track a small set of meaningful events well, document privacy considerations, and test events before each release.
Why a tracking plan matters
Without a plan, events multiply with inconsistent names and missing properties, making data hard to trust. A plan keeps product, marketing and engineering aligned.
Reliable data is the basis for every decision in ASO KPIs.
Start from questions
List the questions you need to answer: where do users drop in onboarding, which features predict retention, which channels bring paying users? Each event should help answer one.
Avoid tracking everything just in case.
Core events
Most apps need events for app open, sign-up, onboarding steps, the activation action, key feature usage, paywall view, trial start, purchase, subscription renewal and cancellation.
See app activation for defining the activation event.
Properties
Properties add context: plan type, price, content category, screen, source. Define allowed values so reports stay clean.
User properties such as country, platform and acquisition channel enable segmentation.
Naming conventions
Choose one style, such as object and action in past tense (“workout completed”, “subscription started”), and apply it everywhere. Inconsistent names are the most common analytics problem.
Document the convention at the top of the plan.
Funnels
Define the funnels you will watch: store visit to install (from store analytics), install to activation, activation to paid. Each step should map to an event.
See app store connect analytics for the store side.
Connecting store and in-app data
Store analytics show impressions, page views and installs; in-app analytics show behaviour after install. Attribution connects them by channel and campaign.
See mobile measurement partners.
Privacy
Track only what you need, avoid sending personal data in event properties, respect consent, and reflect tracking in privacy labels and policies.
See privacy labels and data safety and ATT.
QA before releases
Test new and changed events on test devices before release, checking names, properties and timing. Broken tracking discovered weeks later leaves gaps you cannot fill.
Add analytics checks to your release checklist.
Ownership
Assign an owner for the plan who approves new events. This prevents duplicate and inconsistent tracking.
Review the plan quarterly and remove unused events.
Tools
Product analytics tools, attribution platforms and data warehouses each play a role. Choose tools that fit your team size.
See app analytics tools compared.
Common mistakes
Common mistakes include tracking too many events, inconsistent naming, missing properties, sending personal data, and no QA.
Another is tracking without a question to answer.
A simple template
For each event: name, description, trigger, properties with allowed values, platforms, owner, and the question it answers.
Keep it in a shared spreadsheet or tracking tool.
Event examples by app type
A fitness app might track workout started, workout completed and plan created. A marketplace might track listing viewed, message sent and order placed. A subscription app should track paywall viewed, trial started and subscription renewed.
Each set focuses on the actions that show users getting value.
Identifying users
Decide how to identify users across sessions and devices, such as an internal user ID after sign-in, while respecting privacy. Consistent identity makes retention and LTV analysis accurate.
Avoid using emails or phone numbers as identifiers in analytics tools.
Server-side events
Some events, such as subscription renewals and refunds, happen on the server or store side. Send them from your backend so revenue data is complete.
See involuntary churn for subscription states.
Dashboards
Build a small set of dashboards: acquisition and store funnel, activation, retention, monetization. Each should answer a recurring question.
See ASO reporting dashboard setup.
Documenting changes
Log every change to events with the date and app version. When numbers shift, you can tell whether behaviour changed or tracking did.
This log saves hours of confusion later.
A worked example: fixing messy tracking
A meditation app finds three different events for the same session start, created by different developers. It writes a tracking plan, merges them into one event with a source property, and adds QA to releases.
Retention reports become consistent, and the team finally sees which sessions predict subscriptions.
Key takeaways
Start from questions, track a focused set of core events with consistent names and defined properties, connect store and in-app data, protect privacy, test every release and keep one owner for the plan.
Questions to ask your team
Which decisions did analytics change last month? Which reports do people not trust? Which events are never used? Who approves new events?
The answers show where the tracking plan needs work.
Tracking plans for small teams
Small teams can start with ten to fifteen events covering sign-up, activation, key features, paywall and purchase, in a simple shared spreadsheet. Add events only when a new question needs answering.
Starting small keeps data clean and makes the plan easy to maintain as the app and team grow, and saves engineering time on events nobody reads.
Analytics and store experiments
Store A/B tests change who installs. Track whether users from a winning screenshot variant activate and retain as well as before, using install date and campaign properties. Review it after every major store test, alongside retention cohorts.
This confirms that higher conversion brings the right users, not just more users.
How to do it, step by step
- List key questionsActivation, retention, conversion, revenue.
- Define core eventsMap each to a question.
- Set naming and propertiesOne convention with allowed values.
- Document privacyTrack only what you need.
- QA every releaseTest events before shipping.
Before and after examples
Illustrative examples written for a generic app in this category, not client results. Swap in your own product, audience, and data.
btnClick1, purchase_done, SubStart.
button tapped, purchase completed, subscription started.
Why it works: Consistency makes data usable.
Free-text plan names.
plan: monthly | yearly | lifetime.
Why it works: Allowed values keep reports clean.
200 events.
30 well-defined events.
Why it works: Fewer, better events.
Action plan
- Start from questions
- Track core events
- Use one naming convention
- Define properties
- Protect privacy
- QA and review
Metrics to monitor
- Event coverage of key funnels
- Tracking errors per release
- Activation rate
- Conversion by step
- Data freshness
Record the baseline, release date, audience, markets, and external changes before interpreting movement. Rankings and conversion are useful signals, but a decision is stronger when activation, retention, and business value confirm that the page attracted the right users.
Frequently asked questions
What is an analytics tracking plan?
A document listing every event an app tracks, with properties, triggers and purpose.
Which events should an app track?
Sign-up, onboarding steps, activation, key features, paywall, purchases and cancellations.
What naming convention should I use?
Any consistent one, such as object plus past-tense action.
Should I track personal data?
Avoid sending personal data in events and respect consent rules.
How do store analytics fit in?
They cover the funnel before install; attribution connects them to in-app data.
How often should I update the plan?
Whenever features change, with a quarterly cleanup.
Keep reading
More in Strategy and Operations
Browse all 25 Strategy and Operations guides
