Avo Feature Requests

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

Sometimes we want to see all events/properties/metrics that result from a search and inspect them. Currently, when you search for something, it populated them in the search panel but once you click on anything to inspect, the search results go away until you do the search over again. We'd like a way to be able to filter the more static views like event property and metric views based on the results of a search until we actively dismiss it, like we would a Category or Source filter.

There may be iterations on a funnel like when a user is importing media they could have: 1 - start-import-media : User begins the process of importing selected media 2a - success-import-media-item : One of the selected media items is imported successfully 2b - success-import-media-item : The next selected media is imported successfully 2c - success-import-media-item : The next selected media is imported successfully 2d - success-import-media-item : The next selected media is imported successfully ... 2z - success-import-media-item : The next selected media is imported successfully 3 - success-import-media : The entire media import process has concluded successfully returning the user to the editor Indicating that a step can be iterated is useful for understanding collected sets in analytics. For us, events that share a single trigger also share an instance guid that allows us to connect that specific set of events for that specific instance the user triggered them. If we knew what an event could appear iteratively in a connected event set, we would also know not to worry if the same event shows up multiple times with the same instance guid, which should otherwise never happen as they should not be reused across different instances.

Some of our funnels have branches, like if there is a step in the middle that has a failure and stops the entire workflow. For example, with our personalization in app messaging campaigns we have four touchpoints: 1 - view-campaign : User entered the campaign experience 2a - bounce-campaign-notification : The in app notification failed to deliver 2b - show-campaign-notification : The in app notification was delivered successfully 3b - select-campaign-cta : The user selection one of the options on the in app notification There are two paths here: 1 -> 2a and stop or 1 -> 2b -> 3b If we want to detail the funnel of a campaign or really any funnel that has a fail state, we currently need to create separate funnels for each branch, which can be cumbersome if there are multiple steps that can fail or multiple variants in an experiment with different events or event orders.

Often we have funnels that contain consistent metadata across events that needs to appear on each event. A good example is in app messaging campaign events. Each of those needs to have a specific campaign ID, campaign platform, campaign variant, etc on each event in the funnel for us to be able to identify the funnel in a metric for a given campaign.

Currently there are only events that are showed in the property details, not event variants. That means event variants are missing from the overview of which events and variants the property is attached to, and the presence of the property of variants.

We'd like to be able to have archived triggers available to us to track down old data in the event, but want a clear way to indicate to our engineers that these triggers are no longer valid for the event in question.

Is there a way we could require Stakeholder Team owners for Metrics? We are trying to establish Metric Governance across teams too (in addition to event/property governance)

To help communicating what string constraint applies in which situation, it would be helpful to add a description to each string constraint. Current workaround is documenting constraint descriptions in the property description.

Currently the events view can be sorted and filtered, but the properties view not. Would be great to be able to filter and sort there also to get a better overview over the properties I'm interested in and more easily find those I'm looking for.