Avo Feature Requests

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.

It would be great to have support for defining fields that live inside the context object of an event payload, such as those required by Segment’s Consent Preference Updated event. These fields are not part of the top-level event properties but are instead nested within the context object. Currently, Avo does not provide a clear way to document or manage this kind of structure. This functionality would help teams properly define and validate events like consent events that follow Segment's standard, and more generally improve schema support for nested field requirements.

Enable the ability to define allowed values for a property only for specific events, while allowing that same property to be used without any value restrictions in other events. This would enhance flexibility in property reuse and reduce the need for redundant property definitions. Use Case In current usage, teams aim to reuse the same properties across multiple events to maintain consistency and avoid duplication. However, there are common scenarios where: Certain events benefit from having strict allowed values for a property (e.g., for validation or analytics consistency). Other events require the same property to be open-ended, with no restrictions on its values. For example, the label property might be tightly controlled in one event but left unrestricted in another.

Currently multiple metrics can be created with: the same name the same metric structure Would be good to have the option to prevent that to make sure our metrics are a single source of truth definitions

Sometimes people make breaking changes in Avo without being aware of what effects it has to the downstream data. So it would be helpful if Avo would in some way highlight that breaking changes have been made on a branch such that the person making the changes and reviewers can take a decision if that's what they actually want or if they want to find a different solution to design the data for what they need to measure.

Send workspace notifications to MS Teams

We’d love to explore a small enhancement: Can we automatically include eventVariantId in the generated pseudo code for all events? Why this helps: Developers can easily populate this value via codegen implementation, making event validation between Avo Schema and internal data Collection much more straightforward. Example: Pseudo code should include "eventVariantId": "variant_id_derived_from_th_variant_url" Then we can join raw data on the variant ID Current workaround: create the property eventVariantID add the IDs as allowed values to the property pin the appropriate value to the variant This way the variant ID will be in the pseudocode