A Minimal Event Taxonomy for Mobile App Publishers (Activation → Retention → Revenue)

If you publish multiple apps, analytics tends to drift: every app ships a different event set, naming changes over time, and dashboards become impossible to compare. The result is portfolio blindness—you can’t answer basic questions like “Which apps have healthy activation?” or “Are trial users churning earlier this month?”

This post proposes a minimal event taxonomy Fluxer Labs uses as a baseline across apps. The goal is not “track everything”. The goal is to track the smallest set of events that let you measure:

• Activation (did users reach first value?)
• Retention (do they come back and keep using it?)
• Revenue health (are subscriptions and purchases behaving normally?)

The rule: track outcomes, not UI clicks

Avoid per-screen “button tapped” noise unless it’s required for diagnosis. Prefer events that represent user progress.

Good event taxonomy principles:

• stable over time (survives UI redesigns)
• comparable across apps (portfolio-level dashboards work)
• privacy-aware (no sensitive content in event props)

The minimal event set (publisher baseline)

Here is a compact event set that works for most consumer apps (utilities, productivity, content, or simple tools).

| Goal | Event name | When to fire | Required properties | |---|---|---|---| | Install quality | app_open | first session + subsequent opens | app_version, platform | | Activation | value_moment | first time user reaches the main “aha” | value_type | | Funnel health | onboarding_completed | onboarding ends (success) | onboarding_variant | | Engagement | session_end | session finishes | duration_sec | | Retention proxy | key_action | primary repeatable action | action_type | | Monetization | paywall_viewed | paywall shown | paywall_id, trigger | | Monetization | purchase_started | user begins purchase flow | product_id, price_tier | | Monetization | purchase_completed | purchase success | product_id, revenue_usd | | Monetization | trial_started | subscription trial begins | product_id, trial_days | | Monetization | subscription_renewed | renewal succeeds | product_id, period | | Monetization risk | subscription_canceled | user cancels (or auto-renew off) | product_id, reason (optional) |

Notes:

• value_moment is the most important portfolio metric. Define it per app, but keep the event name constant.
• key_action is your repeat usage pulse. It should happen naturally in “healthy” users.

Define activation in one sentence per app

Write the activation definition as a contract:

A user is “activated” when they [do X] within [time window] of install.

Examples:

• timer app: “start a timer and complete at least one interval”
• scanner app: “scan a document and export/share it”
• language app: “finish one lesson”

You can encode the time window in analysis (cohorts), not necessarily in the event itself.

Naming conventions that prevent chaos

Keep event names:

• snake_case
• verbs only when it represents a user outcome (purchase_completed, not paywall_button_clicked)
• consistent across iOS + Android

Keep properties:

• low cardinality where possible (price_tier: "monthly" | "yearly")
• versioned when you must change semantics (paywall_id: "v3_primary")

Portfolio dashboards you get “for free”

Once every app shares the same baseline events, you can run portfolio-wide dashboards like:

• Activation rate: % users with value_moment within 24h
• D1/D7 retention for activated vs non-activated cohorts
• Paywall view rate and purchase conversion
• Trial start rate and early cancel rate

If you only build one dashboard, make it Activation → D7 retention → Trial start. It catches most publisher problems early.

Common pitfalls (and how to avoid them)

• Multiple activation events: pick one value_moment per app; keep it stable.
• Tracking sensitive content: don’t send document text, user-generated content, contacts, or precise location.
• Mixing revenue sources: subscriptions vs consumables should be separated via product_id + product_type.
• No QA loop: add a debug build screen that shows “last 20 events fired” so you can validate quickly.

Privacy note: minimize identifiers

For most publisher analytics, you do not need raw PII. Prefer:

• anonymous user IDs (resettable)
• coarse properties (country tier, platform, app_version)
• server-side aggregation for monetization reporting when possible

If you operate in regulated contexts or collect sensitive data, review your telemetry choices with your privacy policy and platform requirements.

Conclusion

A minimal event taxonomy turns analytics into a portfolio asset. You’ll ship faster, compare apps reliably, and spot retention/subscription issues before ratings and revenue drift.

Start with the baseline above, define value_moment per app, and keep everything else stable.

---

This note is part of the Fluxer Labs product and app publishing archive.