Analytics

You can't improve what you don't measure. Once your app is in front of real users, analytics tells you:

• Are people finishing onboarding, or dropping off?
• Which features get used? Which sit untouched?
• Are paying customers behaving differently from free ones?
• When users leave, what was the last thing they did?

This page covers how to add analytics to your app. And, more importantly, what to actually track so the data is useful instead of overwhelming.

The temptation is to track everything

Don't. Tracking every tap creates noise, slows your app slightly, and creates a privacy footprint you'll regret. The best analytics setups start with a handful of well-named events and grow from there.

Which tool

Three good options:

• PostHog: open source, great free tier, gives you product analytics, session replay, and feature flags in one. Recommended default - and it's a managed connector: connect it once in Dashboard → Connectors and every project in your account can use it.
• Mixpanel: mature, strong cohort analysis, free tier is a bit smaller.
• Amplitude: large free tier, strong for growth teams.

For most apps, start with PostHog. Mixpanel and Amplitude aren't managed connectors - the agent can still wire them up best-effort if you ask, but it will want a fresh, minimum-permission key, and there's no encrypted storage or activity log for them.

"Set up PostHog analytics. Track account creation, log-in, first habit check, streak milestones, and paid conversion."

What the agent does:

1. Adds PostHog's library and starts it up at the app root.
2. Creates a typed track() helper.
3. Fires the events you named at the relevant places.
4. Uses the key from your PostHog connector (a public-by-design project key, so it's safe inside the app).

The five events that actually matter

If you only track five things, track these. They map onto the classic "Pirate Metrics" funnel. How someone gets in, sticks around, pays, and brings friends.

first_value_moment is whatever the one thing your app is for is. For a habit tracker, it's "checked off their first habit." For a chat app, "sent their first message." For a marketplace, "made their first purchase."

Beyond the basics

Once those five tell you the headline, layer in:

Friction events. Places people give up

• onboarding_step_shown and onboarding_step_completed. Pinpoints where onboarding leaks.
• paywall_shown, paywall_dismissed, paywall_converted. Your conversion funnel.
• error_surfaced. Every red error your users actually see.
• permission_prompted / permission_result. How many people say yes to push, location, camera.

Per-feature events

For each major feature: feature_viewed, feature_used, plus a domain-specific verb (habit_created, message_sent, comment_posted).

Naming events well

Consistent names make analytics readable six months later when you've forgotten what you set up:

• snake_case. habit_created, not HabitCreated.
• verb_noun. habit_created, not created_habit. Skim-readable.
• Reusable properties: every event can have source, plan, platform, app_version attached. Decide these once.

The agent uses these conventions by default.

Knowing who's doing what

Anonymous tracking tells you "how many people signed up." Identified tracking tells you "this specific user took these specific actions."

The agent calls identify on sign-in, attaching the user's ID and a few non-sensitive properties (their plan, when they signed up). From that moment on, all their events are connected to them.

Privacy. Don't pass real email addresses if you don't have to. The agent uses user IDs by default, not emails. PostHog and Mixpanel both support this cleanly.

Auto-tracking screen views

The agent adds a screen-view tracker that fires $screen_view every time the user navigates. Combined with custom events, it gives you a complete picture of the path users take before they bounce or convert.

Consent and privacy

If your users are in the EU, in California, or in any privacy-conscious market:

• Disclose analytics in your privacy policy (our template does).
• Ask for consent before any non-essential tracking.
• Respect "no". Completely stop tracking that user, not just hide it.

"Add a one-time consent prompt for analytics. Users can accept or decline; declining disables all tracking until they change their mind in settings."

Session replay (PostHog only)

Session replay lets you watch anonymised recordings of user sessions. Phenomenal for figuring out "wait, why are people stuck on this step?"

"Enable PostHog session replay for 5% of sessions. Don't record any screen that shows sensitive data (payment forms, private messages)."

Mask sensitive inputs so they never leak into recordings.

Funnels

Once you have events flowing, build funnels in your analytics dashboard:

Onboarding funnel: account_created → email_verified → first_habit_created → first_habit_checked

Paid conversion funnel: paywall_shown → plan_selected → checkout_started → subscription_started

Each step shows the drop-off. Wherever the biggest drop is, that's where to focus next.

What not to track

• Everything every tap. Pick the events that matter.
• Free-text fields. Don't send what users actually type in journal entries, chats, or notes.
• Sensitive data. Health info, payment numbers, street-level location, government IDs. Never.

A useful test: if a user asked "what are you tracking about me?", would your answer embarrass you? If yes, stop tracking it.

Under the hood (for engineers)

posthog-react-native initialised at app root with the public project key from your PostHog connector. A typed analytics.track(event, properties) wrapper enforces event-name discipline. usePostHogRouterTracker() hook fires screen views automatically. identify() on auth state change.

For alternative providers (Mixpanel/Amplitude), the wrapper interface stays the same. Only the underlying SDK differs.

Next

Read Error Monitoring to catch the crashes your users don't report.