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, with product analytics, session replay, and feature flags in one. Review its current plan limits before launch.
- Mixpanel: mature and strong at cohort analysis.
- Amplitude: strong for growth and product analytics teams.
For most apps, start with PostHog. Mixpanel and Amplitude are not managed connectors. The agent can generate a best-effort setup from official docs, but never give it a credential in chat; provision any runtime value directly through the deployed app/backend environment appropriate for that provider.
"Set up PostHog analytics. Track account creation, log-in, first habit check, streak milestones, and paid conversion."
What the agent can do in preview:
- Adds an HTTP-based capture helper without importing the native SDK.
- Creates a typed
track()helper. - Fires the events you named at the relevant places.
- 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.
| Stage | Event | Why |
|---|---|---|
| Acquisition | account_created | How many new users you got today |
| Activation | first_value_moment | Did they actually do the thing your app is for, on day one? |
| Retention | app_opened | Are they coming back the next day? The next week? |
| Revenue | subscription_started / subscription_cancelled | Are people paying? Churning? |
| Referral | invite_sent / invite_accepted | Do users bring 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_shownandonboarding_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, notHabitCreated. - verb_noun.
habit_created, notcreated_habit. Skim-readable. - Reusable properties: every event can have
source,plan,platform,app_versionattached. 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."
Ask the agent to add an explicit identify event on sign-in using an opaque user ID and only reviewed, non-sensitive properties. Verify consent and event payloads before enabling it.
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 can add explicit screen-view events for the navigation paths you select. Automatic native navigation tracking requires the PostHog SDK after export.
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 requires the native PostHog SDK after export and can capture sensitive context. Configure consent, masking, sampling, and excluded screens deliberately before enabling it in a development build.
"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)
The preview uses plain HTTP capture/decide calls with the public project key. After export, you may install posthog-react-native for native autocapture, session replay, and richer lifecycle tracking, then test consent and payload redaction in a development build.
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.