The Mobile App Event Taxonomy Subscription Teams Should Start With
Use this mobile app event taxonomy for onboarding, paywalls, purchases, subscriptions, errors, and retention-ready analytics dashboards.
Give developers a concrete event naming system for subscription apps.
Summary
A starter event taxonomy that keeps mobile analytics useful, consistent, and privacy-safe across iOS and Android apps.
Use Namespace.action names so events stay readable.
Track lifecycle events before adding custom product events.
Keep payloads flat and safe so dashboards can aggregate them.
Why a small taxonomy wins
The best first analytics taxonomy is boring. It uses predictable event names, a short list of safe payload keys, and the same semantics across iOS and Android. This makes dashboards work earlier and prevents the team from debating event names after every release.
A subscription app should start with lifecycle, onboarding, paywall, purchase, subscription, and error events. Custom feature events can come later, after the team knows which product questions are still unanswered.
- Lifecycle: App.launch and Session.started.
- Onboarding: Onboarding.started, Onboarding.stepViewed, Onboarding.completed.
- Revenue: Paywall.viewed, Purchase.started, Purchase.completed, Subscription.renewed.
Payload fields to standardize
A useful event is not only its name. Paywall.viewed should include plan, source, placement, and variant. Purchase.completed should include productId, plan, currency, and revenue amount. Error.occurred should include a safe error code and app version.
Avoid payload keys that invite personal data. Keys like email, phone, name, ip, location, deviceId, idfa, and gaid should be blocked or rejected before storage.
How this taxonomy maps to dashboards
App.launch builds activity and retention readiness. Onboarding events build activation funnels. Paywall and purchase events build conversion and revenue views. Subscription events build renewal, trial, refund, cancellation, and billing retry reporting.
This mapping is what keeps instrumentation focused. If an event does not improve a dashboard, alert, or privacy review, it should probably wait.
Implementation checklist
How to apply this mobile app event taxonomy guide
Treat this article as an instrumentation brief before adding or changing analytics code. The goal is not to send more events. The goal is to make every event answer a specific product, revenue, privacy, or debugging question for your app team.
Define the decision first
Write down the decision this instrumentation work should support. Good examples are whether onboarding is leaking users, whether a paywall variant changes purchase intent, or whether a provider webhook is missing subscription lifecycle events.
Map the smallest event set
Choose the fewest event names and payload fields that answer the decision. Prefer stable names such as App.launch, Paywall.viewed, Purchase.completed, Subscription.renewed, and Error.occurred over ad hoc labels that only one release understands.
Verify in test mode
Send events from a debug build first, inspect the live event stream, and confirm that environment, platform, app version, product ID, paywall variant, and revenue fields appear where expected before counting the data in production dashboards.
Run a privacy pass
Review every payload key before launch. Remove email addresses, names, advertising IDs, phone numbers, precise location, free-form user text, raw payment tokens, and other fields that make analytics harder to defend during an app privacy review.
In AppMetricsKit, the safest workflow is to create an ingest key, install the iOS or Android SDK in test mode, send the first event, review Live Events, then promote the same taxonomy to production. After events are stable, connect RevenueCat, Adapty, Superwall, or server-side sources so subscription changes that happen outside the app are reconciled with client events.
Revisit this checklist whenever a new paywall, onboarding step, plan, trial offer, release channel, or data export is introduced. Most analytics quality problems come from small schema changes that were never reviewed, not from the dashboard itself.
FAQ
Common questions
How many analytics events should a new app start with?
Most subscription apps can start with 10 to 15 events covering launch, onboarding, paywall, purchase, subscription, and errors.
Should event names be different on iOS and Android?
No. Use the same event names on both platforms so cross-platform dashboards and funnels stay comparable.