Launch HN: Avo (YC W19) – Minimize Human Errors When Implementing Analytics
Hi HN! We’re Árni, Sölvi, Thora, and Stef – from Iceland. We make Avo (https://www.avo.app), a tool built to minimize human errors and overhead when implementing analytics. We’re going for “simple made easy” for maintaining tracking for cross platform consumer products, where a 1% change in conversion funnels makes a difference. It’s a code-generated, type-safe tracking library to accurately implement analytics events that are defined and maintained in a single-source-of-truth web app.
We’re solving a personal pain point of broken analytics and how much effort it was to have an overview of what was being tracked across product teams and platforms. We all worked together on a game called QuizUp (100M+ users) where we used metrics to make decisions. The problem was we repeatedly “broke” conversion funnels and retention charts we relied on when we shipped product updates, by mistakenly removing or changing analytics implementation.
It was driving everyone involved mad – so we built internal dev tools and processes that made implementation easier and our data more reliable. What we built was never perfect, and it was clunky in many ways:
1) There was no one that really wanted to maintain this – but developers ended up agreeing to maintain it because it was better than the alternative of frustrated data scientists requesting a fix for analytics implementation that the developers worked on weeks or months ago.
2) JSON files (or the crappy web apps we invested time in building on top of the JSON schemas) didn’t give us a “human-accessible” overview of what was being tracked and when. So people who weren’t working on analytics every day had no idea what data they should look at to dig into user behavior.
We also discovered that a lot of companies build similar stuff – i.e. some version of internal tools for data validation, either through code gen or through server-side validation, often based on JSON schemas. The same seems to apply for those companies; it’s clunky to update, doesn’t give a proper overview, and no one wants to maintain it – yet it beats the alternative of not having it.
So now, six years after we started maintaining tools like these internally, we’ve built Avo, to solve these issues for more people.
Here’s how it works:
1) The web app is built to optimize the experience of maintaining and version controlling complicated event schemas. That means a few things, for example:
- we built a “differ” that feels similar to git, but instead of line-based diff, it’s object-based
- when you make updates, Avo gives you suggestions to maintain casing and reuse properties across events.
- you can view the historical change of each object similar to Asana tasks
2) The code gen is optimized for bringing type safety and rigour to analytics implementation:
- You install a CLI to easily update (`avo pull`) your tracking library according to the latest version of the event schema. The generated code contains a type-safe function per each event.
- For example: A "Cart Updated" event with an "Item Count" property, would generate `cartUpdated(itemCount: Int)` for Swift. For dynamic languages, as well as for limitations which cannot be expressed through type systems, such as min / max, the runtime validation logs warnings or errors for data structure errors.
Things to note:
- Avo does not store, process or access your data – so no GDPR approval required.
- The Avo code generated libraries wrap whatever analytics SDK you already use. You can use the Avo library alongside the tracking you already have, or do a full migration to make sure all your events are according to the specs in Avo.
- Avo is not another analytics or data pipeline vendor. We love the ones that exist already. We’ve just built Avo to make sure we can use the data we send into them.
Thanks for reading, HN. We would love to hear your feedback, as well as stories of when you built this internally or when you wish you had this. I feel like Amplitude's schema management tools are best-in-class right now but still missing a lot. I've been frustrated at the absence of any integration with my eng teams build/CI systems or really any automated way to catch problems at the PR or code review stage. Is this something on your radar? > no one that really wanted to maintain this I feel strongly that the data organization needs to own this outright, and the only thing holding them back was the right tooling. This seems like the perfect tool to enable it. Very excited to give it a spin. > I've been frustrated at the absence of any integration with my eng teams build/CI systems or really any automated way to catch problems at the PR or code review stage. Is this something on your radar? CI / GitHub integrations are definitely on our radar. We have already integrated `avo status` in our own CI pipeline (see https://www.avo.app/docs/reference/regression) and we are excited to do more. I would love to understand your desired use case. If you want to share feel free to continue here or email us at friends@avo.sh. > I feel strongly that the data organization needs to own this outright, and the only thing holding them back was the right tooling. This seems like the perfect tool to enable it. Very excited to give it a spin. Glad to hear. We can't wait to hear what you think. Cool idea, seems like the next logical (or rather the first) step in the current analytics pipeline. This being said, your doc could do with some fixing / editing : > https://www.avo.app/docs/help/faq
Bad copy pasting of "Does Avo send my events to its servers?" instead of "Why does Avo want me to input my analytics tool API keys?" > https://www.avo.app/docs/reference/languages
Those are documented in detail in TBD. Best of luck. It's great that you think so. Thank you for the Docs pointers! Good spots. We will make sure to fix these. I'm having difficulty understanding how to use this. Is there a demo / example to view? I'm currently managing a team using Google Analytics, Facebook Pixel and Hotjar. How can I benefit from Avo? From what I understand, I can use Avo to setup flows that I want to watch (like a sales conversion funnel) and make sure that the analytics tags are properly implemented across all pages of the funnel. Is that correct? In the case that the sales funnel changes and a new page is added, do I need to remember to update Avo with the change? Something like ObservePoint[1] would be more appropriate for that use case. Avo seems like it's designed to deal with consistency issues, rather than coverage issues. For example, say you have three different multistep sales funnels. You send a custom event "TrackFunnelStep" to both GA and Facebook at each step of the funnel. Where Avo would come in would be with defining precisely what that custom event should be (data structure, naming scheme, etc) and ensuring that everywhere "TrackFunnelStep" event ends up, it's used consistently. But Avo wouldn't stop you from forgetting to add the event to a step in the first place. That's correct. Avo today is particularly designed for consistency issues. Coverage issues are top of our mind though, and we have some internal tools for that that we're excited to share soon.
Thanks for taking the time to clarify. Thank you for surfacing the need for a better demo and examples. > I'm currently managing a team using Google Analytics, Facebook Pixel and Hotjar. Avo is optimized for event based analytics, such as when people send events with metadata into Amplitude, Mixpanel, Segment or into custom pipelines. Are you sending custom events into the platforms you mentioned, and sending metadata along with the events? > From what I understand, I can use Avo to setup flows that I want to watch (like a sales conversion funnel) and make sure that the analytics tags are properly implemented across all pages of the funnel. You can use Avo to define the structure of the events that you want to send at each step in that flow. From those definitions, developers can generate code that validates that the event structures are correct. What I mean by event structures is for example event names, which properties should be required on those events, what those properties should be named, and which type their values should be. An example event could be: event name: "Checkout Completed" properties and their values: {"Number of Items": 2, "Amount": 100.00, "Currency": "USD"} > In the case that the sales funnel changes and a new page is added, do I need to remember to update Avo with the change? If your data should change along with the sales funnel change, then you should update Avo and then your code. /pricing is a 404. There are lots of ways this can be interpreted: >14 day free trial. Pricing scales with your team, not your data. What are your future monetization plans? Thank you for pointing that out. We will make this clearer with a pricing section. Here is the pricing model: Avo is $15 per seat per month for schema documentation and codegen. Congrats on the launch, sounds like you're solving a real issue. Thank you! Are you personally familiar with it as well?