Data taxonomy playbook, part two: Events and properties

NOTE: This article is part two in Amplitude's data taxonomy playbook series. You can read part one here, if you missed it, or move on to part three.

In Amplitude, an event is any distinct action a user can take in your product (start game, add to cart) or any activity associated with a user (in-app notifications, push notifications). When deciding what events to track, it is helpful to think of event categories first.

In the previous article, we discussed the importance of determining your product's critical event. What's the one event your users must trigger in order to get value from your product? For a food delivery app, it would probably be placing an order. For a healthcare app, it might be starting or booking a session.

But it's not enough just to know how many people placed an order or booked a session. You also need to understand the factors that drive your users to enter that flow.

Next, identifying broad categories of events will help you conceptualize the major components of your product. It'll also help you better organize your events in the Amplitude UI. Make sure that each category tracked will contribute to reaching at least one of your goals or KPIs.

Sticking with the business objectives we defined in the previous article, event categories could be:

• Registration
• Onboarding
• Checkout

Prioritize your events

Once you have determined your overarching categories, drill down into the individual events in these groupings. Begin with the top priority events that align with your business goals and KPIs.

You do not need to track every event in your product; doing so will increase noise in your project and make your taxonomy harder to understand. We recommend instrumenting no more than 20 to 30 events in your first pass. With fewer events, you can think about and focus on what is truly important to track in your product. However, you do want to break down every event in a critical path (e.g. onboarding flows, purchase funnels) in great detail. Unless you carefully instrument every step, you will not be able to accurately see and analyze drop-offs. 

Adopt an iterative process when it comes to tracking data to Amplitude. Planning and instrumenting the top priority events first will ensure that you answer your most important questions first. This will also enable you to get familiar with the data and help shape the next iteration of tracking data.

While it's unrealistic to expect you to know 100% of the questions and hypotheses you'll be testing down the road, try to be as diligent as possible when selecting actions to record in Amplitude.

Common questions to consider are:

• Why are some users not completing onboarding?
• How many of my users convert into paying users?
• How many times are my users performing Event A vs. Event B?
• What are my new users doing after installing the app?
• Which groups of my users are engaging with feature C?

