Why I add analytics before the first build, not after
I shipped an early version of an app without analytics because I wanted to move fast. Two weeks after launch I had download numbers from App Store Connect and nothing else - no idea whether people who opened the app actually reached the core feature, or bounced on the first screen. I could not tell if the problem was acquisition or the product itself, which meant I could not fix anything with confidence.
Adding analytics before the first build costs less than an hour and removes that blind spot completely. It does not need to be complicated - a handful of well-chosen events tells you almost everything you need for the first few months.
Picking a tool that works with Expo
Most general-purpose analytics SDKs (PostHog, Amplitude, Mixpanel) have React Native support that works fine inside a standard Expo project using a development build. Avoid tools that require heavy native configuration outside the Expo workflow unless you are already comfortable with config plugins - for a first app, pick whichever has the simplest Expo-specific setup guide and a usable free tier.
The events that actually matter at launch
| Event | Why it matters |
|---|---|
| App opened | Baseline usage - are people coming back, or opening once and leaving? |
| Onboarding completed | Shows whether your onboarding flow is actually finishing or losing people midway. |
| Core action performed | The single thing your app exists to do - if this number is low relative to app opens, the product has a real problem, not a marketing one. |
| Paywall or subscription screen viewed | Tells you how many people reach the point of a purchase decision, separate from how many convert. |
| Purchase completed | The actual conversion event - compare against paywall views to get a real conversion rate. |
Resist adding twenty events on day one. Every additional event is something to maintain, name consistently, and actually look at. Five events checked every week beats twenty events nobody reviews.
How to wire it into an Expo project
- Install the analytics SDK and its Expo config plugin if one is provided - this handles the native setup automatically on your next prebuild.
- Initialize the SDK once, near the root of the app, with your project's API key stored in an environment variable, not hardcoded.
- Add a single tracking call at each of the five core events listed above, using consistent event names (snake_case or camelCase, pick one and stick with it).
- Build a development build (not Expo Go, if your SDK needs native modules) and confirm events appear in the analytics dashboard before shipping to TestFlight.
- Check the dashboard again a few days after your first real users are in, not just once during setup - this is where you catch a broken event early instead of discovering it a month later.
A mistake worth avoiding
The most common analytics mistake is tracking an event once during setup, confirming it fires in a test, and never checking again. Events silently stop firing after unrelated code changes more often than you would expect - a renamed screen, a refactored button handler. Build a two-minute weekly habit of glancing at the dashboard, not just a one-time setup check.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
Do I need analytics before my first TestFlight build?
Yes, if possible. Adding it before your first external testers gives you real usage data from day one instead of a gap you can never fill in retroactively for that early cohort.
Is a free analytics tier enough for a new app?
For most new apps under a few thousand monthly active users, yes. Free tiers on tools like PostHog or Amplitude comfortably cover early-stage volume - you can evaluate paid tiers once you have real growth to justify the cost.
Should I track every button tap in the app?
No. Tracking every interaction creates noise that buries the events that actually matter. Start with the five core events tied to your app's main flow and add more only when a specific question comes up that existing events cannot answer.
Does adding an analytics SDK slow down my app?
A well-implemented analytics SDK has negligible performance impact for the event volume a typical app sends. The bigger risk to performance is usually elsewhere - analytics is rarely the bottleneck worth worrying about first.
Last reviewed by David on August 6, 2026
