Firebase Analytics can log up to 500 distinct event types, and the console surface that comes with it is genuinely overwhelming when all you shipped is a small app built with an AI agent. You don't need most of it. For a new mobile app, five events tell you almost everything worth knowing: first_open, sign_up, one activation event you define, purchase, and one retention signal. Two of those you already get for free. The other three are a few logEvent calls. Here's the short list, in the order you should add it.
first_open and session_start — you already have these
Before you write a single line of tracking code, Firebase is already collecting a set of events automatically: first_open the first time someone launches the app after installing, plus session_start, screen_view, and user_engagement (Firebase — Automatically collected events). That means your "how many people opened the app and came back this week" baseline exists the moment the SDK is wired in correctly.
The practical implication: don't reinvent these. People new to analytics often add a custom app_opened event that duplicates first_open and then wonder why their numbers double. Lean on the automatic events for acquisition and engagement, and spend your own instrumentation budget on the three events below that Firebase can't infer for you. (If even the automatic events aren't showing up, that's a setup problem, not a logging one — work through why your app shows no Firebase data first.)
sign_up (and login)
The first event you should add yourself marks the moment a person becomes a known user. sign_up is one of Firebase's recommended events, which means Google has defined a canonical name and parameters for it so it slots cleanly into reports (Firebase — Recommended events). Log it once, when account creation succeeds, with the method parameter ("google", "apple", "email") so you can later see which sign-in path people actually use:
logEvent(analytics, "sign_up", { method: "apple" });
Add login the same way for returning sessions if you have authentication. Using the recommended names rather than inventing user_registered matters: recommended events unlock prebuilt dimensions and keep your data legible to anyone (or any tool) that knows the Firebase vocabulary.
Your one activation event
This is the most valuable event you will log, and it's the one no template can write for you, because it's specific to your product. Activation is the single action that means "this person understood what the app is for" — created their first note, finished onboarding, sent the first message, generated the first output. Pick exactly one to start.
There's no universal reserved name for this because it's yours, so log a clear custom event — created_first_project, completed_onboarding — via logEvent (Firebase — Log events). The reason this matters more than raw opens: it converts a vague "people are using it" into a rate you can act on. If lots of people hit first_open but few hit your activation event, you don't have a traffic problem, you have an onboarding problem — and you'll know exactly which screen to fix. That logic is the backbone of telling whether anyone is actually using your app.
purchase — always with value and currency
Even if you haven't turned on payments yet, define purchase now so the funnel is measurable the day you do. purchase is a recommended event, and the two parameters that make it useful are value (the amount) and currency (an ISO 4217 code like "USD"). Without currency, Firebase can't convert and total your revenue correctly; without value, you have a count but no money attached.
logEvent(analytics, "purchase", {
value: 9.99,
currency: "USD",
transaction_id: "abc123",
});
Getting value and currency right from the first purchase event is what later lets you read revenue per user and feed a real return-on-ad-spend number — the foundation of measuring mobile ROAS. Retrofitting currency onto months of purchase events that never had it is painful, so add the parameters on day one even at $0.
One retention signal
The fifth event is whatever tells you a user came back and did the core thing again — not just reopened the app, but returned to value. Often this is a screen_view of your main screen (automatic) or a repeat of your activation action. You usually don't need a brand-new event here; you need to decide which existing event you'll read as your retention signal and watch whether day-1 and day-7 cohorts keep firing it. Retention is the number that most reliably predicts whether the app has legs, and it falls out of events you're already logging once you've named the one that counts.
Map the five to one normalized view
Five events, three of them one line each, and you can answer: do people open it, do they sign up, do they get value, do they pay, do they come back. That's a complete first-week picture without touching the other 495 event slots or a single Exploration report. For the full Expo wiring of these calls, see Firebase Analytics in an Expo app; for what each metric means, the mobile metrics glossary is the reference.
The last step is making the five legible together. They're more honest as a set than individually, but Firebase shows them across different reports, and a misconfigured SDK can quietly drop any of them. VibesFlyer records the same five as first-party owned events and normalizes them next to Firebase into one schema — active users, activation, conversion, revenue, retention — so your AI agent can read the whole funnel over MCP or a daily Telegram digest, and "Firebase is overwhelming" turns into five numbers you actually check.