For example, if you want to see what your most engaged users are doing and how that is tied to retention, then it is important that you track those distinct user actions in your app ('add to cart, 'play stream', 'start game'). An event like 'updated settings page’ is usually not as critical, and can be prioritized for a later time.

Note that additional instrumentation of new events will take much less time compared to the first iteration, as the data governance process and the overall schema you create should remain relatively constant.

Naming your events

A clear and consistent nomenclature is critical to the success of your event taxonomy and the utility of your data. Clear event names are descriptive and denote what is occurring.

Consistency in naming means that all events share the same syntax. If you do not have your own standard syntax in naming data, we recommend (1) all lowercase—this removes the possibility of casing instrumentation errors, and (2) present-tense verbs—this minimizes any confusion. Regardless of the syntax you choose, the most important factor is that all events consistently follow your chosen syntax.

For example:

• Example: 'submit shipping address'
• Example: 'submit order'
• Example: 'land on order success page'

You can also prefix your event names with a category (noun) or use Amplitude's event categorization feature. This structure makes events easy to search. If you don't know which events are included in the checkout process, for example, you can simply type “checkout” and see every event that falls under that category.

You should also take into consideration the length of your event names. Concise event names make data much more readable and easy to understand.

For example, the event 'game: completed game: level 1,' could be restructured as:

• Event category: ‘game’
• Event: 'completed game'
• Event Property: 'level' = '1'

Make sure your nomenclature is consistent. If you send Amplitude 'Checkout Submitted Order' and 'Checkout submitted order', then they will be considered two separate events and cannot be merged.

NOTE: If you make an error in your nomenclature, you can always update the display name. Do not send a new event with the error corrected—Amplitude will log both the new and the old events as two different events. For more information, see our Help Center article on renaming events in Amplitude.

Page and screen view events

There is a decision to be made around whether to track events as actions that users have taken, or by the pages that they have loaded. Amplitude is designed for event-based analytics. However, you can choose to track page views (or screen views, in the case of mobile apps) as events. There are some tradeoffs, and you should understand best practices when it comes to setting up your page views.

Pageviews provide insights on how users navigate between pages. All pageview events are triggered from elsewhere in the platform, so keep in mind that page loads are almost always a result of a user clicking or landing on that page.

For example, if you are interested in how a user landed on a product page, you can instrument the following events:

• 'checkout: submit order'
• 'pageview: order complete'

Tracking page views also allow you to confirm that a user succeeded in some process in your product.

On the other hand, tracking by pageviews will inflate your event volume. You can decrease this by instrumenting only the critical page views, or by not tracking the click event that takes a user to the page.

Also, having lots of pageviews will create more noise in your organization’s Amplitude UI.

Best practices for tracking pageviews or screen views

How you structure your page view events, once again, depends on the questions you are trying to answer. 

Instrument a single pageview event

Instrumenting one generic event for multiple pages and capturing the difference in event properties works well for pages that are basically the same but still have some minor differences, such as levels in a game:

• Event: 'completed game page viewed'
  • Event Property: 'level' = '1'
• Event: 'completed game page viewed'
  • Event Property: 'level' = '2'

This approach also lets you easily see the breakdown of the different page types. You'll be able to do a group-by on the event property, and see the breakdown of the different events without having to add each individual event to your charts.

Visualization can be more challenging using this method, however, especially when looking at individual streams (you will see the following user journey: Completed Game --> Completed Game). You'll need to apply a filter to see the actual steps.

Instrument independent events for each page

Instrumenting multiple events for each page view you want to track works well for pages that are distinctly different from each other. It lets you easily see how your users are moving between pages, because this approach will be easier to read in Pathfinder and Pathfinder Users reports (since the page a user is on is not embedded in an event property):

• Event: 'product page view’'
• Event: 'basket page view’
• Event: 'checkout page view'

That said, aggregation of these events will be more tedious, since you will have to create custom events to group the events together.

You can even use a hybrid of both methods, depending on the nature of the page views you're tracking. For example, you could group similar pageviews into events that can be consolidated together into one (e.g. “loaded product details page”, where there are many different products that a user could view; “loaded onboarding page”, where there are several onboarding pages the user will navigate through). This method gives you the flexibility of being able to quickly see and understand user paths without having to drill into a specific event property, while also retaining some form of aggregation when analyzing the data.

Example:

• Event: 'viewed home page' (Option 2)
• Event: 'viewed product page' (Option 1)
  • Event Property: 'product id' = '129092'
  • Event Property: 'category' = 'Women's'

Properties

User properties are attached to individual users and provide context on the specific users they're attached to (subscription plan, location etc.), while event properties are attached to events and provide context on the action that was triggered (name of page/screen, selected login method etc.).

While it's certainly important to understand the flow of events for users within your application, without the ability to query on various states of events and users, your analyses will remain two-dimensional. It is essential that you track event and user properties if you want to understand your data at a more granular level and generate more refined analysis. 

Event and user properties can be sent along with every event to Amplitude. All these values will be tracked with the specific event or user they were sent with.

NOTE: User properties apply to the user for all future events until they are changed, while event properties are applied only to events at the time they are sent.

User properties

These reflect traits about an individual person using your product. You can instrument your own user properties that will help you analyze your users at a more granular level; these are called custom user properties.

Some examples of custom user properties are:

• Age
• Location
• Referral source
• Plan type
• Number of photos uploaded
• A/B testing variants
• Attribution
• Push enabled
• Number of units of in-game currency
• Current level in a game

The most important thing to remember is that these user properties reflect the state of the user and apply across all of their future events until the properties are updated again. You do not have to send user properties with every event, because Amplitude will automatically fill in existing user property values to an event until they are updated. And don't worry if you forget to apply custom user properties to your events—you can always update user properties at a later point using Amplitude's Identify API.

We recommend tracking a counter of critical actions as user properties—for example, number of orders placed/number of sessions booked. This will allow you to see the impact reaching or crossing a threshold of these events has on a user's retention/conversion rate/LTV. 

NOTE: Amplitude only shows the first 1000 user properties in a project. For more information, see our Help Center article on data limits in Amplitude.

If you're using Amplitude's SDKs, you'll be tracking the following user properties by default:

• Platform
• Device type
• Device family
• Country
• City
• Region
• Start version
• Version
• Carrier
• OS
• Language
• Library

For more information on these properties, see this article in our Help Center.

Suggestions for user properties

If you do not have your own standard syntax in naming data, we recommend (1) all lowercase—this removes the possibility of casing instrumentation errors—and (2) if the property is not a string value, it should refer to the property's value type (for example, is subscriber = true/false , num of purchases = [1. 2. 3]). This will help minimize any confusion.

Regardless of the syntax you choose, the most important factor is that all events consistently follow it.

User Properties	Notes
registration status	Only assign user IDs to users who have fully onboarded or registered. Amplitude can track anonymous users with unique Amplitude IDs.
user type / status	'Free', 'Paying', 'Seller', 'Buyer'
push notification status	Whether a user has push notifications enabled or disabled.
num total of Critical Actions performed	A running counter of the number of times a user has performed the critical event. Use the increment function of the Amplitude SDK to add values directly to the property.
signup date	When the user first signs up for your product.
app install date	Date when the user first installs your product. In Amplitude, you can filter by new users (users who used your product for the first time) by default.
num total of sessions	Tracking the total cumulative number of sessions a user has had in your product.
last seen date	The last data user was active in your product.
AB testing variants	More information about how to store AB test data in Amplitude can be found here.
customer profile information	Any information users can put in their profile. Always be aware of your users and the privacy policies you have in place. It is also a good idea to check that all data you are tracking is legally compliant.
User properties for values that are in flux (e.g. followers) or interesting lifetime value counts (e.g. total number of orders, total revenue)	Having a user property for these values will cut down on your analysis time for two reasons: you will not have to define a cohort around these properties, and you will be able to easily segment on them. With properties in flux (e.g. followers, friends), there is no easy way to sum up the “Follow” and “Unfollow” events to get a count for that user, so having a property that represents this number is important. You can just add one to the value of these properties each time the event is fired. See the relevant SDK documentation for more information in Javascript, iOS, or Android.

Event properties

Event properties describe the properties, or attributes, of an event. For instance, if 'Swipe' is an event you are tracking, the event property ‘Direction’ could have the values ‘Left’ or ‘Right’.

These properties depend on the type of app you have and the specific information required to understand a particular event. Amplitude does not track any event properties automatically, so you will have to create custom event properties in your instrumentation.

General event properties we have seen include description, category, type, duration, level, % completed, name, count, source, previous page/screen, from, number, lives, authenticated, error, rank, action, and mode. Take advantage of event properties to reduce the number of events you're tracking without sacrificing the detail you need. See the "When should you create a new event or a new event property for similar user actions?" section of this article.

 

One common use case for event properties is tracking values that must be held constant to count towards funnel conversion. For example, an e-commerce company might be analyzing the conversion on the critical path below:

• Step 1: 'Product Page Viewed'
• Step 2: 'Product Quantity Selected'
• Step 3: 'Product Added to Cart'

Here, users should count as converted through the funnel only if they triggered the event on the same product. To ensure this, instrument the event property 'Product ID' and require the funnel to hold this value constant. Every event in the funnel must have that property in order for the holding constant feature to work.

In funnels, you can only hold one property value constant. So for this e-commerce example, using two custom event property values—like 'Property ID' and 'Cart ID', for example—would work best. Then, use two funnels to track if a user has viewed and purchased the same product.

A pair of examples:

Adding product to cart funnel

• Step 1: 'Product - Page Viewed'
  • 'property id' = '3345'
• Step 2: 'Product - Quantity Selected'
  • 'property id' = '3345'
  • 'quantity' = '1'
• Step 3: 'Product - Added to Cart'
  • 'property id' = '3345'
  • 'quantity' = '1'
  • 'cart id' = '1299'

Purchasing cart funnel

• Step 1: 'Cart - Viewed'
  
  • 'cart id' = '1299'
• Step 2: 'Cart - Start Checkout'
  • 'cart id' = '1299'
• Step 3: 'Checkout - Address Added'
  
  • 'cart id' = '1299'
• Step 4: 'Checkout - Shipping Method Selected'
  • 'cart id' = '1299'
• Step 5: 'Checkout - Payment Added'
  • 'cart id' = '1299'
• Step 6: 'Checkout - Complete'
  • 'cart id' = '1299' 

Example

Let’s look at the onboarding example described above. Imagine you want to know if your onboarding is too long and causes users to drop off during onboarding.

You may have a hypothesis that users who are invited by friends are more likely to be retained. To test this, instrument a custom event property called 'Source':

You may know that most of your users drop off in your onboarding flow while watching your game tutorial. You have a hypothesis that younger users prefer not to watch long videos, and this causes them to drop off. To test this, you can instrument a custom user property that tracks a user's age:

To better understand the drop off of your onboarding process, you can look at every step in the flow analyze the conversion based on different properties.

Best practices for properties

• Only instrument properties you think you will use. Having too many properties makes analysis more difficult.
• Before you include sensitive information (email, addresses, etc.), make sure it complies with the privacy policies for your product.
• Enable the UTM and referrer user properties to better understand where you users come from on the web.
• Instrument key properties on every event in a critical path.
• Consistency in naming means that all properties share the same syntax. 

When should you create a new event or a new event property for similar user actions?

Suppose you have two user actions that could either be two separate events, or a single event with two separate event property values. Is the fundamental action the user is taking the same in both cases? If so, consider instrumenting them as one event separated by an event property.

Option 1

• Event: 'Purchase Coins'
• Event: 'Purchase Gems'

Option 2

• Event Property: 'Type' = {'Coins', 'Gems'}
• Event: 'Purchase'

How important is it to monitor the flow of events from 'Purchase Coins' to 'Purchase Gems'? 

If it's important enough, it'll be easier to read as two separate events in Pathfinder, Pathfinder Users, Show Users Streams, and Show User Paths. On the other hand, if the purchase action is the same regardless of whether they purchase a coin or a gem, and you just want to occasionally filter on it, instrument it as one 'Purchase' event with an event property that accepts the values 'Coins' or 'Gems'.

Broadly speaking, the general rule of thumb is that if you want to see how users move between two critical actions, then create two separate events. Having one event is good for two similar user actions.

Identifying users

Tracking unique users is a complex process. Users can log in and out of your product, browse anonymously, and use multiple devices. In order to keep an accurate count of users, Amplitude has a uses a combination of device IDs, user IDs, and Amplitude IDs. Read more on how Amplitude counts and tracks unique users here.

Products with a login system are able to track users even if they switch devices. Though assigning user IDs is optional, we recommend that products with a login system or a UUID (unique user identifier) system assign a user ID.

The benefit of an assigned a User ID is that Amplitude can match events across multiple devices under the same user. A user ID does not need to be assigned immediately. Do not assign anonymous users user IDs. A user's event data will be merged on the backend so that all anonymous events up to the point of user ID assignment are connected to the assigned user ID (assuming the device ID is consistent).

Best practices for setting user IDs

• Do not set user ID if you cannot determine it. For example, setting the string "None" as a user ID for multiple users will group all events under that user ID together, as if it represented a single user. You can always set the user ID later. Amplitude has built-in logic that will merge anonymous events to the correct user later (see Example 2 in our Tracking Unique Users article).
• Do not assign a user ID that might change. If someone’s email can change within your app, tit's a poor choice for a user ID, because Amplitude will mark the person as a new user if they change their email.
• Assigning user IDs properly can be tricky if you have a system that does it server-side. If you feel that you are running into issues assigning user IDs, please contact us here.

Next: Industry-specific tips and recommendations