The most important step before you begin sending data to any event-based analytics platform is identifying which events to send. The importance of good instrumentation cannot be overstated, and it is the foundation for easy and insightful analysis. Instrumentation issues such as omitted events, poor naming, and misuse of properties can lead to complications and prevent you from obtaining the full value of your data.
Before you begin instrumenting your application on Amplitude, we recommend that you read our Quick Start Guide.
Important Note:
- Some of the events and user/event properties in the article are Title Cased for better readability. For Amplitude's recommend naming convention, please see the associated sub-section.
Table of Contents
- Pre-Work - Define Business Objectives
- Getting Started - Align With Business Objectives
- How Should I Prioritize My Events?
- What Are My Critical Paths?
- Events: How Should I Name My Events?
- What Properties Should I Track?
- User Properties
- Event Properties
- Should I Create a New Event or a New Event Property for Similar User Actions?
- How to Identify Users?
- Tips for Different Industries
- Sample Event Taxonomies
Pre-Work - Define Business Objectives
What are you and your team working towards? What is your overall goal? Why would you like to use Amplitude in the first place? Think of the business objectives that Amplitude can help you achieve. Here are some typical goals our customers focus on:
Once you have your overarching goal established, how can you work towards this? Establish the key performance metrics (KPIs) that you are focused on improving in order to achieve your goal.
Let’s say your business objective is to optimize conversion. Your KPIs may be:
- Improving onboarding conversion
- Improving checkout funnel conversion
It is important to define these before you start thinking about your data taxonomy so that you can ensure you are sending the right events in order track your KPIs and achieve your goals.
Getting Started - Align With Business Objectives
Projects
So, what is a project? A project is a destination that collects all of your event data from your product. You can have multiple projects within your Amplitude organization. However, it is extremely important that there are a minimum of two projects in your Amplitude organization: a test and production project. You should always heavily QA your instrumentation in your test project before sending it to your production project in order to catch any instrumentation bugs and keep test data separate from production data. All data sent to one project will be independent of each other. Your total number of projects will depend on your product(s) and your business objectives.
One Production Project
If one of your goals is to be able to analyze users across platforms (e.g. being able to see the full story of User A who did Event X on iOS and Event Y on web), then it is critical that you instrument under one project.
Important Note:
- Currently, Amplitude does not support out of the box cross-project analysis and all data is kept separate between projects unless your organization has purchased the Portfolio add-on.
Multiple Production Projects
We recommend multiple projects for companies that:
- Offer multiple different products, e.g. Game A vs. Game B or Rider App vs. Driver App
- Have fundamentally different experiences across platforms (web vs mobile)
- Have individual teams responsible for each platform are independent
This will keep your data taxonomy clean and easier to understand.
Events
So, what is an event? An event is any distinct action a user can perform in your product (e.g. start game, add to cart) or any activity associated with a user (e.g. in-app notifications, push notifications). When deciding what events to track, it is helpful to think of event categories first.
Start first by determining what your product's critical event is. What is the one event that your users need to perform to get value from your product? For a food delivery app it would probably be placing an order. For a healthcare app, it would be starting or booking a session. When you have your critical event you can then go through and determine what types of events you'll need in order to best understand that critical event and the flows surrounding the event. It is not enough just to know how many people placed an order or booked a session, but also what factors were causing them to enter that flow.
Next, identifying broad categories of your events will help you conceptualize the major components of your product. It also will allow you to better organize your events in Amplitude’s UI. Make sure that each category tracked will help towards accomplishing at least one of your goals or KPIs. Sticking with the business objectives we defined in the above pre-work section, event categories could be:
- Registration
- Onboarding
- Checkout
Once you have determined your overarching categories, start to 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 as doing so will increase noise in your project and make your taxonomy difficult to understand. We recommend instrumenting no more than 20-30 events in your first pass. Having fewer events enables you to think about and focus on what is truly important to track in your product. However, you do want to detail out every event in a critical path (e.g. onboarding flows, purchase funnels). Without carefully instrumenting 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.
When deciding on events to track, keep in mind the questions you want to answer and the hypotheses you want to test. While we would not 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?
How Should I Prioritize My Events?
Chances are you’ll always be constrained on resources and unable to dedicate the time to track all the events you want to track. Even if you’re not constrained, we actually don’t recommend tracking all the data you can possibly track; we only recommend tracking data that is relevant to your use cases and KPIs, and we recommend doing so in an iterative manner.
Once again, make sure to include all of the events that make up your critical paths. Your most critical events will depend on (and mostly align with) the business questions you want to answer.
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 (e.g. '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.
It is important to 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.
What Are My Critical Paths?
Every application has critical paths that a user can move through. Critical paths are a sequence of actions a user takes that align with your product’s purpose. An example of an e-commerce product could be:
Search → Browse Products → Add to Cart → Checkout → Order Confirmation
For a gaming product, a critical path may begin when a user opens the app, is prompted to register, and then taken through a game tutorial.
You can break this onboarding process or path into a series of events: 'App Open', 'Registration - Personal Info Populated', 'Registration - Avatar Selected', 'Registration - Complete', 'Game Tutorial - Started', and 'Game Tutorial - Watched'.
Once that is done you can go through and determine what type of tracking you'll need in order to best understand that critical event and the flows surrounding the event (it is not enough just to know how many people placed an order or finished the tutorial, but also what factors were causing them to perform that critical event.
Page and Screen View Events
Amplitude is a platform 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 best practices when it comes to how you set up your page views. Again, it all comes down to your goals and how tracking page views help you achieve them. There is a decision to be made around whether to track events as actions that users have done or by the pages that they have loaded.
Positives (+)
Pageviews provide insights on how users navigate between pages. Implicit in this is that all page view 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 to see how a user landed on a product page, then 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.
Negatives (-)
On the other hand, page views will inflate your event volume. You can decrease this by only instrumenting the critical page views or by not tracking the click event that takes a user to the page. In addition, having lots of page views will also create more noise in your organization’s UI in Amplitude.
How to best track page/screen views?
How you structure your page view events, once again, depends on the question you are trying to answer.
Option 1: One Page View Event
Instrument one generic event for multiple pages and capture the difference in event properties.
- Event: 'completed game page viewed'
- Event Property: 'level' = '1'
- Event: 'completed game page viewed'
- Event Property: 'level' = '2'
This is good for pages that are inherently the same but have minor differences, such as levels in a game. You can easily aggregate all page load events together. This approach also enables you to easily see the breakdown of the different page types. You will be able to do a group by on the event property with this method and see the breakdown of the different events without having to add each individual event to a chart.
Visualization can be more difficult using this method, however, especially when looking at individual streams (you will see the following user journey: Completed Game --> Completed Game) and will need to apply a filter to see the actual steps.
Option 2: Independent Event for Each Page
Instrument multiple events for each page view you want to track.
- Event: 'product page view’'
- Event: 'basket page view’
- Event: 'checkout page view'
This instrumentation is good for pages that are distinctly different from each other. It also allows you to easily see how your users are moving between pages because this approach will be easier to read in Pathfinder and Pathfinder Users reports as the page a user is on is not embedded in an event property. That said, aggregation of these events will be more tedious as you will have to create custom events to group the events together.
We recommend grouping similar pageviews into events that can be consolidated together into one (I.e. “loaded product details page”, “loaded onboarding page”). This method gives you the flexibility of both being able to quickly see and understand user paths without having to drill into a specific event property while also being able to already have some form of aggregation when analyzing the data.
For example:
- Event: 'viewed home page' (Option 2)
- Event: 'viewed product page' (Option 1)
- Event Property: 'product id' = '129092'
- Event Property: 'category' = 'Women's'
Events: How Should I Name My 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. We recommend a present-tense verb + object syntax with spaces and all in lowercase for clarity on when the event triggers. 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 and enhances your discoverability. If a user doesn’t know what events are in the checkout process, they can simply type “checkout” and see every event that falls under that category.
Consistency in your 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 (some of the events in this article are Title Cased for better readability), 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.
You should also take into consideration the length of your names, concise event names will make data much more readable and easy to understand. A common mistake and result for long event names is because of the granularity of the event. 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.
Important Note:
- If you make an error in your nomenclature you can update the display name. Do not send a new event with the error corrected as both the new and the old events will be logged as two different events. See how to rename events here.
What Properties Should I Track?
Tracking event and user properties allow you to dive deeper into your analyses. While it is important to understand the flow of events for users within your application, it is also crucial to be able to query on various states of events and users. It is essential that you track event and user properties. Having detailed user properties lets you review your data at a more granular level, leading to more refined analysis.
User properties are attached to users and provide context on the user itself (his subscription plan, location etc.) while event properties are attached to events and provide context on the action that was performed (name of page/screen, selected login method etc.).
Event and user properties can be sent along with every event to Amplitude. All of these values will be tracked with the specific event they were sent with and the user properties sent will also update the user's user properties with the most recent values. In addition, user properties apply to the user for all events going forward until they are changed, and 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 and we will call these custom user properties. Some examples of custom user properties are age, locale, referral source, plan type, number of photos uploaded, A/B testing variants, attribution, push enabled, number of units of in-game currency, and 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 events moving forward until the properties are updated again. You also do not need to send user properties with every event because previous Amplitude will automatically fill in existing user property values to an event until they are updated. In addition, do not worry if you forget to apply custom user properties to your events because you can always update user properties for users at a later point using our Identify API.
We always recommend tracking a counter of critical actions as user properties. I.e. number of orders placed/number of sessions booked. This will allow you to see how performing/crossing a threshold of these events has an impact on a user's retention/conversion rate/LTV.
Example
Mario's User Activity page on June 28th:
Mario's User Activity page on July 3rd:
Important Note:
- We only show the first 1000 user properties in a project. See our documentation on limits for more information. Our customers typically implement at most 20 user properties on top of what Amplitude automatically tracks.
If you're using our SDKs, you will track the following user properties by default: Platform, Device Type, Device Family, Country, City, Region, Start Version, Version, Carrier, OS, Language, and Library. Read here for definitions of each property.
Suggestions for User Properties
Consistency in your naming means that all properties 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 (some of the properties in this article are Title Cased for better readability), and (2) if not a string value, should refer the property's value type e.g. is subscriber = true/false , num of purchases = [1. 2. 3] -- this minimizes any confusion. Regardless of the syntax you choose, the most important factor is that all events consistently follow your chosen syntax.
Note: Please see the below Tips for Different Industries section for suggestions for event properties.
| User Properties | Notes | |
|---|---|---|
| registration status |
Only assign User IDs to users who have fully onboarded/registered. Amplitude can track anonymous users with our unique Amplitude IDs. |
|
| user type / status |
'Free', 'Paying', 'Seller', 'Buyer' |
|
| is logged in / out |
Have a property that is a boolean to track whether a user is performing events when they are logged in or logged out. Update: this is no longer recommended since you can use the User ID for this purpose. |
|
| push notification status |
Whether or not 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. Note: You can use the increment function on our SDK to add values directly to the property. |
|
| sign up date | When the user first signs up for your product. | |
| app install date |
Date when the user first installs your product. Note: 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 can users put in their profile. Note: 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 because 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. Note: You can just add +1 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/attributes of an event. For instance, if 'Swipe' is an event that you are tracking, then the event property ‘Direction’ could have the values ‘Left’ or ‘Right’.
These properties highly depend on the type of app you have and the specific information you think is necessary for understanding 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 are description, category, type, duration, level, % completed, name, count, source, previous page/screen, from, number, lives, authenticated, error, rank, action, and mode. Leverage event properties to reduce the number of events you are tracking and provide the detail you need. See the “Should I Create a New Event or a New Event Property for Similar User Actions?” section of this article.
One key use case for event properties is tracking values that must be held constant to count towards funnel conversion. For example, let’s say you are an e-commerce company and you are analyzing the conversion on the critical path below:
- Step 1: 'Product Page Viewed'
- Step 2: 'Product Quantity Selected'
- Step 3: 'Product Added to Cart'
You will only want to count that a user has converted through the funnel if they performed the event on the same product. To ensure this, you can instrument the event property 'Product ID' and define your 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, we recommend having two custom event property values, 'Property ID' and 'Cart ID'. Then, use two funnels to track if a user has viewed and purchased the same product. Two examples are outlined below.
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 we detailed out above. Let’s say you want to understand 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, you can instrument a custom event property called 'Source' to analyze this hypothesis:
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 tend to not want to watch a long video and this causes them to drop off. To test this, you can instrument a custom user property tracking age to analyze this hypothesis:
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
- Only instrument properties you think you will use. Having too many properties makes analysis more difficult.
- Before you include sensitive information (email, addresses, etc.) consider if it goes against 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 your naming means that all properties 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 (some of the properties in this article are Title Cased for better readability), and (2) if not a string value, should refer the property's value type e.g. is subscriber = true/false , num of purchases = [1. 2. 3]
Should I 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. An important question to ask is if the fundamental action the user performing in both cases is the same. In that scenario we would recommend having them be one event separated by an event property.
Option 1
- Event: 'Purchase Coins'
- Event: 'Purchase Gems'
Option 2
- Event Property: 'Type' = {'Coins', 'Gems'}
- Event: 'Purchase'
You should ask yourself: Is it important to monitor the flow of events from 'Purchase Coins' to 'Purchase Gems'?
If it is, then it will 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 the capability to occasionally filter on it, then you should have it as one 'Purchase' event and set an event property with 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.
How to Identify Users?
Tracking unique users is a complex process because 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 comprehensive solution using a combination of Device IDs, User IDs, and Amplitude IDs. We recommend reading more on how we count and track unique users to get a full understanding of how we identify and merge users.
Products that have some kind of 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 (same User ID). A User ID does not need to be assigned immediately. You should 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 will be connected to the assigned User ID (assuming the Device ID is consistent).
Important Recommendations on Setting User IDs
- Do not set User ID if you cannot determine it. For example, setting a User ID of the string "None" to multiple users will group all events under that "None" User ID together (e.g. any user with the "None" User ID is assumed to be the same single user). You can always set the User ID later and Amplitude has a built-in logic that will merge the anonymous events to the later identified user (see Example 2 in our Tracking Unique Users article).
- Do not assign a User ID that might change. So, if someone’s email can change within your app, then it is not a good idea to set it as a User ID as 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.
Understanding the User Journey
As you start creating your event taxonomy one important thing to think about is the end user journey as they go through your product. Your taxonomy should allow you to split your analysis into 3 different levels
- Event counters - Being able to track DAU/MAU, Total purchases etc.
- Funnels and conversions - Retention rates, Funnel conversion, Power curve chart
- Behavioral analysis - Impacts of performing actions on your other metrics
If we think of a new user we can map their journey from new to ultimately to a power user. The key here is to understand the factors that is causing a user to transition between these states and having clear events tracked for these key areas will allow you to better analyze patterns that help/hinder users from transitioning between these states.
How do I ensure data quality?
It is critically important that you as a company establish and enforce set of data governance rules when it comes to instrumenting events. Maintaining these rules will ensure that your taxonomy maintains clean and ensures that new and existing users use Amplitude, understand the taxonomy and are able to derive meaningful results from the data.
Common things to think of when creating business rules
- Always ensure new data is aligned with your goals/use cases and KPIs
- A consistent way of naming events
- Consistent casing and formatting of event names
- Consider shortening longer strings so they are easily read
Make sure your nomenclature is consistent. For example, if you track two events like 'Checkout Submitted Order' and 'Checkout submitted order', then they will be considered two separate events and cannot be merged automatically. Furthermore, you will confuse other teammates who are using Amplitude.
You can learn more about our data governance best practices from this helpful video.
Tips for Different Industries
In this section, we detail out some best practices based on your industry. These are suggestions based on standard goals and objectives for companies in these spaces. This is not a comprehensive list of everything that you should have but they are best practices to keep in mind as you create your taxonomy.
B2C
E-commerce / Marketplace
| Events | Event Properties | Notes |
|---|---|---|
|
Product Viewed |
|
Make sure to include every event in a critical flow and for every critical event, have the same key event properties. Amplitude lets you set that a property must be constant to have a funnel conversion count. Some examples of key event properties are Product ID, Category ID, Cart ID, Transaction ID, Order ID, Promotion ID, and Campaign ID.
|
|
Product Added to Cart |
Consolidate all SKU information into one event property with all of the SKU info stored in an array separated by commas. ["Product ID", "Color", "Quantity"] |
|
|
View Cart |
|
|
|
Checkout - Started |
|
|
|
Checkout - Added Shipping Address |
|
|
|
Checkout - Added Billing Address |
|
|
|
Checkout - Added Payment |
|
|
|
Checkout - Completed |
For this event, we recommend tracking an 'Order Size' event property. An event property count of the total products in your cart is a good practice so that you can easily segment on different cart sizes. You are not able to sum the products listed in an array and so this is property is important. |
|
|
Saved Billing |
|
If you allow your customer to save any billing or address information, then send an event when they use this in the checkout flow. Create a Custom Event that includes all address and billing events in one custom event. Then, in your funnel analysis use the custom event for your billing and address step. |
|
Saved Address |
|
|
|
PageView - Product Category |
Impression tracking can be done by tracking an array of all of the products that were seen on this page. You should also keep track of the count for total number of products on the page, in addition to the page number that they were on in a search page. This helps you understand if users are not getting the items the want on the first or second page. Page = [1, 2, 3, 4…..] |
|
|
PageView - Product Detail |
A 'Source' event property will show you the page the user was on before they came to the product detail page. Source = PageView - Product Category |
|
| User Properties |
|---|
|
Last Purchase Date |
|
Attribution Data (organic vs. campaign) |
|
Total Revenue Spent |
|
Promotions Used |
|
Total Number of Orders |
|
Total Number of Favorites |
|
Total Number of Saved Items |
|
Categories Used |
|
Brand Purchased |
|
Events |
Event Properties |
Notes |
|
Send Chat |
Message ID |
If two users involved in a single action and you want to be able to track the events on both users profiles, then send on event for each user. Have the events be triggered by the initial action. 'Send Chat' + 'Receive Chat' |
|
Receive Chat |
Message ID |
|
|
Total Swipes |
|
For events that have an extremely high volume (e.g. total chats sent, or total swipes), send one event at the end of the session and store the total as property value. |
|
Any General Event (PageView - HomePage, Category)
|
|
|
|
User Properties |
|
Total Number of Followers |
|
Total Number Following |
|
Gamification Status |
|
Total Number of Groups |
|
Total Number of Communities |
|
Total Number of Chats |
|
Social Integrations |
|
Attribution Data (organic, campaign) |
Media
|
Events |
Event Properties |
Notes |
|
Send Chat |
Message ID |
If two users involved in a single action and you want to be able to track the events on both users profiles, then send on event for each user. Have the events be triggered by the initial action 'Send Chat' + 'Receive Chat' |
|
Receive Chat |
Message ID |
|
|
‘Heartbeat’ Events |
|
If a video is being watched, then send a heartbeat event. The pros of sending this is so that you will not have to adjust the end session time and will have more aggregate session times. The cons are that you may experience event volume inflation. Example: If a user is watching a video or playing a game then send an event every ~5 min. |
|
Any General Event (PageView - HomePage, VideoCategory) |
|
|
|
User Properties |
|
Attribution Data (organic, campaign) |
|
Total Hours Watched |
|
Total Articles Read, Favorited, etc. |
B2B
Note: It is recommended that you set up account-level reporting, which is only available to Enterprise customers who have purchased the Accounts add on.
|
Events |
Event Properties |
Notes |
|
Company Metric Event |
|
One daily event with properties for an entire company/organization/group. |
|
User Properties |
|
User ID for Company Level Metrics
|
Gaming
|
Events |
Event Properties |
Notes |
|
Game start |
|
One daily event with properties for entire company/organization/group |
|
Purchase Made |
|
|
|
Add Items to Cart |
|
|
|
Ad Revenue |
|
Fire when an ad comes up for a user. |
|
Impressions Event for Ad |
|
|
|
Ad Clicked |
|
|
|
Send Chat |
Game ID |
If two users involved in a single action and you want to be able to track the events on both users profiles, then send on event for each user. Have the events be triggered by the initial action 'Send Chat' + 'Receive Chat' |
|
Receive Chat |
Game ID |
|
User Properties |
|
Attribution Data (organic, campaign) |
|
Current Level |
|
Games Played |
|
Total Number of Games Play |
|
Tokens / Currency |
|
Total Spent |
|
Items Purchased |
|
Game or User Name |
|
Current Rank |
|
Special Features Used (e.g. avatar) |
|
Games Won |
|
Games Lost |
|
Top 10 Games |
|
Most Popular Games |
|
Days Active to Date |
|
Days Playing to Date |
|
Days Since Last Game Played |
|
Days Since First Game Played |
Sample Event Taxonomies
To help you better understand and visualize event taxonomy, we have built a few examples here:
Copy the Google Doc template for your own use.
Download Excel version of template for your own use.
We hope this article helps you develop a better understanding of how to set up your events on Amplitude. If you are an Enterprise customer, please do not hesitate to reach out to your dedicated Success Manager. If you are not an Enterprise customer and need clarifications around Event Taxonomy, you can still reach out to us here and we would be happy to help.