Event Triggers are a way to communicate to your team exactly the user actions or moments that trigger an event to be sent – in a visual and written way.
💡 Note that Event Triggers are available on the Team and Enterprise plans.
Event triggers can be found in the event details view under "Triggered when", between the description and sources.
To add a trigger to your event:
You can use Event Triggers to communicate very clearly from where the event should be sent and at what moment. Below are examples of different ways of using event triggers to communicate that with your team.
When you have an application on web and mobile, they often have different triggers for the events. In that case it's very convenient to be able to communicate visually when the event is sent on mobile on one hand and on web on the other hand.
When you have multiple locations in your application where a user can perform an action (for example with multiple buttons to sign up) then it's good practice to include all scenarios such that the developers implementing don't forget to add the event to a specific call site in their code.
When you have fat events (events that include multiple related user actions, distinguished by a property), it's good practice to communicate all scenarios by using multiple triggers.
For example if you have an event for all interactions to a billing modal, you can add triggers for every single interaction.
Triggers facilitate a very nice way to communicate to a developer when they need to add a new call site to an event. For example when a new button for the user action is added or a new option in a setting screen is added. Then the new trigger for the event is displayed in the review screen, implementation instructions and Avo Codegen.
Whenever there is simply one location that a user can perform an action or when a single screenshot is sufficient to describe when an event is sent, it can be useful to simply add one trigger and have it "source independent".