Firebase is a platform, and analytics is one part of it. Most posts about "replacing Firebase" quietly mean replacing the whole thing, which is a different and much larger decision. This is about the analytics part only: what changes if you take Google Analytics for Firebase out of an app, what you should keep, and what genuinely has no replacement.
Why anybody looks
Measuring an app should not require agreeing to an advertising platform. Firebase Analytics keeps an app instance identifier on the device and is built to work with the platform advertising IDs (Android's advertising ID, Apple's IDFA) because attribution to ad campaigns is much of what it is for. If you do not advertise, you are carrying the machinery anyway.
Consent. An identifier on the device brings a consent requirement in the EEA and the UK with it, and an app that asks on first launch loses some share of its own users from its own numbers. The same argument as a cookie banner on a website, with a worse first impression.
The event model. Firebase Analytics is an event-and-parameter system. It rewards a team that models its events carefully and gives very little to one that does not, which is most teams for most of a product's life.
One vendor, one relationship. Some organisations simply cannot send app usage to Google. That is a procurement fact rather than an argument, and it is the reason a large share of the people reading this are reading it.
What a privacy-first app SDK sends instead
The useful question is not "is it private" but "what is in the payload". Skomi's app SDKs send:
- the screen name you gave it, your properties, and whether it opened the session
- the platform, the OS version, and whether the device is mobile or desktop
- the app version you passed, and which build of the SDK sent it
- when it happened on the device's clock, and when the batch was flushed
- an identity: a random UUID the installation generates for itself
Nothing else. No advertising ID, no device ID, no location, no account, no contacts, and therefore no runtime permission on any platform beyond internet access, because none of the things that need one are being asked for.
That is the trade in one line: you can no longer join app usage to an ad campaign, and you no longer have to ask anybody's permission to count them.
Keep your crash reporter
This is the part people get wrong, and Skomi's own SDK documentation says it plainly rather than leaving you to find out.
An app analytics SDK can report the errors your code hands it and the ones the framework raises. It cannot report a native crash, whether a segfault in a plugin's C++, an out-of-memory kill or an NSException from a platform channel, because the process that would do the reporting is already gone.
So Crashlytics, Sentry or the store's own reporting stays. What you get from the analytics side is a crash-free rate sitting beside your release numbers, which answers a different question: not "what broke" but "is this build worse than the last one". Worth knowing: that rate errs pessimistic, because a session that crashed before its first screen counts as crashed and not as a session, which is the safe direction to be wrong in.
There is also no mapping-file upload, so a stack from a minified release build arrives as it was thrown. Another reason the crash reporter stays.
What has no replacement
Being honest about the rest of the platform, because "Firebase alternative" is often shorthand for far more than analytics:
- Remote Config, A/B testing, Cloud Messaging, Authentication, Firestore. None of these are analytics and none of them are replaced by an analytics tool.
- Audiences and ad attribution. Building an audience in Firebase and using it in Google Ads is the integration Firebase Analytics exists for. Take the advertising ID out and that goes with it, by construction.
- Raw event export. Firebase can stream every event into BigQuery. Skomi's app API answers with aggregates (summaries, time series, breakdowns) rather than with a table of events to model yourself.
If any of those three is load-bearing for you, this is not a swap you want to make.
What you get that Firebase does not give you
- The same reports for your site and your app, in one account. A release and a marketing campaign in the same week are two lines on the same page rather than two products and a guess. See one place for app and site analytics.
- An offline queue that does not double-count. Every screen carries an id minted once, so a batch retried after a fortnight without signal is recognised rather than counted again.
- A consent switch that means it.
Enabled = falserecords nothing and sends nothing, so the SDK can exist from start-up and begin only when somebody agrees.
The honest summary
If you use Firebase for authentication, messaging and a database, this replaces one component of it and you keep the rest, including Crashlytics.
If you added Firebase to an app only to find out how many people opened it and which screens they reached, you are carrying an advertising platform to answer a question that does not need one, and removing it is a small change with a disproportionate effect on what you have to disclose.
Installing takes one call: Flutter, .NET MAUI, or any of the eight SDKs.
What arrives once it reports is on the App analytics page: screens, sessions, versions and the crash-free rate. The rest of the field, including the products that beat us on price, is set out on Firebase alternatives.