Introduction
This article explores the event design principles for your current or future Amplitude implementation. This article contains best practices and can be considered as guidelines.
Event design principles
There are two main principles to be taken into account when designing events:
Naming conventions
Event cardinality
Naming conventions
Naming conventions refers to
The system used to name eventsAmplitude recommends using a system called “object-action in the past tense”.In practice this means first using the object (example “button”) and then the actual verb in the passed tense (example “selected”). This would result in “button selected”.
The applied casingAmplitude recommends capitalised casing (opposed to snake case or camel case for example).If we take back our previous example this would mean “Button Selected” rather than “button selected”.
The examples indicate Amplitude’s preferred and recommended ways of working.Nothing prevents you from choosing another system or casing. The important message here is to ensure there is an actual naming convention consisting of both (1) a system and an (2) applied casing that has been agreed upon. This ensures consistency across teams and time.
Event cardinality
Event cardinality refers to the total number of unique events determined by the event name.
A low cardinality is preferred over a large cardinality. Implementations or tracking plans with large cardinality may indicate that optimisation is needed and properties are underleveraged.
Let’s examine how cardinality can be reduced by leveraging properties and what the impact is on how analysis is done within Amplitude using a couple of examples.
For our example we’ll be using the example of an airline company.
Example 1
The following events track the errors that users might encounter in different “modules” of the booking process.
Original event design:
Date Error Encountered
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Booking Error Encountered
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Seating Error Encountered
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Luggage Error Encountered
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Payment Error Encountered
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Ticket Printing Error Encountered
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Optimised event design:
Error Encountered
Error Type : Date | Booking | Seating | Luggage | Payment | Ticket
Error Code : YZ49
Error Message : Error message the user receives
Page : AirHuman37.com/xyz
Impact on analysis:
By introducing the “Error Type” property we are able to:
Reduce the event cardinality from 6 to 1.
Leverage the group by feature in Amplitude and reduce the analysis from 6 clicks to 2.
Reduce the risk of making errors during the analysis. The analyst in Amplitude can now simply start with the” Error Encountered” event and drill down into the data from there. This means the analyst does not need to know at all times how many types of errors could potentially exist in the system which would be a requirement for the first event design.
The following charts answer the question “which error occurs the most?” for both event designs.
Example 2
The following events track the different types of dates a user can select for a flight.
There are two types of flights - Direct and indirect.
There are two directions of travel - Outbound and Inbound.
Original event design:
Direct Flight Departure Date Selected
Flight Date : YYYY-MM-DDTHH:mm:ss
Direct Flight Return Date Selected
Flight Date : YYYY-MM-DDTHH:mm:ss
Indirect Flight Departure Date Selected
Flight Date : YYYY-MM-DDTHH:mm:ss
Indirect Flight Return Date Selected
Flight Date : YYYY-MM-DDTHH:mm:ss
Optimised event design:
Flight Date Selected
Flight Type : direct | indirect
Flight Direction : outbound | inbound
Flight Date : YYYY-MM-DDTHH:mm:ss
Impact on analysis:
Reduce the event cardinality from 4 to 1.
Leverage the group by feature in Amplitude and reduce the analysis from 4 clicks to 2.
Reduce the risk of making errors during the analysis. The analyst in Amplitude can now simply start with the” Error Encountered” event and drill down into the data from there. This means the analyst does not need to know at all times how many types of errors could potentially exist in the system which would be a requirement for the first event design.
The following charts answer the question “how many times was each flight type selected?” for both event designs.
Conclusion
Make sure to conduct the following check when working on your taxonomy or tracking plan:
Ensure you have a naming convention in place
Ensure you have decided on which casing will be used
Low event cardinality is preferred over large event cardinality
Drilling down into data is safer than summing up data as the latter introduces additional risks of omitting events someone is not aware of
Use properties to add details and context to events
Need help with Amplitude and/or Analytics in general? Feel free to reach out !
コメント