Mobile App Analytics for React Native: A Complete Guide to What to Track and Why

** Most mobile apps don't die from bad code. They die from invisible problems — users who never finished onboarding, a checkout step that lost half the funnel, a feature nobody opened after week one. You can't fix what you can't see. This guide walks through the analytics setup every React Native or Expo app should have running before it ships to TestFlight: the AARRR framework, the activation event trick, the one chart that matters, and a tool-agnostic event-tracking pattern in TypeScript.

Why mobile app analytics is different from web

Mobile data flows through an SDK embedded inside the binary rather than a tag injected into a page. That architectural difference cascades:

• Attribution is harder. Apple's App Tracking Transparency reshaped what you can see for paid-acquisition channels.
• Sessions are defined differently. App foreground time, not page navigation.
• Privacy rules apply. Both iOS and Android have platform-level limits on what you're allowed to track without explicit consent.

That makes the discipline of choosing what to measure even more important. You can't compensate for bad instrumentation with a clever JavaScript snippet the way you can on web. If you didn't track it, you don't have it.

The AARRR framework, applied to mobile

The cleanest mental model for mobile analytics is AARRR — Acquisition, Activation, Retention, Referral, Revenue — popularized by Dave McClure. It works because it follows the user's actual journey, top to bottom, and forces you to ask one question at each stage: where are we leaking?

Stage	Question	What you'd track
Acquisition	How do users find us?	Installs by channel, CPI, attribution
Activation	Did the first session land?	Onboarding complete, first key action
Retention	Do they come back?	D1/D7/D30 retention, DAU/MAU
Referral	Do they bring friends?	Invite rate, viral coefficient (K)
Revenue	Does any of this pay?	ARPU, LTV, conversion to paid

You don't need a metric in every row on day one. You need to know which row is leaking the worst, and you can only know that if you can see all five.

Most apps focus heavily on acquisition because the numbers are easy to get and feel like progress. The teams that actually compound focus on activation and retention, because that's where leverage lives.

The single most important event: activation

Activation is the most under-instrumented stage and almost always the most leaky. The reason teams skip it is that "activation" feels abstract. The fix is to make it concrete.

Pick a behavior that, if a user does it in their first 48 hours, strongly predicts they'll still be around in week two. Real examples:

• Dropbox: "one file in one folder on two devices"
• Facebook (early): "seven friends in ten days"
• Slack: "2,000 messages sent in a team"
• A fitness app: "logged one workout in the first 48 hours"

Write this down before you write any tracking code:

A user is activated when they ___ within ___ minutes/days of installing.

You're guessing at first. That's fine. You instrument the event, watch it for a month, and correlate it against week-two retention. If users who hit your activation event retain at 60% and users who don't retain at 10% — congratulations, you've found your activation event. If both groups retain the same, the event isn't really activation. Pick another and try again.

For a deeper walkthrough of the onboarding flow that drives activation in the first place, see the user onboarding best practices guide on the RapidNative blog.

Implementation: a tool-agnostic event schema in TypeScript

The biggest analytics mistake most React Native teams make is calling SDK functions directly from screen components. The result is event-name drift (Purchase / purchase / purchasedItem all in the same codebase) and a painful migration when you outgrow your first analytics provider.

The fix is a thin abstraction. Three files, ~50 lines total.

Step 1: Define your events as constants

// src/lib/analytics/events.ts
export const Events = {
  APP_OPEN: 'app_open',
  SIGN_UP_COMPLETE: 'sign_up_complete',
  ONBOARDING_COMPLETE: 'onboarding_complete',
  ACTIVATION: 'activation',          // your one defined event
  PURCHASE_COMPLETED: 'purchase_completed',
  SHARE_INITIATED: 'share_initiated',
  PUSH_RECEIVED: 'push_received',
  PUSH_OPENED: 'push_opened',
} as const;

export type EventName = typeof Events[keyof typeof Events];

The as const assertion gives you a typed union, so TypeScript will yell at you if you typo an event name anywhere in your codebase.

Step 2: Wrap your analytics provider

// src/lib/analytics/index.ts
import PostHog from 'posthog-react-native';
import type { EventName } from './events';

