I am using firebase sdk with Expo. In order to link users accross sessions and different devices we use the following setUserId(user._id).
This occurs after a user logs in and authenticates.
On logout I call setUserId(null).
My questions is: does setting the user id to null erase the previous user tracking data from GA. Should I be setting to null at logout? I can't find any concrete documentation on how setting to null impacts the data collection.
The goal is to track unique users across months, years etc. Is the above configured correctly or is there some issue with setting to null on logout.
You can remove the User ID by setting it to null or replace it with a new user ID. userID is just a user property that goes with all events after it is set so you need to set it to null when user logs out and set a new user ID when a different user logs in.
From documentation:
The value of the user property. Values can be up to 36 characters long. Setting the value to null removes the user property.
https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics#setUserId(java.lang.String)
Related
whether I use the lastonline endpoint https://api.roblox.com/users/[USERID]/onlinestatus/, or the new presence one https://presence.roblox.com/docs#!/Presence/post_v1_presence_users, it's returning different dates and times for a specific user, lastOnline": "2022-02-25T06:56:39.283Z" from the presence one, 25-02 is the date their account was created, & "LastOnline":"2022-08-08T06:32:36.567-05:00" from the lastonline endpoint, date is right, given that the user was showing online and in a game today on the website portal, but the time is wrong
I do have my GA4 property connected to Bigquery. I use my own user_id for tracking - its available once someone logs into my app.
For some reason, when I'm trying to build a report User ID string vs Unique Users, some ID's have more than 1 Unique User reported. Showing an example on the attached image.
Why is that and how I can fix that situation? I'd expect that one ID = One User
User ID vs Number of Users
I have a SQL Server table called AD where ad's to be viewed are stored as
create table Sponsors.AD
(
ADID varchar(40) primary key,
SponsorID varchar(30),
PurchasedViews int , --How many views the ad must reach before it is disabled
CurrentViewCount int, --Keeps track of how many views the ad has gotten
{...}
Active bit -- for easier checking of whether the AD still has clicks to give
)
This feeds into a webpage where, to access a feature, users first need to view an ad. Users can pick one ad from a menu that displays three options [they pick one, the ad's media is displayed and the feature is unlocked at the conclusion].
After they view the ad, its CurrentViewCount should be updated (increased by 1).
This is handled by a stored procedure that includes an update call for the table - separate from the stored procedure that fetches 3 ads at random for the option menu - but I'm looking for suggestions on how to solve the problem of synchronizing all concurrent AD views - as it could happen that
two or more users have the same ad in their 3-choice-menu
two or more users view the same ad at the same time
1 and 2 are not a problem on their own but they could be if the ad is one click away from it's set maximum.
One way I've thought to solve this is to set the active flag as false if the ad is one click away from it's target when it is displayed in the 3-option menu, and if the user does not click it, the flag will be reset to true -- but then I'd need to handle cases where the user exits the option dialogue or disconnects, times out, etc. I feel like there must be a better way.
Another suggestion I've heard is to automatically increase the counter when the ads are summoned to the 3-option menu but that's even more overhead than the other and suffers the same issues.
Locking the table is absolutely infeasible unless we wanted to only serve one ad view at a time - so I'm not even considering it.
I'm sure something like this has been discussed before but don't know what keywords/etc to search to find more on this.
I would not count the clicks within the same table... Could avoid your locking issues...
But, to get to your question: maybe you could handle this "fuzzy". Not the thight active=yes/no but rather something like an InactivityLevel together with a timeout.
As long as your flag would be true, everything is fine. If the counter exceeds, you switch to "No new visitors" and set a timestamp, so your add won't display in a new context. You set this to "inactive" after a given timeout.
I am designing an Banking application ,kindly help me to develop how can I block a user who is accessing his/her bank account concurrently from two separate browsers(systems).Suppose the user is withdrawing money from his/her account concurrently from two browsers at the same type ,how can I stop the user from doing so?
Add a flag column named SessionActive datatype int with the customer table.
Let the column value be 0 when the user did not log into his account anywhere.
If an user log into his/her account from a browser, he/she could be authenticated to his/her account only when the flag is 0 ie. SessionActive=0.
Update the flag to 1 ie. set SessionActive = 1 soon after he logged into his account.
Update the flag to 0 ie. set SessionActive = 0 when he/she log out.
If I have a website mysite.com/camera and I have users subscribe by their email address and I assign a 8 digit (numbers/letters lower cse)password. What code do I need on what pages so the login checks if its valid, then checks if that combination is already in use
The username password list will be kept on another page that needs to be checked for validity when the user logs in.
I would like to set this up so that if a customer shares his username/password that at most only one friend can view at a time.
No login is being used at this time, right now it is a public page.
You say the username password list is kept on another page. You should use a database such as mysql to store the username/password list. Create a table with fields userId, email, password, key - where userId is an identity field, and key is a guid.
When a user registers, create a new entry in the database with their email in the email field, password in the password field, and key guid defaulted to null or some initial guid value if you prefer not to allow nullable fields.
When a user logs in successfully (validates email/password against the database table), create a new guid, update the key field for the user with that guid, and drop a cookie for the user with the guid value. On every page on the site that requires being logged in, start by retrieving the user's guid from the cookie and querying the database to make sure an entry exists with that guid value. If there is no entry, expire the cookie and log the user out.
What will happen is that a user's friend who tries to log in will generate a new guid and in effect "steal" the login. The initial user will no longer have a valid guid cookie and will be logged out when they try to access a page.