Avo 101 for developers

5 minute read

Avo offers three ways to validate your tracking implementation:

  1. Avo Functions: Type safe analytics wrappers
  2. Avo Inspector: Tracking observability
  3. Avo Debuggers aka In-App Inspector: On device tracking verification

Avo Functions: Type safe analytics wrappers

What are Avo Functions?

Avo Functions are type safe analytics wrappers that are code generated based on your tracking plan.

Technical or non-technical people can define analytics event schemas in the Avo Tracking Plan, and you can generate human readable type safe code based on that. The days of unstructured and outdated tracking plan spreadsheets and Jira tickets are over 🥳 So are the days of brittle analytics implementation you have to revisit to fix again and again and again 😌

How do Avo Functions work?

Avo Functions are type safe analytics wrappers that can work with any analytics tool you already use or plan on using, whether it's any of the third-party event logging SDKs (e.g. Google Analytics 4, Segment, RudderStack, mParticle, Snowplow, Amplitude, Mixpanel, Pendo, etc) or your home made API.

The Avo Functions have a Destination Interface that you have full control over how you implement. You provide a simple Destination Interface object when initializing Avo Functions SDK, so that any time an Avo Function calls an analytics logging method (e.g. logEvent, setUserProperties, etc), you can govern exactly what analytics SDK method should be called.

In the Avo Tracking Plan you can configure which analytics actions should be triggered with an Avo Function (for example you might want to update user properties or log revenue along with logging an event), and the Avo Functions will handle calling all the relevant Destination Interface methods. All you have to do is call the Avo Function in your code base and pass in type safe key-value pairs, and the Avo Function will take care of the rest.

Learn more technical details about Avo Functions here.

Do events flow through Avo servers?

No. None of your events ever go through Avo servers. They go directly from your devices (whether that's a front-end client or a server) to the analytics destination.

💡 This sometimes called "device mode". With CDPs, you can choose between Cloud-mode or Device-mode:

  • In Cloud-mode, your events go through the CDP servers. Your devices send the events to the CDP cloud (aka the CDP Servers) and the CDP cloud sends them to the analytics destinations.
  • In Device-mode the events go directly from your devices (whether it's a front end client or a server) to the analytics destination. In this regard, Avo works like Device-mode.

Avo Inspector: Tracking Observability

What is Avo Inspector?

Avo Inspector is a tracking observability solution that's easy to install. Avo Inspector analyzes tracking calls made by your app and provides an overview of them in the Inspector dashboard.

With Inspector, you get an instant audit of your current state of tracking, and an ongoing tracking observability going forward.

How does Avo Inspector work?

The Inspector API extracts the schemas (aka shapes) of the events you trigger (no PII data, only event names, property names, and types of properties) and sends those schemas to the Avo servers. To repeat: None of the PII data ever flows through Avo servers; only event schemas.

How do I use Inspector?

You can view the overview of your current tracking in the Inspector dashboard and you can connect Avo Inspector to a Slack channel to receive alerts when the Inspector detects a new issue that has not been seen in production for 30 days.

How do I send data into the Inspector?

You can send data into Inspector three ways:

  1. Inspector SDKs
  2. Connect with CDPs and analytics platforms
  3. Inspector API (contact us to get access)

Inspector SDKs

The Inspector SDK can be plugged into your existing tracking – independent of whether you're using the Avo Functions or not.

Inspector SDK with your existing tracking

The Inspector SDK is a stand-alone SDK which you can install with your package manager. You can use the Inspector SDK whether or not you adopt Avo Functions, by plugging the Inspector SDK into the call site of your existing tracking. Most code bases have some sort of a wrapper around calling their analytics SDKs, and that's where you plug the Inspector SDK.

Inspector SDK with Avo Functions

Initialize the Avo Functions SDK with an instance of the Inspector SDK.

Connect with CDPs and analytics platforms

You can pipe your analytics data into the Inspector API via your CDPs or analytics providers:

Reach out to support@avo.sh for early access to any of the platforms coming soon.

Inspector API

Coming soon: You can send data into the Inspector API directly. Reach out to support@avo.sh for early access.

Does Inspector receive PII data?

No. Inspector does not receive any PII data. Inspector only takes in event names, property names, and types of properties.

Learn more technical details about the Avo Inspector here.

Avo Debuggers aka In-App Inspector: On device tracking verification

Avo provides an In-App Inspector that shows you when you're triggering events, what the schemas are, and whether they match the analytics event spec. The In-App Inspector is displayed via a small bubble on your web or mobile app, which you can click into and see the details of the event structure.

When you implement analytics via the Avo Functions, the In-App Inspector will not only show you the timing and schema of your event, but also display a red warning or green check mark based on whether or not your events fits the analytics spec in your Avo tracking plan.