Updating user properties in Firebase takes too long - firebase

I am using firebase for my mobile Android and iOS app and I want to send push notifications based on specific user properties that I set (push notifications topics don't work for my use case).
So now when I set a user property in via the app it takes forever for that change to be propagated. For example, I do have a property club which was set to a value x. I can successfully send push notifications to those users. Now when I change the value to club = y and this change will take forever to go through. Which means that all notifications sent to club = x will still be received on those devices.
To set user properties I use the firebase_analytics plugin for flutter as follows:
FirebaseAnalytics analytics = FirebaseAnalytics();
analytics.setUserProperty(name: 'club', value: 'some value')
Since I am using the user properties to set notification settings this delay is not acceptable. Does anyone know how to make this work with firebase? Or are there any guarantees at least after which amount of time these user properties get updated?
I don't want to use other services such as OneSignal etc. but stay in the firebase ecosystem completely if possible.

Per the Analytics doc
Note: Once the property is registered, it can take several hours for data collected with the property to be included in reports. When the new data is available, the user property can be used as a report filter or audience definition.
Which is what I assume is the cause for your delay.
Topics would be the way to go, but since as you mentioned it is not viable, you could set custom claims for the user and filter it that way as mentioned here but performance might not be great since you have to retrieve all your users first.
You could create a club collection in Firestore and for each clubName document have a toNotify subcollection containing the userIds as document name. In this context users would remove themselves from the previous clubName and create a new doc in the newClubName.
Keep in mind this has the potential of causing quite a lot of read operation depending on the frequency you send notifications and the size of the your userbase.

Related

In-app messaging and Targeting users by audience/User properties

I would like to run a new firebase in-app messaging compaign based on a new user propertie that I just set.
I would like to know, if targeting a specific dynamic audience based on this propertie, will include also users that will become part of it in the future depending on the running period of the compaign, or should I launch a new compaign each time to cover them.
thanks

GA 360 export to Big Query

We have just linked our GA360 account to BigQuery but we noticed from the docs that the userId doesn't get exported. This is really annoying as one of our main use case was to join the userId with our CRM system.
Why is Google not exporting the userId ? Is there workaround ?
Thank you for your answers.
The solution is to create a User level custom dimension and pass your user's ID into that as well.
There's no restriction on exporting your custom dimensions, and these are exported to BigQuery.
Enjoy :)
How User-ID works
User-ID enables the association of one or more sessions (and the activity within those sessions) with a unique and persistent ID that you send to Analytics.
To implement User-ID, you must be able to generate your own unique IDs, consistently assign IDs to users, and include these IDs wherever you send data to Analytics.
For example, you could send the unique IDs generated by your own authentication system to Analytics as values for User-ID. Any engagement, like link clicks and page or screen navigation, that happen while a unique ID is assigned can be sent to Analytics and connected via User-ID.
In an Analytics implementation without the User-ID feature, a unique user is counted each time your content is accessed from a different device and each time there’s a new session. For example, a search on a phone one day, purchase on a laptop three days later, and request for customer service on a tablet a month after that are counted as three unique users in a standard Analytics implementation, even if all those actions took place while a user was signed in to an account. While you can collect data about each of those interactions and devices, you can’t determine their relevance to one another. You only see independent data points.
When you implement User-ID, you can identify related actions and devices and connect these seemingly independent data points. That same search on a phone, purchase on a laptop, and re-engagement on a tablet that previously looked like three unrelated actions on unrelated devices can now be understood as one user’s interactions with your business.
From Google analytics about the userid feature the user id is used in the background by google analytics to analyse your data.
If you want to analyse on the user id you can just add it as a custom dimension you will then be able to see it.

Client ID and/or User ID - which to use?

