I import firebase analytics logs to BigQuery, and observed the user_pseudo_id changed unreasonably. As I put a "UUID" in user profile in their own app, and found some events are bundled with same "UUID", can have different user_pseudo_id. And I'm pretty sure the users didn't re-download or re-install the app.
Especially, sometimes, I saw the user_pseudo_id changed from A to B, and later changed back to A.
Any hints/instructions? Thanks a lot!
I saw the same behavior. I guess the id would also change if the user clears local cache. I now assume user_pseudo_id can change over time and use other more durable ids to map them. I've never seen it change backwards though, would be an interesting case.
Related
We are using Firebase/Google analytics for our Android and iOS app. Everything seemed to be sending data correctly and we were able to view the data in Big Query etc. However we started to notice that some data seemed to be getting lost.
We detected an odd situation where some users' analytics data stopped showing on Firebase/Google Analytics/Big Query, despite having previously received data from that user in the past. The data seems to just stop at a random point in time, for random users.
in_app_purchase events from those players were still appearing in the data on dates where they didn't have any other events. We checked our backend service (gamesparks) for their account and could see that they were active players who had been using the app very recently. That is, after their last event was appearing in Big Query.
After investigating some more and started finding other users who had the same issue. They would be sending data without issue and then all of a sudden we would receive nothing from them, except from in_app_purchase events/notification events etc which are sent via a seperate service (app store etc) rather than the client.
After scouring our implementation and going over it line by line comparing to the samples/documentation we couldn't really see any issues, and even the automatic events (session_start etc) stop appearing. We made sure we were using the latest versions of the firebase SDKs etc in the hope it would fix it but it made no difference.
One peculiar thing is that when we find a in_app_purchase event from one of these 'broken' players, things like the user properties and default parameters for that player have changed from when they stopped sending data, so it seems like the lost data is somewhere but not being logged anywhere.
I was wondering if it was possible for specific users to stop their app sending any analytics data to Firebase via a device/google account setting?
While looking into the documentation we noticed that if Google Play Services is installed on the device, data is sent via that, rather than via the client/firebase sdk itself. Is there any known issue with players changing their Google Play Services settings that could cause something like this?
Wondered if this was a known issue but please let me know what other information you might need.
EDIT: I also wanted to mention that although we can't be 100% certain, we believe this is only happening to our Android users. We haven't found any iOS users that have the same issue.
Thanks,
Matt
I have some code I put in my react-native app a couple of years ago to support the forced migration of users from v2 -> v3 authentication. I am using the Web version of Firebase (6.6.0) in my app (NOT react-native-firebase).
I recently had a user try to log in with an old v2 token found in AsyncStorage (local storage). The app crashed with the following error:
TypeError · undefined is not a constructor (evaluating 'new t.default.Promise')
The crash occured on this line of the migration code supplied by Firebase. I'm guessing this migration code is no longer supported and I should just remove it from my app. But what should I do instead if a person tries to log in with a saved V2 auth token? Can she simply log out and log in again? Or does she have to change her password? Or does she have to create a new account, losing her old data?.
I don't have a way to replicate this situation since I have no way of logging in to v2 authentication. So I would appreciate a clarification from the Firebase team. Thanks.
TLDR; I've decided to remove the migration code from my app. When someone fires up the app and a legacy token is loaded from AsyncStorage, I simply delete the token and present the user with a login page.
I corresponded with Firebase auth support and include their answers below. First off, they suggested changing firebase.Promise in the code to Promise as firebase.Promise doesn't exist any more. This fixed the crash. Then, to test, I found an old simulator image that still had a legacy token in its AsyncStorage. Working with that, I found that the response to the XMLHttpRequest to the exchangeToken endpoint result in a null response (after approximately one minute). This tells me the endpoint is dead and there is no point in trying to query it, thus it makes sense to remove the migration code altogether from my app (even if the endpoint were working, a 2-year-old token surely would have expired.)
Then the question is what to do to enable users in this situation to upgrade gracefully. Firebase support suggested I should export the user (I have quite a few but I don't have a way to identify them definitively), then delete the user and import again. I couldn't believe all that hassle was necessary so I managed to find a couple of friends with old accounts. They had both forgotten their passwords, but after resetting, they were able to log in easily. So based on this limited testing, I think all that is necessary is to have them log in again. If that doesn't work they can contact our support and we'll go from there.
EMAILS FROM FIREBASE SUPPORT
I understand you, it must be a very frustrating situation, let’s try to find a solution together. I have checked your case and, as you have mentioned, the library is no longer actively maintained, so I’ll escalate your case to our engineering team in order to get any suggestions for your case, please wait a little until they can answer us.
The engineering team has answered and, unfortunately, they have said that old auth tokens have been unsupported for a long time, they suggested you forked the library and try to change firebase.Promise(), which does not exist anymore and then convert that to Promise(), but they can guess other errors will pop up and probably you will need to fix the code.
Thanks a lot for the clarification, I’m so sorry for my misunderstanding. If you want to delete the migration helper, as a workaround, you can export all the users (or only the users having the old token, if you have identified them), delete the users and import them again. This process will re-create the user and it will have the auth latest version because the user would be like a new user, with the same credentials and authentication methods. After that, the user on his side, needs to update the application, log out and log in again in order to update the token.
Please try to do the described workaround with a specific and identified user to limit the scope in case of fail and let me know how it goes.
Nice to hear from you again! Yes, the users will have the same UID and password, as you can see Auth export, the format contains those data and a lot of other more. Unfortunately, based on this, there is no way to know which of the accounts have an old auth token, so, in order to do a test and error approach, I suggest you try to do this with one user (identified old auth token user) to minimize unwanted results.
I have been introduced to Firebase a few days ago. Since then I have been trying to discover more features and usage of Firebase, in particular, the usage of the Firestore/Realtime Database.
However, as I am reading into more details, I start to think of some questions. I hope someone that is familiar with Firebase can help me answer them
As for User authentication, I understand that I can use Firebase Authentication where I won't see their real password. However, technically, everything that user stores in my Firestore would be visible to me since I am the owner of the Firebase.
For example, if I were to develop a note/chat app, in which the user can access their notes/chat on the iOS app and also Android. That means all their notes data would be saved in my database. If it happens to contain some private data, then I would be able to read it?
Even if I set security rules, that would be only facing client-side, whereas, for me, the owner of the entire firebase data, I could see the whole thing. Surely, as a customer, you won't want to use an app knowing that I can see everything you write
I am not sure if what I said is true or not. If true, is there a possible solution?
Both of your statements are correct. This happens in most of the apps-websites, the admin or some core developers have full access to the data. That's why privacy policy and GDPR exist. You must specify what data you collect and for what reason. If you intend to use your user data for any other reason you must inform them. Be aware that if you disclose any user information without his permission you can be held liable.
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).
I have an iOS App. I am trying to figure out how users move through my app. I am looking for a way to group all the events by some sort of session id. I assumed all fireBase events would have a session id. This does not seem to be the case.
I noticed there is a user_pseudo_id. I did some testing, where I logged an event that only I could ever have created. I noticed that sometimes the user_pseudo_id changes. Any idea what triggers a new id? I restarted and deleted/reinstalled the app many times so its not so easy to reverse engineer when user_pseudo_id changes
Thanks in advance
Andy
No, user_pseudo_id is not a session ID. It´s a unique ID "by app install". So as long as a user uses the same app instance ("Installation") without reinstalling it, the user_pseudo_id stays the same. It also doesn't change on app update. But it will change if you uninstall and reinstall the app.