let client: PostHog | null = null;

export const initAnalytics = (apiKey: string) => {
  client = new PostHog(apiKey, { host: 'https://us.i.posthog.com' });
};

export const track = (event: EventName, props?: Record<string, unknown>) => {
  if (__DEV__) console.log('[track]', event, props);
  client?.capture(event, props);
};

export const identify = (
  userId: string,
  traits: Record<string, unknown>,
) => {
  client?.identify(userId, traits);
};

export { Events } from './events';

Three things this gets you:

1. Single switch point. Swap PostHog for Amplitude or Mixpanel by changing this one file. Every call site keeps working.
2. Dev logging. __DEV__ logging means you can verify events in the Metro console before they hit production.
3. Null-safety. Calls are safe even before initAnalytics() has run — useful during app startup.

Step 3: Call from screen components

// src/screens/OnboardingScreen.tsx
import { track, Events } from '@/lib/analytics';

export const OnboardingScreen = () => {
  const handleComplete = async () => {
    await saveProfile();
    track(Events.ONBOARDING_COMPLETE, {
      flow: 'signup_v2',
      steps_skipped: skippedSteps.length,
    });
    navigation.replace('Home');
  };

  // ... rest of component
};

Clean, typed, no SDK leak into your UI code.

User properties: do this once, slice everything forever

The biggest analytics regret most teams have is not setting user properties on day one. Once they're attached, every event you've ever tracked becomes sliceable by them retroactively.

import { Platform } from 'react-native';
import DeviceInfo from 'react-native-device-info';
import { identify } from '@/lib/analytics';

// on first sign-up
const onSignUp = async (user: User) => {
  identify(user.id, {
    install_source: await getAttribution(),  // organic, paid, referral
    signup_date: new Date().toISOString(),
    platform: Platform.OS,                    // 'ios' | 'android'
    app_version: DeviceInfo.getVersion(),
    plan: 'free',
  });
};

// on plan change later
const onUpgrade = (userId: string, newPlan: string) => {
  identify(userId, { plan: newPlan });
};

Now you can ask "what's D7 retention for organic-install Pro users on iOS?" without ever touching tracking code again.

The chart that matters more than DAU

The single most useful chart in mobile analytics is the cohort retention curve — a triangle where each row is the install week and each column is the percentage of that cohort still active N weeks later.

If the curve flattens around D30, you have something. If it keeps dropping toward zero, you don't — no matter what the install counter says.

Healthy products see newer cohorts retaining better as the team fixes activation. If your January cohort retains better than your March cohort, your product is regressing — usually because a new feature broke onboarding or a recent acquisition channel sent lower-quality users.

Most modern tools (Amplitude, Mixpanel, PostHog) ship this view out of the box. Firebase requires more setup. Andrew Chen's classic write-up on the smiling retention curve remains the cleanest visual explanation of why this chart matters.

Vanity metrics to remove from your dashboard

Some metrics are seductive because they always go up, which is exactly why they're nearly useless for decisions:

• Total installs — a counter that only moves one direction
• Total registered users — a dead user is still registered
• Page views without context — high screen views with low conversion usually means users are lost, not engaged
• Followers on social — unrelated to in-app behavior
• Average time in app, isolated — meaningless without knowing what action a longer session represents

Replace each with a ratio or a cohort:

Vanity metric	Decision-making replacement
Total installs	30-day retained users from last month's installs
Page views	Screen views per session for activated users
Avg session length	% of sessions where activation event fired
Registered users	DAU as % of registered users (engagement rate)
Total revenue	ARPU by acquisition cohort

The discipline of converting absolute numbers into ratios is the difference between a dashboard and a decision-making tool.

The day-one stack

The mistake most teams make is installing five SDKs on launch day and tracking nothing useful, instead of installing one and tracking five things well.

A practical day-one stack for a React Native or Expo app:

Layer	Pick one	Why
Product analytics	Firebase / Amplitude / Mixpanel / PostHog	All have first-class RN/Expo SDKs
Crash tracking	Sentry or Crashlytics	Engagement data is meaningless if you don't know which sessions crashed
Attribution	Defer — AppsFlyer / Adjust / Singular	Only needed when you start paid acquisition
Session replay	Defer — PostHog session replay, LogRocket	Useful after activation rate stabilizes
A/B testing	Defer — Firebase Remote Config	Useful when you have a hypothesis worth testing

Decision guide for picking your product analytics tool

• Firebase Analytics — Best free default. Generous free tier, integrated with Crashlytics, Remote Config, and A/B testing. Weakest cohort UI.
• Amplitude — Strongest cohort and funnel UI. Free up to 50K MTUs. Standard for product-led growth teams.
• Mixpanel — Mature reports, good retention visuals. 20M events/month free. Solid middle option.
• PostHog — Open-source, self-hostable, session replay built in. Good for privacy-conscious teams.

Whichever you pick, use the abstraction pattern from earlier so swapping is a one-file change later.

How to integrate analytics into a React Native MVP fast

If you're generating your React Native MVP with RapidNative's PRD-to-app builder, you can add the analytics SDK directly to the exported Expo code — the codebase is standard React Native, so any provider's SDK installs cleanly without translation. The fastest path:

1. Generate the screens with RapidNative
2. Export the project locally
3. npx expo install posthog-react-native (or whichever SDK you picked)
4. Drop in the three files from the implementation section above
5. Add track(Events.ACTIVATION) to the screen where your activation event happens

You're tracking events the same afternoon you generated the app. Pair this workflow with the patterns in AI-driven React Native development and the loop from screen change to measured impact closes in hours instead of sprints.

Frequently asked questions

How many events should a new mobile app track?

Start with 6–10 well-named events covering the full AARRR funnel, then expand only as specific questions come up. Tracking 60 events on day one almost guarantees that none of them will be reliable, and you'll spend more time cleaning up the schema than learning from it.

What's a good retention rate for a React Native app?

Industry benchmarks vary by category, but rough rules: Day 1 retention of 25–40% is healthy for consumer apps, Day 7 of 10–20% is good, and Day 30 of 5–10% is what most successful apps land at. Social and messaging apps run much higher; one-off utilities run lower. The shape of the curve matters more than any single day.

Do I need a paid analytics tool for an MVP?

No. Firebase Analytics is free, has React Native and Expo SDKs, and covers the basics — events, funnels, retention, audiences — at no cost up to very generous limits. Most MVPs don't outgrow it until they have meaningful revenue or need cohort-level analysis Firebase can't do well.

How do I track conversions when iOS App Tracking Transparency blocks IDFA?

For in-app conversions (sign-up, purchase, activation), ATT doesn't apply — those events are first-party data and track normally. ATT only restricts cross-app identifiers used for ad attribution. Use Apple's SKAdNetwork (or SKAN 4) for paid-acquisition attribution on iOS, and accept that your channel-level numbers will have a 2–3 day delay and some aggregation noise.

Mixpanel vs Amplitude vs PostHog for React Native — what's the actual difference?

All three have first-class RN SDKs and cover the same core features (events, funnels, cohorts, retention, user properties). The differences are operational: Amplitude has the strongest cohort UI; Mixpanel has the most mature reporting; PostHog is the only one you can self-host. Pick based on whether you optimize for UI polish (Amplitude), report depth (Mixpanel), or data ownership (PostHog).

Build, measure, learn — faster

Mobile app analytics isn't a dashboard. It's a discipline: pick the metric that matters, instrument it before you ship, and let the data argue back when your gut says otherwise.

The teams that win in mobile aren't the ones with the prettiest dashboards. They're the ones who decided on day one which question they were trying to answer and built tracking against that question first.

If you're at the start of that journey, speed of iteration is the bigger lever than analytics tooling. RapidNative turns a plain-English prompt into a real, working React Native + Expo app in minutes. Ship the first version, instrument the activation event with the pattern above, watch what happens, and iterate. The faster the build–measure–learn loop runs, the sooner the metrics actually mean something.

---

What's the activation event you defined for your app? If you've found a behavior that strongly predicts week-two retention, drop it in the comments — I'm collecting examples across categories.