top of page

Amplitude - Hands-on with event design

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:


  1. Naming conventions

  2. Event cardinality


Naming conventions


Naming conventions refers to 


  1. 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”.


  1. 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


Booking Error Encountered

Error Code : YZ49

Error Message : Error message the user receives


Seating Error Encountered

Error Code : YZ49

Error Message : Error message the user receives


Luggage Error Encountered

Error Code : YZ49

Error Message : Error message the user receives


Payment Error Encountered

Error Code : YZ49

Error Message : Error message the user receives


Ticket Printing Error Encountered

Error Code : YZ49

Error Message : Error message the user receives


Optimised event design:


Error Encountered

Error Type : Date | Booking | Seating | Luggage | Payment | Ticket

Error Code : YZ49

Error Message : Error message the user receives


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 !

Comentarios


bottom of page