What problems is Avo solving and how is that benefiting you?
These notes are straight out of our business case for Avo:
The process for creating and updating events in Amplitude Govern is cumbersome and prone to error. The Amplitude projects for our development and production environments are curated independently, with copy-pasting between the two projects, and as a result of imperfection, the categories, events, and properties differ between the two projects. Requests for new events, or changes to existing events, are currently documented in spreadsheets or Miro boards, which involve double-entering and can result in lost information and confusion. The Amplitude SDK does not enforce the schema created in Govern. Nothing is stopping us from releasing events without mandatory properties, misspelling properties or even event names. Once the events are sent in production, the errors are eventually flagged by Amplitude, but it means engineering, PA, or both, need to make further changes to ensure they are tracked.
Avo effectively solves all of these problems.
The process to create new and update existing events is much easier, with a branching system similar to Git. All changes for a newly tracked feature can occur on a branch, allowing Product, Engineering, and PA to collaborate to find a neat solution before the changes are merged to production. Avo enforces the schema from the development side. It makes it impossible to push or release a change without including all mandatory properties. It eliminates the risk of misspelling event names or property names, or making other errors. Avo provides documentation about all changes in a branch, both in a PM-friendly format (that can be pasted in the comments on a Jira card), and a dev-friendly format (that can be accessed from the command line). This removes the need for double-entering into spreadsheets. Review collected by and hosted on G2.com.