I am looking into using Firebase Analytics for my apps. I'm curious:
What are the criteria for which retention is based on? Does retention track user accounts with a unique id that I'd have to send, or unique device?
How would I control for this if, say, a user logs into my app from multiple devices? I'd want to make sure a user's retention is applied from those multiple devices.
The Firebase SDK library uses an app-instance identifier to Identify a unique installation of the App. When using the SDK, an app-instance identifier gets generated at the app level (Source: https://support.google.com/firebase/answer/6318039?hl=en).
There is also a thing called User Properties that you can use to have a better understanding about unique users i.e. users that signed into your app (Source: https://firebase.google.com/docs/auth/users)
Related
My team is using Firebase Auth in our project. We're using custom claims to properly authenticate whether or not a user has access to a specific piece of information. We're storing each piece of information and deciding access for the user based off whether or not the user has access to a specific location. Each piece of data is somehow associated with a location, and we are storing the location id in the custom claims for the ID Token.
The problem is that a user potentially has access to thousands of locations. Instead of storing thousands of locations in the custom claims, we think it's better to generate a new custom token and exchange it for a fresh id token every time the user switches locations. That means that it's potentially reasonable for a user to generate a new custom token every few seconds as they switch through their locations if they are doing it quickly enough.
The Firebase Auth documentation doesn't indicate anything in regards to any rate limiting in this regard.
Are we going to run into any issues / rate limiting if a user switches through their locations very quickly? This would be unusual, but I just want to make sure that the worst case will still work.
The control of Firebase Authentication custom claims is an Admin SDK operation and as such is not subject to rate-limiting. Firebase Authentication as a whole is designed to handle millions of concurrent users and is subject to various rate limits. Updating a user's custom claims would only contribute to the overall limits of 1000ops/sec and 10 million ops/day (at time of writing).
However, custom claims should be used for access control related data that will infrequently change such as the name of a role or a building ID. This is because the propagation of changed custom claims can take up to an hour and requires that the client code manually refresh their tokens after any changes to see an immediate effect. Custom claims have no mechanism to notify clients that they have been updated.
I'd reconsider your approach and store the list of locations a particular user has access to in the Realtime Database or Cloud Firestore rather than the ID token itself. You can then use this information to secure their access using appropriate Security Rules for those databases based on their user ID. By configuring a listener to that portion of the database, your client code can be instantly notified when a user gains or loses access to a new location. Additionally, you can poll information from multiple locations at once so you can show information in a notification feed or dashboard - something that can't be done with the claims strategy.
Firebase is great as it offers a lot of authentication providers. In one of my apps, I use four different providers provided by Firebase (Email, Twitter, Facebook and Google), but I also need to let users sign in via LinkedIn.
As Firebase SDK does not offer LinkedIn, I need to implement the login flow manually, which doesn't seem to be difficult, but there is one huge issue which I see. During the creation of a custom JWT token, I need to assign a user ID. And I have no idea how to generate one while making sure that my approach will not conflict with user IDs which Firebase generate on its own for other providers.
For example, let's imagine that a user Andriy Gordiychuk signs in via LinkedIn and his email address is andriy#gordiychuk.com. A simple way to create a user ID would be to take an email address (andriy#gordiychuk.com) and to randomise it using some hashing function. I would get some random id such as aN59nlphs... which I would be able to recreate as long as the same user signs in. So far, so good.
However, how can I be sure that the ID which I get is not already used by another user who signed in via Twitter, for example?
One way to mitigate this issue is to store LinkedIn user IDs in a Firestore collection. Then, when I need to create a token, I first check whether I already have an ID for this user. If not, I would hash the email address, and I would try to create a user with this ID. If this ID is already occupied, I would then try to create another ID until I stumble upon an ID which is not occupied, and I would then use it.
I don't like this approach for two reasons:
Although the chance that I would generate an already occupied ID
is small, theoretically the process of finding an "available ID" can
take a lot of steps (an infinite loop in a worst-case scenario).
Once I find an available ID, I must store it. Given that all these calls are asynchronous there is a real chance that I would create a user with a suitable ID, but because the save operation fails, I would not be able to use this ID.
So, does anyone know how to choose user IDs for such use case correctly?
It's fairly common to generate a string with enough entropy (randomness) to statistically guarantee it will never be duplicated. This is for example behind the UUID generators that exist in many platforms, and similarly behind Firebase Realtime Database's push keys, and Cloud Firestore's add() keys. If there's one in your platform, I recommend starting with that.
Also see:
The 2^120 Ways to Ensure Unique Identifiers, which explains how Firebase Realtime Database's push() works.
Universally unique identifier, Version 4 on Wikipedia
the uuid npm module
I am using FCM console to send push messages to the users. Until now I am targetting using User Segments through which I can filter users based on language. But now I need to allow users to subscribe or unsubscribe to the type of alerts they can receive. So I am exploring the option Topics. But now from firebase console I can either target users based on User Segments or Topics.
I want to be able to use Topics with the options I can get in User Segments(where I can filter based on language). Is there a way to make this possible?
Thanks,
Sindhu
Segments can't be targeted with topics. Segments are populated by data collected by Firebase Analytics, and don't identify individual devices. Topics are just names that you make up, and the names must match between the device and server.
You will need to find a way to match up users in a segment to the topic that you create for that segment. You could try to use Remote Config to give clients the name of a topic that matches their segment, then use FCM to subscribe to that topic.
My app uses Firebase for authentication and I'm having trouble understanding the discrepancy between the number of authenticated users (1027) and the number of installs (4800):
This suggests that a lot of people installed the app but very few logged into it. If so, why would anyone go to the trouble of installing but not using it? Or am I reading Analytics wrong?
Stack Overflow isn't really the right place to ask about human behavior. There could be any number of reasons why someone installed an app and deleted it without even signing into it.
We also don't know if you allow users to delete their accounts after signing in, which could also explain a difference.
We don't know if your users have multiple devices, which would each count as different (anonymized) users in Analytics, but the same user account in Authentication.
There could even be robotic crawlers trying to use the app, especially if it's a web app.
If you're having problem reconciling what you see in the console, you're probably better off contacting Firebase support to see if something is wrong. But something is probably not wrong at all. Consider instead putting some effort into instrumenting your app with more analytics events to figure out exactly how people are using it, and where they might be falling off before they ever sign in, or if they sign in with multiple devices.
I received an answer from Firebase Support and here's what they said:
The active user calculation in our dashboard is based on the user_engagement of your user who access your application while the app is in foreground state. With that, the active user count is not based on the total count of your authenticated user because we track it using the user_engagement event. This is expected that there would be greater number of active users than your authenticated user count if your user didn’t authenticate and they’re using the app within foreground state.
I turns out that the number of 4800 is the number of "engagements" by the app's users, not the number of users. If the user logs in, then goes to another page, that's two engagements. Firebase Analytics is a great way to analyze what people are doing in the app. I love it!
Consider the following case:
User got invitation ticket, after they invite person, the number will decrease. The user can't add the invitation number by their own. Based on the Firebase (Within Function), it seems that it is not suitable for this use case, because once I grant access for user to modify the invitation number for user, they can somehow increase the number or assign any number they want. Is my understand correct? Thanks.
No, security rules can allow you to restrict the data written to the realtime database and by whom.
If you need trusted administrative logic, such as keeping counters you can use Cloud Functions for Firebase or the admin-sdk on a traditional backend.