Background of my specific environment: I am trying to set up GA to track the user journeys around an iOS native app written in React Native. The app is in-house only and all users consent to being tracked in this way.
As I understand it, the measurement protocol allows either Client ID (cid) or User ID (uid). In the docs, both are optional, but at least one is required. Makes sense so far. Client ID is an anonymous UUIDv4 that tracks a browser or device, but not necessarily a user. User ID on the other hand is some uniquely-identifying value for a user, but may cross devices/browsers.
Initially I wrote my application using cid (as I hadn't yet read the docs on uid). Every time a user logged in the user's uuid would be stored and sent as the cid parameter. I also used session control sc. This worked - I saw sessions coming in, the User Explorer showed me the individual user uuids and sessions, etc. But upon rereading the docs, this seemed like an incorrect use of cid. It seems like cid is meant to be consistent and not something that changes as you log in and out.
As people on my app can log in and out (and possibly will - staff members may well share devices), using a long-lasting cid that is specific to the device won't allow me to track the habits of individual users and changing it per login-session, as mentioned above, feels wrong.
So I switched out cid for uid. The docs say both are optional and one is only required if the other is not used, so I figured I could just use uid and use the user's uuid in that field and it's otherwise act the same.
However, when doing it this way no hits seems to be registered at all - in "real time data" as well as the User Explorer.
Am I doing something wrong or is this by design? (If by design, are the docs wrong to say cid and uid are both optional or am I reading it incorrectly?)
Either way, best-practices-wise, do I:
Just go back to using an ephemeral cid that only changes when people log in and out. Individual sessions in the app don't change the cid but I do use sc to explicitly start and end sessions by navigation inference (click 'home' = sc=end, navigate from 'home', sc=start).
Use uid as I am trying to (i.e. switching out the current cid for uid), but also include a random cid that never changes (regardless of session lifetime, logging in and out, etc.).
Something else?
I have seen this question and its answer but it does not really answer my actual question regarding how cid and uid should actually be used, and if my issue is me or the way that GA works.
Oki so client-id is randomly generated value and must be sent with all hits.
In a non-User-ID-enabled view, Client-ID is used to calculate unique users. In a User-ID-enabled view, User-ID is used to calculate unique users
In reference to your app, you can send the unique Device id value in place of random value for client-id. This will resolve all your problems and ensure that the client id is sent with all the hits, otherwise it wont get registered in GA

Firebase Analytics multiple table events

I am using Firebase Analytics to send some custom information from inside of the app iOS and android app. For some reason, when i see the values inside of Google BigQuery, I see the data was pushed twice so I have too many repetitive values. How could I stop it from doing that? On iOS, I will sometimes see it posted 3 or 4 times. Here is a quick snippet from the android side:
mFirebaseAnalytics.setUserProperty("user_email", user.getEmail());
mFirebaseAnalytics.setUserProperty("location", locationValue);
When you set user property the value is persisted and uploaded with every subsequent data upload. If you like to record something that happens at given moment in time you should log an event.
See Set User Property documentation for more details.

How to set Gender User Property manually in Firebase Analytics?

Firebase collects some user properties automatically but the question is, how does Firebase know what the user's gender is?
I tried to set them programmatically but it didn't help because there's no data about genders on the Firebase Console. In other word, setting predefined user properties programmatically could not be collected by Firebase.
mFirebaseAnalytics.setUserId(Long.toString(user.id));
mFirebaseAnalytics.setUserProperty("Gender", user.sex);
mFirebaseAnalytics.setUserProperty("Age", Integer.toString(age.getYears()));
Note: I'm using free plan and I waited for +24 hours to see the result.
Firebase collects some user properties automatically but the question is, how does Firebase know what the user's gender is?
From this help article:
Demographics and interests data comes from anonymous identifiers for mobile apps (i.e., Advertising ID for Android and IDFA for iOS).
You cannot set or override the built-in user properties yourself, however if you believe you have better data for each user you can create a custom user property and set that yourself to be used separately to the built-in value.
User properties created in code need to be registered in the Firebase console to view them there. The default user properties (Age, Gender etc) however cannot be registered in the console, since they already exist.

Resources