Skip to main content

Hi everyone,
 

I'm wondering if anyone knows of a solution for filtering user segmentations by the newest (current) user property in Amplitude. I've run into some use cases where this feature would be really helpful, but I'm not sure if it exists.


Amplitude's analyses are event-based, which means that filtering in charts is based on the properties at the time of the event. However, there are times when filtering or grouping by current user properties would be more useful.

 

Examples
Here are a few use cases where we've had a need for such filtering:

A) User origin data comes from a third-party integration - sometimes our engineering team has to enrich user properties after the actual time of the event. For example, an event resembling the sign-up of a user will not contain all properties needed to determine their origin. Thus, filtering in this particular event will return "(none)" for such users.

B) In-depth breakdowns of users' origin can become very detailed very quickly, and various combinations of different user and event properties are often required to classify different origin groups. Some of these events and user properties can still occur at a time after the event of interest, when not all data is available for filtering.

C) Some people who are not as familiar with Amplitude may find it counter-intuitive that filtering is based on the properties at the time of the event. It can sometimes be a challenge to communicate this effectively. For instance, if a user's primary location is in Europe, but they were traveling in the USA at the time of sign-up, they would ultimately appear as a user from the USA in their sign-up event, which from an analytics perspective is biased.

Current solutions

1) Cohorts. One solution is using cohorts, as you can define user cohorts where it's easy to mimic the current user property value and specify multiple user segments in your chart analysis.

The biggest drawback are:

 

  • Limited number of segments in charts (I think it was 9)
  • Performance and loading time is impacted when using multiple complex user segments


2) LookUp properties. Uploading a CSV file to lookup properties seems like a perfect solution but there are major drawbacks:

  • CSV file is limited  to 100MB and 1M of rows
  • Manual process that is heavy to maintain and scale

3) Channel classifiers. They don't solve the problem of filtering by the newest/current user property, but they do seem to be an intended solution by Amplitude for use case B). I believe it's worth mentioning here, however, the main drawback is:

  • Filtering is happening at the time of the event, i.e. not with the newest/current value


I realize that these may be edge cases that are specific to my workplace, but I'm curious if others have had similar needs or experiences. I would love to hear other people's opinions on this, as I may be missing something obvious. Thank you! :-)

Hey @aleksandar,

Thank you for your question and all the context. I’ll try my best to answer and hopefully help you move forward on this. 

Before we dive in I want to make it clear how user properties in Amplitude work:

User properties: A user property is a characteristic or trait of a user. Typically, user properties describe things like location, status (paying user vs free user, for example), details of how they access your product (device type, device family, operating system, etc). Because many user properties can change over time, they will always reflect the most-recently known state of that user. In other words, if a user most recently logged in from Mexico, that will be reflected in their location properties—even if that user typically logs in from a different country.

 

  1. This is a tricky one, and I personally don’t know a solution other than delaying firing the event until you have that user property available (depends on how long enrichment takes) or simply firing another similar event with the user property once enrichment is complete.
  2. I wonder if you’re referring to UTMs specifically? If you’re wanting to get very granular with UTMs and attribution I would recommend getting granular with how you track UTMs – making sure you track UTMs both as event and user props and maybe even add additional user props for e.g. ‘first touch’, ‘last touch’, etc. Our Marketing Analytics Browser SDK should help with some of that out-of-the-box.
  3. That is a challenge and I’m not sure I have a handy solution for that other than education. We have lots of resources like Amplitude Academy and our Professional Services teams. 

Hopefully that was a tiny bit helpful!

@franciskafyi Hi! Sorry for a very late reply, and thank you very much for the help!

 

  1. This is a tricky one, and I personally don’t know a solution other than delaying firing the event until you have that user property available

Yeah, our conclusion was also that this is the most optimal solution.

  1. I wonder if you’re referring to UTMs specifically?

Its mostly UTM parameters but some other properties too, although as you mentioned the suggestion for the A. it kind of feels that it would require the same solution.

  1. That is a challenge and I’m not sure I have a handy solution for that other than education.

Thank you for sharing, I’ll make sure to check these resources!


If we do figure out how to solve our special use case in a convenient way without engineering I’ll make sure to post it here!

Reply


Terms & ConditionsCookie settings