Avo Feature Requests

Sometimes when the base event is updated the changes only apply to a subset of the variants of the event. It's no problem if the variants are few to go through each of them and modify. But when the variant are many, the job to update all of them becomes very tedious and error prone. So it would be helpful to be able to pick which, if any, variants the change applies to.

We use the main event as a blueprint of what all sources for the app should follow as event variants. Some variants don't have properties from the blueprint for a number of possible reasons: Does not exist on platform with no plan to implement Not yet implemented on the platform Technical limitation to include on this platform etc. If whenever a user hovers over the red strikethrough properties on an event variant the reason for its exclusion pops up or is otherwise visible, this would be really helpful to know what the status of the exclusion is for that property.

Improved audit log on two pieces of functionality: Code generated: A fliterable view of overall usage and frequency of who/when is generating code. Sign ins/usages: Who has access to Avo and is signing in and working with it? When's the last time they've something in Avo? Who's signing in and viewing it without making changes (especially those editors/admins)?

It would be helpful if each platform could be notified when changes are made to events on their source. It is currently possible to get notifications for stakeholder teams, but the events are only filterable by category and tag, so it's a very manual job to set up a stakeholder team for a source.

When a property is shared across many events, adding an allowed value directly to the property applies it to all those events, which can lead to unintentional values for some or many events. While it's technically possible to fix this by removing the allowed value from the property and manually adding it back on a per-event basis, this workaround becomes increasingly time-consuming as the number of affected events grows. The complexity also increases if different sources need different allowed values. A more efficient way to bulk manage allowed property values at the event level, especially in cases where properties are reused across many events and vary by source would help a lot!

It would be valuable to support embeddable visualizations of Avo events and properties, such as event names, descriptions and associated metadata that could be displayed directly in external tools and platforms (e.g. documentation, systems, wikis, dashboards etc). This functionality would enable teams to: Share Avo context more broadly without requiring users to navigate away from the tools they already use Keep documentation and specs automatically in sync with Avo as the source of truth Reduce manual duplication of event information across platforms This would hep bridge the gap between planning, implementation and analytics by making event documentation more visible and accessible across workflows.

It’s difficult to understand how a nested property relates to the event or parent object that contains it. The current UI only links the top-level object to the event, making it feel like child fields (like skuId inside a skus[] array) are floating and unconnected. In improvement could be either breadcrumb context, a tree structure, or at minimum an indication of which events the parent is used in. Right now, you only discover relationships by hovering, which is too subtle.

It would be useful of Inspector would detect significant event volume drops and spikes, for example between versions. And even better if it would alert me!

Avo does a great job of documenting event schemas. But a lot of companies today rely on enriching and transforming the data both before and after how data is documented in Avo. It would be really helpful to be able to document the shape of the data trhoughout the lifecycle. Examples: Document Amplitude derived properties Document default properties collected by tracking tool SDKs Document other data from non-event based sources that are used downstream to enrich the event based data

There's currently no good way to search property allowed values when building a metric. Properties that have a ton of values are difficult to navigate because they are added chronologically, not in an easily navigable sorting (such as alphabetically). Adding the ability to search for allowed values would make this much easier.