Hey, Is it possible to have an assignment conditio...
# ask-questions
p
Hey, Is it possible to have an assignment condition that is not verified for users that are already assigned to the experiment? We have an experiment that depends on the user not having a user id. The thing is that once they log in, they are unassigned from the experiment. I would like to be able to change our condition so that those who have a user id but were assigned before (traffic is split based on another id), keep their assignment
f
often event trackers will have an anonymous id or similar that will not change on login
if you use that as your hashing attribute it will work as you want
p
I am using something of the sort. The thing is that since I am using the condition attached in the image, they are unassigned once they sign in. So I wonder if it's possible to change this condition to be something such as: If
userId
is undefined or the
sessionId
is part of an experiment variant, split traffic 50/50, so that I can keep getting the variant value even after sign in. Is this possible?
f
are you not wanting to expose existing logged in users?
I have a feeling you can get what you want by just targeting to sessionId (assuming your okay with that level of stickiness)
p
Exactly, I do not want to target existing logged in users. Okay, thank you. I will look into it
f
Yes, then I think that will work
With the rule you have, when the user logs in, they won’t trigger the trackingCallback - but it will have fired previously when userId is null, so it will still count. Btw, you could also create a boolean attribute called isLoggedIn and target to that to make it easier if you intend on doing more of these.
p
Will do so, thank you. Just to make sure I understood, you suggest just splitting traffic using the sessionId, right? Wouldn't this consider the existing logged in users? On the tracking-side, I could use the previously fired event, but I would not be able to get this in the app without using some sort of storage, right?
p
@plain-jordan-57405 have you figured this out -- we have a similar issue
f
there are a few ways to handle this situation - one would be to target to session id or another anon id, and then filter out the logged in users on the reporting side. Another would be to use the logged in/out state as an attribute, and target to all anon ids but exclude ‘logged in’ users