Step 4: User properties and event properties

Welcome to Step Four of our Getting Started with Amplitude Series. This series is intended to help you set up Amplitude in the quickest, most optimal way possible, by walking you through the Amplitude data structure and helping you identify the data your product should be sending to Amplitude. Specifically, we'll cover:

0. Introduction & getting started
1. Instrumentation pre-work: Things to consider before deciding what data to send
2. Identifying your users: Requirements for properly tracking your product's unique users
3. Event data: How to identify the events or user actions you should track
4. User properties and event properties: The attributes you should send to upscale your analytics
5. Cross-platform instrumentation vs. separate platform instrumentation: The differences between them, and when you should choose one over the other
6. Dive into Amplitude and Snowflake, and explore powerful resources: Use Snowflake with Amplitude to answer key questions via SQL

(If you're a developer or product manager who will be responsible for instrumenting Amplitude, you should also read our getting started guide for developers.) 

In this article, we'll be going over properties. Properties are attributes that deliver additional context around your users and the events they trigger. There are two types of properties in Amplitude:

1. 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.
2. Event properties: These are attributes of a particular event. The value of an event property will reflect its state the moment its event was fired. For example, a property of the event JoinCommunity could be Type , which denotes the type of community joined at the time of that event. In a music app, a user can join a hip-hop community, rock community, and jazz community. The app will send a separate JoinCommunity event for each of those actions, and they'll all have a different value for Type .

NOTE: As this article is only intended as an introduction to the concepts of user properties and event properties, you'll need to read this article on user and event properties to fully grasp how properties behave, and how Amplitude handles them.

While properties are useful in all kinds of Amplitude analyses, they're especially helpful when creating an Event Segmentation chart.

You'll probably remember from the previous article in this series that it's not a good idea to track every event your customers can trigger. The same logic goes for properties as well. Only instrument the minimum number you'll need to answer the questions you're most interested in. When you've decided what those are, you'll be ready to plan your properties in Amplitude.

For more detailed recommendations and best practices on what user and event properties to track, check out our Data Taxonomy Playbook.

Next steps

When you're ready to move on, just click this link to go to the next step: deciding on a cross-platform implementation vs. separate platform implementation.