When an Expo or React Native app shows no data in Firebase Analytics, the cause is almost always one of five things: you're running in Expo Go instead of a development build, the native config file is missing, you haven't actually logged any events, the standard reports just haven't processed yet (that can take up to 24 hours), or events are firing but you're only checking the wrong report. None of these mean the SDK is broken. They mean the events never reached Firebase — or reached it and you looked too early. Here's how to find which, in order.
Are you running in Expo Go instead of a development build
This is the cause that specifically catches Expo developers. The native Firebase Analytics SDK (via React Native Firebase) includes native code, and it does not run in Expo Go — you need a custom development build instead. Expo's own guide is explicit that React Native Firebase requires a development build rather than Expo Go (Expo — Using Firebase).
If you've been testing in Expo Go, analytics calls either no-op or never initialize, so Firebase receives nothing. Create a development build (Expo — Development builds), install it on a device or simulator, and test there.
Did you add the native config file
Firebase identifies your app through a platform config file: google-services.json for Android and GoogleService-Info.plist for iOS. If those aren't present and wired into the native project (in Expo, via the config plugin and your app.json/app.config.js), the SDK can't associate events with your Firebase project, so they go nowhere. Re-download both from the Firebase console, confirm the bundle identifier and package name match your app exactly, and rebuild. A frequent trap with AI-scaffolded projects is a placeholder or example config that was committed before the real Firebase project existed — the file is present, so nothing errors, but it points at a project you can't see. Open the file and confirm the project_id actually matches the project whose dashboard you're staring at.
Is the tag firing right now — use DebugView
Don't wait on dashboards to answer this. Firebase DebugView shows events from a single device in near real time, so you can trigger an action and watch the event arrive within seconds (Firebase — DebugView). Enable debug mode on your build, open DebugView in the console, and use your app. If your events appear there, collection works and the problem is downstream (latency or the wrong report). If nothing shows, the SDK isn't sending — loop back to the build and config checks above.
Did you wait long enough for standard reports
Firebase Analytics standard reports are not instant. Most data is processed and reflected within about 24 hours, so the Events and Dashboard screens can legitimately read empty an hour after launch even while DebugView is live. This is why DebugView exists: it's the real-time confirmation, and the aggregate reports follow a day later. If DebugView shows events but the dashboard is empty, this is very often the whole answer — wait a day and recheck before changing code.
Are you actually logging events
Firebase collects a set of events automatically — first_open, session_start, screen_view, and user_engagement among them — so you should see some activity even with zero custom code (Firebase — Automatically collected events). But the events that tell you anything useful about your product (a signup, a purchase) only exist if you call logEvent yourself (Firebase — Log events). If the dashboard shows automatic events but none of your custom ones, the SDK is fine — you just haven't instrumented the actions you care about yet. See the 5 events a vibecoder should actually log for the short list.
The durable fix: own the events that matter
Chasing the Firebase setup is worth doing, but a mobile analytics SDK still depends on native builds, store review, and device conditions you don't fully control. The resilient pattern is to also record the handful of actions you truly care about — a signup, a trial start, a purchase — as first-party owned events sent to your own endpoint and stored in your own database. Those don't depend on a correctly configured native SDK to exist, and they give you a baseline that doesn't read zero just because a config file was missing or a build was wrong.
VibesFlyer is built around this split: your AI coding agent wires owned events and connects Firebase in one step, then normalizes both so a misconfigured SDK can't leave you blind. For the full Firebase wiring on Expo, see Firebase Analytics in an Expo app; for how Firebase and an attribution tool divide the work, see Firebase vs AppsFlyer. Work through the five checks above in order, and "no analytics data" almost always turns into "it was an Expo Go build" or "the report just needed a day."