Note: The workaround we currently have is to keep track of the user IDs and continuously add the new IDs to the list as employees/applicants pop up. This works fine, but is not scalable and is a pain to keep on top of. I’m hoping to find a more automated solution. 

Hey @jguerinet ,

From what I understand of your use case, the easiest way would be to use a filter on that CURRENT user property value in your event segmentation chart. This will filter out all the events which the user has performed on any other value for that user property and only give you events where the value is CURRENT.

This article outlines a few other ways you can achieve this, one of which you are already using i.e Maintaining User Lists.

Let me know if I have interpreted your question correctly. Hope this helps!

Hi Saish, 

Thanks for your quick response. I believe you may be slightly misunderstanding my use case, but I appreciate the effort. Let me first try to recap what I believe you have suggested to make sure I understand what you are suggesting: 

If I have a User with events, A, B, and C, and I set their “Tag” user property to “1” between events B & C, then if I try to look at all users with tag “1” who did event A this user will not show up. However if I look at all users with tag “1” who did event C they will be included. If I understand what you are suggesting, you are saying to filter out the events to only keep the ones that have the current user property “1” associated to them, i.e. get rid of events A & B in this case and only keep event C as this will allow me to only look at the events with the right tag. Am I understanding you correctly?

If so, my use case is slightly different. Let’s take a more concrete example. I’ve got a user who performed the “CreateAccount” event, the “Login” event and the “Logout” event. I realized that this user was a job applicant after the “Login” event and before the “Logout” event, so I set their “Tag” user property to “Applicant” at that time. Now, if I look at all the users who do NOT have the “Applicant” Tag user property and who performed the “Logout” event, this user will be excluded, as expected. However, if I look at all users who do NOT have the “Applicant” Tag user property and performed the “CreateAccount” event, this user will be included as they did not have the “Applicant” tag user property set at the time of the “CreateAccount” event. What I am looking to do is find a way to essentially filter events before a specific user property was set based on a current user property. So in this example, I am looking for a way to filter out all users who CURRENTLY have the “Applicant” tag user property and who performed the “CreateAccount” event, regardless of whether they were marked as an applicant when they performed that event. The use case is fairly simple to understand: Someone creates an account and performs some actions in our app, I realize afterwards that this person was a job applicant, and I therefore want to exclude all of their activity from any analysis, no matter what their user property was set to during the time of that event. I cannot set the “Applicant” Tag user property when they create an account because I do not know they are an applicant until after they’ve created an account. Does this make sense?

Hello @jguerinet,

What I am understanding is you want to filter out internal users. However, adding a property to the right module is not enough because some events could be performed before the property was set for the user.

One of the features customers use for this case is, Cohorts, where you can filter for users who have the most recent property value and you would be able to add this cohort to the right module to filter the users out. Here is the documentation on this.

As @Saish Redkar has recommended the other options for filtering out internal users can be found here.

Hey @jguerinet ,

Thanks for elaborating your use case.

As Eddie suggested, the most recently clause in the cohort definition should be able to help you answer your question.

Hello Eddie & Saish, 

Thank you both for your time and patience, I appreciate your help! Indeed, it looks like cohorts are the way to go for this. 

Cheers, 

Julien