Note 04 · Product analytics
The first events your mobile app should track
Follow through on the tap.
Start with the questions you need to answer. Define a small set of events for reaching value, returning to it, and paying for it. Check that each event means what its name promises.
Write the question before the event.
A tracking plan earns its place when it changes a decision. Start with three questions: do new users reach the useful part of the app, do they come back to it, and where does the path to payment break?
For a voice-notes app, opening the recorder tells you less than successfully saving a usable note. For a language app, opening a lesson tells you less than completing a practice session. Pick the action that represents the promised benefit, then measure how many new users reach it within a defined window.
Call that your initial activation hypothesis. Later, check whether people who complete it actually return. A convenient event is not automatically a good definition of value.
Give every event a precise meaning.
The following are illustrative event names, not a universal SDK schema. Map them to your provider’s recommended events when an equivalent exists. Firebase’s event guide, for example, distinguishes automatically collected, recommended, and custom events.
- onboarding_completed
- The required setup is finished. Record the onboarding version, so different flows remain distinguishable.
- core_action_completed
- The useful task succeeded. Record the action type and outcome, rather than counting a button tap as success.
- paywall_viewed
- A specific paywall was actually displayed. Include the variant and entry point, not just a generic screen name.
- trial_started
- A trial was confirmed by the purchase system. Keep plan and offer information so unlike trials are not mixed.
- purchase_confirmed
- A transaction was confirmed. Distinguish initial payments, renewals, and restores; a restore is not new revenue.
For each event, document its trigger, properties, identity rules, and owner. Use stable identifiers where needed for deduplication. Avoid placing note contents, email addresses, or other unnecessary personal information into event properties.
Keep intent separate from the outcome.
A purchase-button tap means someone tried to pay. It does not tell you whether they completed checkout, cancelled, or encountered an error. Keep those steps distinct.
Use confirmed store or billing records to reconcile money. A client event stream alone may miss renewals, refunds, or events that occurred while the app was closed. Agree on which system owns each financial fact and how duplicate transaction notifications are handled.
Then define a funnel using the same eligible users and explicit windows. Our paywall conversion note shows why dividing by viewers and dividing by trial starters answer different questions.
Test the journey, including the awkward parts.
- Complete one fresh-install journey and inspect each event and property.
- Repeat it with a cancelled checkout, a retry, and an interrupted connection.
- Check that reopening a screen does not create a second successful purchase.
- Test a restore and confirm that it grants access without counting new revenue.
- Compare a small set of known transactions with the resulting report.
Firebase DebugView provides near-real-time visibility into development-device events. Use the equivalent debugging tools in your stack, then verify the aggregated report too: an event arriving correctly does not guarantee that the report’s filters are correct.
Sources & further reading
Examples are hypothetical. They illustrate the method and do not represent Piiko results or industry benchmarks.