FR: Support for multiple Analytics instances

[IjzerenHein]

Feature proposal

• Firebase Component: Analytics

It is currently only possible to log Firebase Analytics data to the default Firebase app. This "tight" coupling of Analytics with the default app makes it difficult/impossible to log analytics data to other Firebase Apps.

One example of a scenario where logging to multiple Firebase projects is needed, is the standard Expo client, which is a universal react-native app and can load (and host) different projects (where a project can be described as some JavaScript code, assets, and configuration settings). In this case, a unique Firebase App is created for each loaded project, which utilizes its own Firebase configuration.

The standard Expo client can be considered a "testing" environment, with which people can quickly get started and iterate/share their projects. It is therefore not essential that each additional Firebase Analytics instance behaves exactly as the default one. Instead, it would be sufficient if manual logging of events is possible.

Other scenarios where data-driven apps want to record data to multiple Firebase projects are also imaginable.

As a current workaround for the standard Expo client, a community version of a pure JavaScript Firebase Analytics client has been developed. It uses the "unstable" Measurement Protocol version 2.
Another drawback of this approach is that it requires additional configuration and an additional web-app needs to be configured in the Firebase project (in order to obtain a measurementId to log to).
firebase/firebase-js-sdk#2644

Optionally, it would be nice (food for thought), if the lifecycle events that are captured for the default Analytics instance are routable, and could for instance be "routed" to one of the other Analytics instances, instead of just the default instance.

Proposed API:

FIRApp *app = [FIRApp configureWithName:@"myawesomeapp" options:options];

FIRAnalytics *analytics = [FIRAnalytics analyticsForApp:app];
[analytics logEventWithName:@"myawesomeevent" parameters:${}];

Love to hear your thoughts 🧡

[paulb777]

Related to #230

[cpsauer]

If useful, had Firebase Analytics been open source, I'd have strongly considered building and contributing this feature--but I think we'll have to use another service or the Measurement API.

[david-var]

any updates on this? we have similar issue when we need to log 2 analytics depending on user category.

[joshuapoq]

Is there any plan to implement this on the roadmap? It's a big problem to have both crashlytics and analytics only use the default app.

Launch time config should be dropped by the industry; it encourages more CI or build time waste due to separate targets, QA process confusion, live data pollution and goes against the goal Apple has to unify app targets.

[paulb777]

@joshuapoq Thanks for the question. We're in the early stages of thinking about how to improve configuration. Would you share more about your use case and why it's a big problem that crashlytics and analytics only use the default app?

[cpsauer]

If useful, in our case, it's because we're building middleware. Imagine if you were building tooling for developers (in the same way as the rest of firebase, but noncompetitive, like say, the ultra popular PSPDFKit). You'd really want to be able to use crash reporting and analytics to make things better for your users! But you can't or you'd deny them use of firebase.

[johnny-liang-gd]

we're developing a SDK that would like to use Firebase to collect Analytics & Crashlytics data for business review over time, but seeing this I guess we're unable to achieve the goal, and I tried with a demo project, the config in the SDK never received any analyzing data itself except for the host app. Bummer!

[cpsauer]

Sounds like the same user story to me :)

[joshuapoq]

We are a SAAS ecommerce platform with a core SDK and integration SDKs. We have multiple development and QA teams. Each of our clients has at least 3 backend environments for which we used to have a matching number of targets.

Each target requires a separate app on Firebase (additional maintenance). But more importantly, separate builds. This separation of builds and apps for the same codebase sometimes causes QA confusion / misalignment leading to rejected tickets that has a knock-on and cumulative effect to time waste across multiple teams.

To eliminate this we've finally reworked our core SDK to be configured via a runtime environment switcher and, in doing so, have merged these environments into a single target per client. To avoid data pollution we have added a developer mode that integrations must explicitly handle (otherwise are disabled). When developer mode is toggled the app requires a restart, and on restart decides which Firebase app to use (development or production).

Following the above, with Analytics and Crashlytics tied to the app we need to run the upload symbols script twice on every build to ensure the symbols are in both apps when the app crashes. Additionally we require two apps to be set up to catch crashes during developer mode. If either were separate we would not need to do this as we could initialise both at runtime with the primary being the production app.

EDIT: The reason I said before that this encourages data pollution is that I believe (with limited experience to back this up) that many companies will test against their live app. If the Firebase mechanism for test data was different, perhaps built into the GoogleService-Info.plist, then I'd imagine companies would be more avoidant of data pollution. And with Apple's drive to merge targets into a single app that can be distributed cross-platform I imagine there will additional aspects to this problem.

[bartpowers]

Our use case:
We provide a "white-label" app for our our clients. We build the same app for client A and client B. We change out some colors and other data etc. We want to use remote config and other services (our google-services-info.plist)... and we want client A to provide their google-services-info.plist then client B to provide their google-services-info.plist for analytics so they can see their data in their firebase accounts

[AdamBebko]

I am also loading firebase configurations at runtime based on c# PROD and DEV scripting defines, and analytics doesn't seem to behave nicely with that. I'm using the Unity SDK

[ThetoMokganya]

Currently using two Firebase configurations loaded at runtime, however Analytics start of using the default configuration and once the second configuration loads. Analytics no longer uses the default configuration, which shouldn't be the case. Is there a way to specify which Firebase project Analytics should use?