Six months in, you sit down with the coffee and the CEO's Monday-morning question: why do users churn at the paywall? You open the dashboard. It shows three events — paywall_view, paywall_shown, and paywallImpression — each firing from a different screen file, none of them lining up across iOS and Android, half of them firing twice. The funnel is unaskable. The reason is not the vendor and not the engineer. The reason is that nobody spent the two hours in week one on mobile analytics event naming, and every rename now costs a dashboard rebuild.
This piece is a drill-down into one area of the eight-area mobile app architecture map — mobile analytics event naming, and only that area. If you want the full map first, start with mobile app architecture for founders; this article is the deep-dive that section 3 of that pillar forward-references. The sibling deep-dive on another day-one discipline is payment provider abstraction from day one; the same "one file, one convention, enforced everywhere" pattern applies to both.
1. What a mobile analytics event naming discipline actually is
A mobile app analytics event taxonomy is one file. Usually called analytics_events.ts, analytics_events.dart, or AnalyticsEvent.swift — the name does not matter. What matters is that this file declares every event the app will ever fire as a typed named constant, and no other file in the codebase invents an event string inline. Every track(...) or logEvent(...) call imports its event name from this file. That is the invariant. Break it in one screen and you have started accruing rename tax.
How many analytics events mobile mvp needs is a smaller number than most founders expect. Ten to fifteen. The MVP-shaped set looks something like install, sign_up_start, sign_up_complete, first_key_feature_use, paywall_shown, paywall_accepted, subscription_started, subscription_renewed, subscription_cancelled, and retention_day_7. More than fifteen and you cannot hold the funnel in your head; fewer than eight and you cannot see between the steps. The count is a discipline, not a limit.
The event naming convention mobile app teams pick matters less than that a convention exists and is enforced. Snake case, verb-noun order, past-tense: pick one, write it in a comment at the top of the file, and reject the pull request that violates it. paywall_shown beats showedPaywall — but showedPaywall used consistently across every event beats paywall_shown mixed with paywallImpression and PaywallView. Consistency is the discipline; the exact convention is folklore.
The other half of the file is the analytics events schema mobile mvp will be reasoning about a year from now. The event paywall_shown is not just a name — it carries paywall_variant, product_id, and entry_point. Those three properties are declared alongside the event constant with types, and any call site that tracks the event without them is a compile error. This is the event properties naming mobile analytics half of the discipline that the "just track a bunch of events" pitch skips. Without paywall_variant, "which paywall converted better?" is unanswerable, no matter which vendor you pay.
Written together, the file is the analytics events single source of truth for the whole app. Ten to fifteen typed constants, a properties schema per event, one comment at the top explaining the naming convention. That is mobile analytics event naming as a discipline, in two hours of typing.
2. Paying for the best vendor is orthogonal to mobile analytics event naming
This is the counter-intuitive point most non-technical founders get wrong. Paying $500 a month for Amplitude does not mean you have an event taxonomy. Amplitude — or Mixpanel, PostHog, or Firebase Analytics, treat all four as interchangeable here — is a very good implementation of the dashboard, funnel builder, and cohort explorer. It is the pipe and the visualisation. It is not the naming discipline. The vendor cannot reach up into your codebase and rename the inline event strings your engineers wrote last month. Only the taxonomy file can, because only the taxonomy file has one copy of each name.
Founders skip this decision because the engineer said "Amplitude handles the analytics for us" — which is true for storage, funnels, and dashboards, and irrelevant to whether paywall_view (fired from PaywallScreen), paywall_shown (fired from an A/B test wrapper), and paywallImpression (fired from a shared header component that happens to render on the paywall screen) all end up in the same project, competing for the same reality. The paywall_shown vs paywall_view argument is not resolvable at the vendor. It is only resolvable at the file that says "one of these is the event; the other two do not exist."
Think of it in three layers. Layer 1 is the callers — screens and business logic. Layer 2 is the taxonomy file — mobile analytics event naming as a single source of truth. Layer 3 is the vendor SDK — the pipe and the dashboard. Skipping Layer 2 collapses Layer 1 straight into Layer 3: every screen calls the vendor SDK with a stringly-typed event name of its author's choice. Renaming analytics events mobile teams need to change later — because the growth team asked for dashboard clarity, or because a year-two analytics hire cannot make sense of the funnel — turns into a codebase-wide grep, a scattergun search-and-replace, and a lost month of comparability when historical events do not match the renamed ones.
The discipline generalises. Identity events (sign_up_complete, login_success) live in the same taxonomy and follow the same convention — see the auth and identity decisions that haunt your mobile MVP for the identity-model discussion those events sit on top of.
3. Three founder-side questions before the first paywall_shown ships
Mobile analytics event naming is easy to verify without reading a line of code. Ask three questions in the architectural review and listen to the shape of the answer.
Question 1: "Show me the one file that lists every event the app fires and the naming convention behind it." If the engineer opens PaywallScreen.tsx and points at inline track('paywall_view', {...}) strings scattered across the screen, the taxonomy does not exist and you are watching the failure mode being built in real time. If they open analytics_events.ts, it declares every event as a typed constant with the properties schema alongside, and the paywall screen imports AnalyticsEvents.PAYWALL_SHOWN from that file, the taxonomy exists. The file name is not the point; the single answer — "here is the one file, and every track call imports from it" — is.
Question 2: "If I asked you tomorrow to rename paywall_view to paywall_shown because the growth team wants dashboard clarity, what would change?" The right answer names one file plus a one-line note in the vendor dashboard to alias the historical event so retention curves stay comparable. That is a one-hour change. The wrong answer describes grepping the codebase for paywall_view, checking every screen, hoping we caught the ones that got misspelled, then a QA pass to verify nothing else broke. That answer is the rename-tax quote your engineer will present in month six. Ask it in week one instead — you do not need to read the code, you need to hear the shape of the answer.
Question 3: "Where is the properties schema — how do we know every paywall_shown event carries paywall_variant and product_id, and that no event fires without them?" The right answer is the taxonomy file itself (typed properties on the event constant so it is a compile error to omit them) plus a small runtime assertion in the analytics wrapper as a belt-and-braces check. The wrong answer is "the engineer remembers to pass them." The wrong answer ships fine for the first hundred events; it produces the "why does 40% of paywall_shown have a null paywall_variant" support-thread in month four.
I have cleaned up codebases where the paywall fired three events — paywall_view, paywall_shown, and paywallImpression — from three different files, each written by whichever engineer was on the screen that week. The funnel showed a 300% conversion rate because the vendor was counting all three as separate impressions and matching all three against the same purchase. Rebuilding every funnel to use one canonical event name meant a dashboard rebuild, a re-learned baseline, and a lost month of comparability. The engineer who wrote the codebase held the same title, used the same vendor, and delivered on time. The difference between that codebase and one that survives the month-six funnel review is one file of mobile analytics event naming that was never written.
4. Where AI-augmented delivery lands
AI writes the vendor SDK wiring in minutes — the initialisation, the identify call, the track boilerplate, the offline queue, the flush-on-background handling. What AI does not do is decide which ten to fifteen events carry every funnel report the founder actually needs, what to name them so they still make sense to a data analyst who joins in month twelve, or which properties to attach so the paywall-variant question is answerable a year from now. That judgement is what the senior engineer is paid for. See how AI-augmented delivery works in practice for the workflow.
The positive proof is on the wall. Boyfi runs two monetisation surfaces — App Store IAP through Adapty and a web funnel through a custom Stripe API — and the funnel report reconciles both channels because mobile analytics event naming was locked once, in one file, before any instrumentation shipped. The same subscription_started fires from mobile and from web with the same properties, and the cross-channel funnel is answerable without a reconciliation script. MyCoach has run the same taxonomy file for two years and sixty-plus updates; the workout-completion funnel is comparable across the entire product lifetime. Hairly declares generation_started, generation_completed, and generation_failed with a provider property attached — three different image providers have been added by writing one adapter each, and the analytics side has needed zero changes.
The one file that saves the month-six funnel
The taxonomy is two hours in week one. The rename tax is a month in year one. Everything else is the same — the same vendor, the same engineer, the same product — and the difference is whether ten to fifteen event names live in one file with a property schema, or in twelve screen files with whatever the author was thinking that afternoon.
A clean taxonomy also pays off later in a way that was not obvious when this was written: once the names are consistent, an AI assistant can query the stack directly and be trusted with the answer. That is the subject of MCP for mobile app analytics, a live case study on a 1,000-DAU app. Garbage names in, three contradictory answers out.
If you are about to commission a mobile MVP, ask the three questions above before the first paywall instrumentation ships. If the answers do not sound like "here is the file," the codebase is already accruing rename tax. Tell me about your project and I will tell you whether mobile analytics event naming is already implied by your scope or the decision your engineer is about to skip. Or see the engagement model where analytics — and the other seven architectural areas — are owned end-to-end.
Originally published at msappdev.com.
