Companies in the growth stage depend on highly relevant and accessible data to be able to move fast. Unfortunately often as the company grows, data becomes less and less accessible and becomes a bottleneck. Sometimes you realize that your data quality has taken a hit because of a bug or implementation inconsistency between platforms. Sometimes, which is even worse, you do not realise it and release a feature based on incorrect data. Both scenarios can lead to lost money and time.

In the ideal world everyone involved in tracking data would be spending extra effort to maintain pristine data quality, but in reality this is not always the case. More often than not, even one small mistake in the implementation pipeline can corrupt data, which is expensive if not impossible to fix. 

A parable

Let's imagine a hypothetical growth stage company with money to grow its headcount and product. That company will do whatever it can at this point to improve their product and gain market share – including blindly building product and sending more and more data out to analytics without the proper planning. (We’ve been there.) What the company will soon find is that instead of using their money wisely, they were setting themselves up for failure related to the data they want to rely on – the more people involved, the worse the data gets, and the more money it will cost them to fix it in the long run. If they even last that long...

The biggest issue with this hypothetical disaster is that the company didn’t take the issue of data quality seriously enough from the beginning -- and honestly, it’s hard to blame them. The existing tools for analytics don’t exactly make it easy to get data right. They make it easy to get data out. Even if they adopt a tool for data quality at this stage, it will be hard and expensive for them to get it right. But what’s the best way to fix it?

Introducing The Avo Inspector

We’d like to introduce you to the Avo Inspector, designed specifically for the described case. You integrate it with a couple of lines of code and it immediately and automatically gathers metadata about your event tracking – the foundation of your company’s analytics. 

Note: Avo Inspector doesn’t gather any actual user data, only the shape and volume of the tracking calls.

As the Inspector analyzes your data, it will show the issues you have in your event tracking setup and will help you fix them and gradually pick up all the other benefits of Avo: easy, type-safe, validated analytics, consistency across all languages and platforms, built fast with cross-team collaboration.

How it works: The Inspector SDK

The Inspector SDK monitors all analytics events being sent, logging metadata about every event sent to our servers. We are launching with Android and iOS SDKs, with a Web SDK coming very soon.

Implementation-wise, the Inspector method should be placed where the analytics event is emitted: Most code bases have a “central wrapper” to handle the emission of analytics events. This wrapper is then called in multiple call sites in the code base, to trigger events for a range of user interactions. Add the trackSchemaFromEvent(eventName: String, eventParams: Map) method right after the line in the wrapper that emits the analytics event.

More information about the Inspector SDK: https://www.avo.app/docs/inspector/sdk

In addition to analyzing your tracking and highlighting issues, having Inspector SDK in place will make adopting Avo way easier. While you are gradually moving your tracking calls to go through Avo the Inspector will yield an overview of the tracking calls that have been migrated to use Avo functions and which calls are still coming through the Inspector SDK, providing a clear list of tracking calls to migrate.

Issue types

The SDK collects enough data to analyze and highlight a wide range of issues. We will be rolling out more and more issue detectors as time passes that retroactively detect new types of issues in your existing data.

Right away, Avo Inspector detects the following issues:

> Property Sometimes Missing reveals when events are accidentally missing a property, usually due to a bug or platform inconsistencies

> Event Volume Changed shows you when an app’s sessions start delivering significantly more or less of a particular event. This is usually due to a bug - or a bugfix.

> Event Missing On Platform warns if an event is never sent from a platform.

> Property Type Mismatch warns if a reported property has varying type. Ensuring consistent types is hard across platforms or even different codepaths.

Of course sometimes when things like this happen they are intended, you can mark those issues in the Inspector and they won't be reported again.

What’s next?

Read more about how the Inspector works in the FAQ and in the documentation.

Try Avo today