Avo Feature Requests

We use common event properties across a wide range of events because only select number of properties are by default visible in our analytics reporting platform. For example, we have a property called ui.location, which is meant to contain information about the location in the UI where the user performed that action. Depending on what the event is capturing (adding text to their graphic, opening a settings dialog, etc), the allow list will be very different. This causes confusion to engineers if an allow list is defined for a property on an event that is not relevant for the features they are developing. We'd also like to have this allow list dependent on source since we use sources to differentiate apps, which have very different designs and feature sets, but all use the same properties that are compatible with our analytics reporting platform.

Such as adding tags, sources or categories. Frustration: To add tags, sources or categories to an event today one needs to go into the event and add them for every event. And if the event doesn't have tags already, one needs to go into the event menu to add it. Would be better if one or more of the following would be possible: multi select events to add tags, categories and sources to keyboard shortcuts tag specific have a list of available tags accessible, to be able to add events from the tag view (like is possible for properties, sources and categories)

Clicking on a branch from Avo brings me to the metrics page, which doesn't make a ton of sense to me. I would expect it to bring me to the diff page or something more branch-related.

I went to edit a property for a given source, so I started by navigating to the source, then through the tree on the right through to the event and property I wanted to change. When I went to change it I was asked to switch to a branch, so I created a new branch and then it reloaded the page and closed the side panels so I had to re-do all that navigation to find my event and property again. When a new branch is created after navigating through several panels, the same panels should be reloaded when the new branch is opened.

I'd like to specify that certain property values are allowed for one event, while different values are allowed for the same property on a different event. Use case: "context", which represents location from which an action was taken (eg "home feed", "profile", "item details", etc.). The allowed values for this are different depending on the event.

A role that allows a developer to generate code but not make changes changes to master without approval. Use case: Having outside contractors that are implementing analytics. With editor access they can make accidental changes to master that can be hard to undo.

I have a property value that should be on the format \d+.\d+.\d+.\d+. If anything else is passed in I'd like to get a validation error.

Be able to have different set of constraints on the same property based on source. Example: A "Page Name" property is applicable for two sources but one of them only has 5 possible constraints and the other has 20 possible constraints. Ideally it would be possible to validate the constraint only against the values applicable for the given source.

When dealing with fat events in Avo there are currently 2 choices: - the docs recommend to create one trigger for each occurrence of the event, but there's no way to specify if allowed property values are any different between them beyond using the trigger description - if you want to pin a distinguishing property value for each trigger + use name mapping. This inflates the tracking plan and increases the risk that any event occurrence might have "something" different than the rest (beyond the obvious case of that property itself). It would be better in my opinion to allow each trigger to pin property values. This way you could get the best of both worlds and triggers would have more meaning beyond being just screenshots and text

It would be useful to have the filters on category and tags available in the issues view. This would allow to create alerts tailored to areas and/or people, without changing the list of monitored events e.g., every time that there is a new event in that category