Properties are attributes that provide additional context around your users and the events they trigger. There are two types of properties in Amplitude:
- User properties: User properties are attributes of the users and reflect the current state of the user. For example, "age" can be a user property. They are useful because it is possible for user properties to change over time and as such, these properties would not be unique to events and are instead tied to the user.
- Event properties: Event properties are attributes of a particular event and reflect the state at which the event was triggered. For the event 'JoinCommunity', an event property could be 'Type' which denotes the type of community joined at the time of that event. A user can join a pop community, rock community, and jazz community; and this data is specific to each of those 'JoinCommunity' events. The type of community joined provides more information about the event, not necessarily about the user because a user can join many different types of communities.
Table of Contents
- User Properties
- Event Properties
- Hiding Properties
User properties are attributes of the user and are sent with every event. Properties intrinsic to the user, such as age or gender, should be set as user properties. These reflect traits about an individual person using your product. Some examples of custom user properties you can send Amplitude are age, gender, email, locale, referral source, plan type, number of friends, current level in a game, etc. '[Amplitude]' will appear next to user properties that our SDK tracks automatically. Custom user properties that you choose to track will not have '[Amplitude]' prefixed.
Amplitude tracks the following user properties by default from our SDKs:
- Device Type
- Device Family
- Start Version
You can find the definitions of each property here.
Note: Our customers typically implement at most 20 user properties on top of what Amplitude automatically tracks.
Updating User Properties
User properties reflect the state of the user and apply across all of their events moving forward until the properties are updated again. You do not need to send custom user properties with every event; once a user property is set, the set value will persist and be applied to all subsequent events (until the value is changed). Do not worry if you forget to apply custom user properties to your events, as you can update user properties at a later point using our Identify API.
When a user property changes, all subsequent events will be associated with the new user property. For example, if a user has the user property 'SongsPlayed' = '45' and a few minutes later they perform 'PlaySong' again, 'SongsPlayed' will now equal '46'. 'SongsPlayed' will equal '46' for all subsequent events until the property is updated again.
At 4:30pm, 'PlaySong' was fired with 'SongsPlayed' = 45.
At 4:04pm, 'PlaySong' was fired with 'SongsPlayed' = 46.
Furthermore, the top of a user's activity page will display the most recent user properties.
On the day a user property changes, the user will be counted as having been in both the old user property category and new user property category. For example, let's say on July 1 a user logs into your game app version 1.0 and plays a few games. On the same day, she updates the app to version 2.0 and plays some more. If you segment the daily active user graph by version and compare version 1.0 and 2.0, that particular user would appear as a user in both segments (unless you segment on "most recent" properties). However, on July 2 and onwards she would only appear in the version 2.0 segment until she updates to a newer version.
When applying a user segment to a chart, the chart will show none values if the user had that a value of none at the time of the event. So if a user initially had 'isPaying' = '(none)' for their first 'PlaySong' and later had 'isPaying' = 'False' for the next 'PlaySong' event, the user will show up in both buckets. However, when you look at the User Activity page, their most recent value for that property will show up because you are now looking at the data at a user level, no longer at a event level.
Similarly, the CSV download from any chart will display the user's most recent value. This does not mean this was the user's value at the time they performed the event in the chart, so it is likely these values will be different from the chart.
Applying User Properties to Events
User properties are applied in the following order:
- User property is updated before an event: the property's value is updated in the user property table and reflected in the UI via the event that follows the update.
- User property is updated after an event: the property's value is updated in the user property table, but it is not reflected in the UI until an event is sent.
Therefore, in order for a new user property value to be reflected in the UI, an event must follow the update. You can also use the Identify API to update user properties, but updates this way still follow the same above logic. Please read and understand the Identify API document fully before using it.
When a user property changes all events going forward will be associated with the new user property. On the day a user property changes, the user will be counted as having been in both the old user property category and new user property category (thus counting twice for that day). For example, on July 1 a user logs into your game app version 1.0 and plays a few games. On the same day he updates the app to version 2.0 and plays some more. If you segment the daily active user graph by version and compare version 1.0 and 2.0, that particular user would appear as a user in both segments. However, on July 2 and onwards he would only appear in the version 2.0 segment until he updates to a newer version.
Event properties are attributes of events and each particular event will have its own set of event properties. These properties highly depend on the type of product you have and the specific information you think is necessary for to better understand a specific event. For instance, if 'Swipe' is an event that you are tracking, then the event property 'Direction' could have the values 'Left' or 'Right'.
Some example event properties are: description, category, type, duration, level, % completed, count, source, status, number, lives, authenticated, error number, rank, action, and mode. Leverage event properties to reduce the number of events you are tracking and/or better analyze your events.
You can hide old or buggy properties in your project's settings page. Hiding event or user properties only hides them from appearing on the platform UI. You can always unhide the properties.