DEV Community: Avo

9 Free Tracking Plan Templates from Mixpanel, Amplitude, Segment, and More

Avo — Mon, 23 Nov 2020 14:39:08 +0000

At Avo, we’re all about working smarter, not harder. That’s why we rounded up some of the best tracking plan templates: so you can spend less time planning your data management, and more time enjoying the fruits of your labor.

Sure, you could build your tracking plan completely from scratch using a Google Sheet or Excel, but why make your life harder than it needs to be. Building a good tracking plan can take a lot of work and trial and error.

When you start with a tracking plan template, you reduce some of the friction between your data-driven vision and your data-admin reality. This helps you get your data management off the ground faster, with less of a headache.

Why you should use a tracking plan template

There’s a lot that goes into building a great tracking plan, and, thankfully, some of the best leaders in the analytics industry have done the legwork for you.

You can definitely blaze your own trail and create a tracking plan yourself, but you’ll inflate the amount of time going back and forth with your product and sales teams to establish key events and KPIs. You also run the risk of forgetting about a key field your tracking plan needs, requiring you to go back and correct both your plan and your analytics down the road.

Why work harder when you can work smarter and faster?

But before we get going too fast, let’s review a quick definition of what we mean by “tracking plan”:

A tracking plan is a centralized document that everyone on your team refers to when setting up and implementing tracking analytics at your company. It outlines what metrics you care about, and why.

Now that you know why you should use a tracking plan template and what a tracking plan is, we can move on to the best part: our favorite tracking plan templates. 🥑

A breakdown of our favorite tracking plan templates 😍

The tracking plan templates we’ve included below will streamline many of the steps of building this centralized document to keep everyone on the same page.

These templates help you avoid all that mess and help you get your tracking plan best practices up and running, and each of the templates below from companies such as Amplitude, Segment, and Mixpanel will make it easier for you to implement your plan into popular analytics tools.

1. Avo’s Ultimate tracking plan template 🎉

We’re a little biased, but this is our favorite. We created an ultimate, universal tracking plan template that outlines everything you need to think about when creating a tracking plan, all in one Google Sheet doc.

‍

What we like: This tracking plan template takes our favorite elements from our customers’ tracking plans and puts them into an understandable template format that companies can use to break down the metrics they most care about. Then, once it’s filled out, tracking plan champions can use this document to seamlessly implement their plans into their analytics tool of choice.

What we don’t like: Your information isn’t already in it. 😉

Best for: The Avo template is made for any company that wants to be data-driven and develop a killer tracking plan.

2. Segment’s basic tracking plan template

Segment is an industry leader when it comes to product analytics. In addition to their specs for mobile, video, SaaS, and ecommerce tracking, they’ve developed a number of tracking plan templates to get you started, but this basic template is one of our favorites.

‍

What we like: You can use Segment’s template for a variety of industries, and the Google Sheet format makes it easy for you to keep track of implementation notes, tracked events, and user IDs and traits.

What we don't like: In our opinion, this template could be improved with an additional column (or stand-alone tab) for overall business objectives and key performance indicators (KPIs).

Best for: This template is best suited to any company looking to improve their data management practices (bonus if you already use Segment).

3. Amplitude’s basic event taxonomy template

This template is an oldie but a goodie. Amplitude created a basic template for event taxonomy (a fancy way of saying tracking plan) for companies in any industry.

‍

What we like: Amplitude’s tracking plan template includes clear instructions on how to get started, as well as answers to common questions companies may have while building their template. This ensures that you (or whoever is in charge of developing your 1.0 tracking plan) can easily get started without having to do a bunch of Googling.

What we don't like: This template doesn’t feature a tab for implementation notes, but you can always add another to your local copy.

Best for: Amplitude’s template is best suited to companies in any industry that already use—or plan to use—Amplitude to manage their analytics.

4. Practico Analytics’ basic tracking template

Practico Analytics has created some awesome resources around tracking plan development and management, not least of which is this basic tracking plan template.

‍

What we like: Practico Analytics added some extra fields to their template for implementation status, spots to specify where in the life cycle the event fits, and a field for what app section your events sit within. This extra detail is an awesome way to ensure that your events match up with your user journey.

What we don't like: This tracking plan is technically behind a sign-up gate (though the link we provided up top gets you around that), and their implementation checklist doesn’t include any sample information.

Best for: This tracking plan template is best for companies that have some tracking plan experience and that appreciate, but don’t need, example data to show them what to include.

5. Mixpanel’s Tracking plan Template for SaaS companies

Mixpanel created a great simple template for SaaS companies that breaks down how to think about business objectives, analytics strategy, and tracking plan elements such as event names, triggers, and definitions. If you’re in the SaaS space, this is a great resource to get you started.

What we like: This Mixpanel tracking plan template is great for SaaS companies looking to pull all their tracking and sales KPIs into one place (there are three sheets: one for your tracking plan, one for your analytics strategy, and one for your business objectives).

What we don't like: The design is a bit old school and may take a bit longer to figure out than others on this list. Also, there are some redundant fields (trigger and event definition, for instance), so the layout could be simplified.

Best for: The Mixpanel SaaS tracking plan template is best for—you guessed it—SaaS companies that are putting together their first tracking plan.

6. Mixpanel’s Template for Retail and eCommerce companies

Mixpanel has created a great simple template for retail and ecommerce companies that breaks down how to think about business objectives, analytics strategy, and tracking plan elements and includes some sample data for each area to help you get started.

What we like: The Mixpanel tracking plan template for ecommerce and retail companies includes some awesome example data for your tracking plan to help you get an idea of what to start off with. And, like the SaaS template, it features tabs for your overall KPIs, your analytics strategy, and your tracking plan, so everything is in one place.

What we don't like: Like the SaaS template, this one’s design is a little clunky, and some fields are redundant.

Best for: This template was specifically put together for ecommerce and retail companies.

7. Amplitude’s tracking plan template for ecommerce companies

This template is nearly the same as Amplitude’s basic template but includes some suggested events and properties for the ecommerce industry, which can be used as a jumping-off point.

What we like: Amplitude’s tracking plan template for ecommerce companies includes sample event and property names, as well as detailed instructions on how to think about each field of the plan. They also have included links to sample taxonomies that you can check out for more inspiration.

What we don't like: This is the same as their basic template, and it doesn’t include that much space for adding notes for developers.

Best for: This template is best for companies within the ecommerce space that are completely new to tracking and in need of some extra detail.

8. Mixpanel’s Tracking plan template for Media companies

Continuing on their industry-themed templates, Mixpanel created a great, simple template for media companies. Like the templates before it, this one breaks down business objectives, analytics strategy, and tracking plan fields.

What we like: The Mixpanel tracking plan template for media companies includes a great breakdown of the different elements you need to identify—everything from KPIs to events to implementation notes—to create a great tracking plan.

What we don't like: Some of the fields provided are redundant, like previous templates. Additionally, their provided KPIs and properties include some examples that aren’t actually relevant to the industry and can’t be implemented 1:1 into their platform.

Best for: This template is best for media companies that have already put some thought into their tracking plans and don’t necessarily need a bunch of examples.

9. Mixpanel’s Tracking plan template for financial service companies

Closing out both our list and our collection of Mixpanel tracking templates is this great template for financial services companies. Like previous examples from Mixpanel, this template breaks down info into KPIs and analytics strategy, as well as your tracking plan.

What we like: Like other tracking plan templates from Mixpanel, this one includes a good amount of detail to ensure that companies using it are breaking down their tracking plans to the right level.

What we don't like: Unfortunately, also like other tracking templates from Mixpanel, the information isn’t presented in the prettiest way, and some fields are redundant.

Who this template is best for: This template—as you probably guessed from the name—is best for financial services companies.

Now that you’ve got your tracking plan template, meet your best tracking analytics tool: Avo

There are lots of awesome templates out there to help you get started in creating your tracking plan. But no matter which one you go with, you can level up your tracking (and make the management of it easier) with Avo.

Avo works with nearly all of the analytics tools that developed templates on this list (sans Practico Analytics). So, no matter what template you choose, you can add your tracking plan to Avo and manage analytics implementation across all platforms.

Basically, we’re your source of data truth.

Create a free account today, or sign up for a demo to learn more.

Who should be involved in tracking plan development?

Avo — Mon, 16 Nov 2020 15:09:18 +0000

If you’re building a great product—which, if you’re concerned about data analytics, we’re betting you are—you likely have a capable team of people that support you. This team can help you build not just a great product, but an insightful tracking plan to learn from your data. All you have to do is invite them to your pre-release purpose meeting.

During your 30-minute pre-release purpose meeting, you and your stakeholders will align on goals and metrics to design data as well as possible with a comprehensive tracking plan.

Too often, teams lack alignment on why they’re working on a feature and how, exactly, they’re executing it, especially when it comes to communication between product, design, and engineering.

Instead, by including key stakeholders in your tracking plan development, you can get everyone on the same page and ensure the data you collect answers each team's questions. Furthermore, when you invite reps from every major team responsible for your product to help design your tracking plan, you avoid bad data. This is great for your sanity and business clarity when 41% of companies say bad data is their biggest challenge.

A tracking plan that includes the feedback and expertise of everyone from your engineers to your designers helps you align on the problem your new features are solving, why you’re solving it, and how you’ll measure your success.

In this article, we’ll break down exactly who should be invited to your 30-minute pre-release purpose meeting and what they contribute to the development of your tracking plan.

Engineers from each platform for technical details

When it comes to the technical design of your data and product, there’s no better resource than the developers that built it. Include engineers from each platform in your early purpose meeting so you can get their technical perspective on the design of your tracking plan and gut check what’s possible to track.

After all, your developers are the ones who best know what information is available at what points of the user journey and what data will be difficult to track.

Beyond just giving you the chance to tap into their knowledge, your purpose meeting will offer you a way to get them excited about the success of the feature you’re looking to track. Plus, it will help them understand the fact that data is an important part of your product’s success.

Once your developers weigh in on metrics and understand the role of data in your success, they’ll feel more receptive to implementing analytics with set best practices (which will go a long way in creating good data for your team to use).

You can get their perspective on what’s possible (or not) to track—and find the best way to structure events to reflect your metrics—by asking a few basic questions off the bat. These can include things like:

Do these event structures make sense from a technical perspective?
Is this information available at this moment in the application?

Armed with the answers from these questions, you can create better, cleaner data to help you better understand your features and identify ways to improve them in future iterations.

Product managers for better insight into your problems

Product managers are often one of the biggest consumers of your data post-release. But you shouldn’t wait until the data comes streaming in to ask them for their opinions on your product’s goals and success.

Instead, invite your feature’s product manager to your purpose meeting so you can leverage their insights to help you and your team understand the problem you’re solving, why it was prioritized, and where it sits within your company’s work overall.

Many of your product managers will have an opinion on your success metrics and the structure of your events. This is because they work closely day to day on aligning development workflows with overall business goals. Use this knowledge to help you create a tracking plan that collects good data to support wider company objectives.

To get the most out of your product manager’s time and knowledge, ask them the following questions during your purpose meeting (of course, feel free to add on more questions as you see fit):

What problem(s) are we solving?
What are the effects of the problem?
Why did we prioritize this problem and feature?
What is the goal of building this feature?

Once you have the answers to these questions, you and your team can design a tracking plan that directly ties into the problem your product is trying to solve (and produces data to support these goals).

Designers for accurate customer journey tracking

If you’ve sat in on tracking plan and analytics meetings before, a designer might seem like the odd person out on this list at first. But they provide incredibly valuable insight into your user experience and journey, which helps you design more accurate events and metrics.

Your designer will be able to tell you the exact design decisions and user flow for each section of your conversion funnel. This will enable you to accurately map out how a user will interact with your product and what actions are most indicative of their progress toward conversion.

Plus, if you need to make tracking changes down the line (or if your data points to the need for a design change), you’ll already have an open channel of data-driven communication with your feature’s designer.

To better understand your UX during your purpose meeting, you can ask your designer the following questions:

What does the proposed solution look like?
What are some important user interactions?
What are potential drop-off points?
What specific design decisions did you make at this point in the user journey?

The answers to these questions will help you and your team better understand the experience of your user and, as a result, design events and metrics that logically map to that journey.

Data specialists for the best data design decisions

The final team member you’ll want to include in your tracking plan development is a data specialist. Your specialist will be pivotal in ensuring your data is well designed and that you avoid obvious errors that would muddle your insights later on.

Your data specialist can help you settle on the appropriate naming schemas and double-check that the data you need is being fed into your tracking from day one. These data experts bring valuable perspective into what event structures work best to visualize your metrics. Insights into both of these areas will help you avoid the need to refactor tracking analytics in the future and increase the quality of the data you collect. Not only does this help you and the other stakeholders understand and leverage information about your product, but it ensures other data consumers can quickly parse what your data tells them.

Ask your data specialist the following questions to glean the best information from their experience:

Do these event structures fit our standards?
Will we be able to visualize this easily in our analytics tool?
Is there a better way to structure the events for visualization?
Are there any existing events and properties that we could be repurposing?

Combined with the insights you gathered from your developers, product managers, and designers, the answers to these questions will ensure your data is consistent and helpful post-release.

Take the next step toward a better tracking plan today

To develop a tracking plan that fully captures all the information you need about your upcoming release—and ensures that everyone can make sense of your data post-release—you need to include a mix of stakeholders in your tracking plan development early on.

Doing so will ensure that you have the perspective of every side of your product reflected in your tracking plan—and that all major stakeholders of your product release understand how to use data to measure success.

Once your tracking plan is ready to go, you can further improve collaboration between your stakeholders by using a tool like Avo. Avo not only helps you keep everyone on the same page by creating a single source of data truth, but reduces the chance of human error during implementation with easy-to-share instructions for developers.

Take a step toward a better data future and try Avo today.

Tracking Plan Guide: How to Pick Your Events and Properties

Avo — Thu, 12 Nov 2020 18:37:20 +0000

There are two ways to spend your post-product-release time.

One: You could spend a bunch of time and effort bugging your data experts to let you in on what your data is telling them, and then struggle to use that information to improve your product (slowly).

Two: You can quickly glean valuable insights from your data yourself and get started on the next cutting-edge feature release to delight your users.

Which would you prefer? Our 💰 is on option two.

Well, picking good events and properties is the key to ensuring that your post-release hours are spent celebrating your successes, not lamenting a lack of clarity in your product performance.

To really capture data-driven success, you and your team should pick your tracking-plan events and properties during your pre-release purpose meeting. Each of them should be mapped directly to your goals and metrics.

Here’s how to do it:

When to start looking at your events and properties

When it comes to designing and setting up your tracking-plan events and properties, the earlier you can sit down with your team, the better. Ideally, companies should set their events and properties during their pre-release purpose meeting.

We define a purpose meeting as a 30-minute get-together that includes all of your product’s main stakeholders and is held before every major release.

This meeting should include the following people:

An engineer from each platform
A product manager
A designer
A data specialist

You should use this time to align on the purpose of your product release and map out your highest-impact, lowest-effort tracking design to understand your release success.

Start the meeting off by aligning on your overall business goals and committing to the metrics you’ll use to measure success. Then, you can get to work on designing the events and properties that will feed into those metrics.

By picking your events and properties during this early stage, you reduce the chance of needing to refactor analytics down the road. This not only saves time and money but also preserves your sanity.

What to look at when choosing your events and properties

To collect good data, choose events and properties that support your goals and metrics. Good data is the kind that gives you insight into user interactions and the context around them (versus bad data, which is information you collect just because you might need it someday).

Your events and properties should fill in the blanks between the metrics you want to track and the way they connect to your customer behavior.

Each new layer of your tracking plan—from product goals to metrics to events to properties—will uncover a new layer of information about your product and your users. As you move down your data funnel, from the highest level to the most granular tracking, you should stop to ask questions to further break down the information you’re looking for.

To start selecting your events and properties, you can ask yourself and your stakeholders the following questions to understand the reason for your release (it’s good to start with the basics):

What are we trying to help users do?
What problem are we trying to solve?
Who are we solving it for?
What does success look like?

Then, once you have a framework to understand your product mission and its success, you can dig a little deeper to set your metrics (which will inform your events and properties). Here are some additional questions you can ask to arrive at your metrics:

How will we know when we’re successful?
What steps do users need to take to achieve this success?
Are there any points of dead ends or user drop-off that we want to keep an eye on?
Should we compare cohorts of users and A/B test the release?
Is our conversion achieved through a set of steps, a total count of something, or a rate?
How do we visualize and compare these metrics (e.g., time series, bar chart, bar per group, line per group)?

Once you have answers to these preliminary questions—and, as a result, know your goals and metrics—you can begin to identify your individual events and properties.

How to choose your events

To choose events, identify the questions that you most want to be answered about your product or features. Your answers to these questions will point you toward your events.

You can start at a high level with these questions by breaking down the steps that each user must take in order to count toward your success metric. From there, you can narrow it down to more specific queries to identify each action a user must take in order to impact your identified metric.

Let’s say you’re launching a new paid plan for a music streaming service. 🎵 If one of your main metrics and KPIs is to increase upgrades for the new paid tier from existing free users, you could ask the following questions to identify your first batch of events:

What is the first action a user has to take to begin the free sign-up process?
What is the last action a user has to take to complete the free sign-up process?
What is the first action a user has to take to upgrade their plan?
What is the last action a user has to take to upgrade their plan?
What are important milestones between the first and last action?
What actions could the user take to show us that they’ve dropped out of the funnel or hit a dead end?

The answers to the first five questions, respectively, would tell you that you need to track when a user views the plans page, when they submit account info for a free plan, when they log in, and when they submit payment information. For the last item on the list, the user would exit out of the site without completing payment.

Your events reflect specific actions your users take (or things that happen to them) along their full user journey within your product. Look at the metrics you’ve decided on, and start asking questions to drill down on what users have to do in order to count toward improving the metric (in the case of our example, the metric would be “increased upgrades to paid user”).

Once you have identified the events that support your higher-level metrics, you can dive deeper into the properties that support them.

How to choose your properties

Once you’ve set your events, you can begin to identify further insights you need and then figure out how you’ll segment your data with properties by mapping out the specific parts of each page and feature users interact with on their way to converting.

Properties are the dimensions (metadata) you’ll use to filter and group your events (they’ll help you clarify and get context on higher-level events). Off the bat, start with the questions about user segments you know you need (you can always add properties later when specific questions arise). This helps you reduce the noise from a bunch of data.

Building on our streaming example from before, let’s break down our events—view page, complete registration, log in, change plan, and abandon session—into their supporting properties. First, you should talk to your designers and programmers to identify each of the on-page elements the user must interact with to move further down the funnel. You’ll build a plan to track three categories of properties:

Event properties that are specific to the action the user performed. Example: "Game Mode" on the "Game Started" event or "Authentication Method" on the "Signup Completed" event.
User properties that are associated with the user and can be used for cohorting (analyzing a certain group of users). Example: "Games Count", "User Name" or "Subscription Status."
System properties that are sent with all events and don’t change during a user session. Example: "Platform" and "App Version."

For example, when our users log in, we want to track when they click the login button, when they enter their email address, and when they’re successfully authenticated. Then, when they’re ready to upgrade, we’ll want to track properties for payment type and payment validation.

To further understand where our users are coming from and what experiences they’re having, we also would want to track a number of system properties that span events (i.e., we collect the information at multiple points throughout our tracking). These properties include things like what platform (web versus mobile ) or browser type (Chrome versus Firefox) they’re using.

Now, with a robust combination of goals, metrics, events, and properties included in your tracking plan, you’ll be able to gain valuable insights into your product and user experience throughout your funnel and directly connect this data to your overall business goals.

What to do once you select your events and properties

Once you’ve designed your data by choosing events and properties that tie into your metrics and goals, it’s time to ship! 🥑 Well, almost.

Before you take everything live, you’ll need a document that’s your single source of data truth. This can be a spreadsheet (like this awesome tracking-plan template 😉) or a JSON file hosted on GitHub that outlines your events and properties. You’ll want to test your analytics before your full release to make sure no human errors snuck through during implementation.

Or, if you’d like to save yourself and your team some time (and make it easier to implement tracking analytics), you can use a tool like Avo. Avo replaces your old-school spreadsheet to give you a modern, single source of data truth that you can collaborate on with your team and tie into each platform you use. Plus, there’s no need to triple-check for human errors, because Avo handles the formatting of code—and sends instructions directly to developers—for you.

Get started on creating a better, easier data future by trying out Avo today.

Avo’s Ultimate Tracking Plan Template (w/ Downloadable Worksheet)

Avo — Tue, 10 Nov 2020 17:18:13 +0000

We talked in depth about why you need a tracking plan in our definitive guide to tracking plans; now, we’ll break down the awesome tracking plan template we created for you, so you’re ready to implement better product analytics via your tool of choice (possibly Avo 😉).

But before we dive in, here’s a quick refresher on what a tracking plan is (you may recognize this from our definitive guide to tracking plans):

A tracking plan is a document that defines the key stages of your customer life cycle and codifies a single source of truth for the data that supports it. It helps you standardize your data management and capture better and cleaner data.

As part of your tracking plan, you’ll need to outline the events and properties relevant to your goals, explain where in your codebase tracking code should be placed, and provide context for why you’re tracking what you are.

While each of the elements of your tracking plan will be as unique to your business as your product is to your market, you can save admin time up front by using a tracking plan template. There are dozens floating around the internet, so we went ahead and created our 🎉Ultimate Tracking Plan Template 🎉 that pulls together the 10 elements you absolutely must have. Use this template to spend less time researching how to make your tracking plan and more time using it.

What makes a good tracking plan?

Your tracking plan should include events and properties that help you understand your customers’ behavior and measure progress through your sales funnel and customer journeys so you can see how well your features are meeting customer needs. It shouldn’t aim to measure every drop of data under the sun—just those that are most important to you.

For the full breakdown of how to find the events and properties that mirror your customer journey, check out our full guide on tracking plans, and then meet us back here.

To get a full picture of your customers’ behaviors and experiences, you’ll need a mix of both qualitative metrics (the kind that reflect user sentiment) and quantitative metrics (the kind that reflect user actions).

Your tracking plan will focus on quantitative metrics. That's because it's possible to objectively measure whether an action happened. But it’s equally important that your sales and product teams reach out to customers and users via surveys, social media, and reviews to get qualitative data to complement your tracking plan.

The 10 key elements of your tracking plan

We have a lot of experience helping folks build killer tracking plans (and we’ve seen a lot of great examples of tracking plans from other companies, too). When we sat down and pulled from our experience—and the experiences of others—we noticed there were 10 key elements that every great tracking plan included.

1. KPIs

‍

Each event you track should tie directly to a business-end key performance indicator (KPIs) that affects your success, so you can easily reference the tie-in between metrics tracked and their real-world value.

These KPIs will change depending on your company maturity, product, and business strategy, but here are some examples:

Signup funnel
Retention from signup to playing game
Monthly new signups

This first section is what will give any business-end stakeholders the context they need to understand how the tracking plan ties into a wider strategy.

2. Event categories

Your tracking plan should break down events tracked by macro category—typically reflecting the different kinds of KPIs you’ve set—so you can keep track of each segment of customer success.

Like all things on this list, the kinds of events you’ll track will depend on your goals and use case, but here are a few examples:

Authentication
Gameplay
Tournaments
Navigation

Once you’ve set the broad categories of events you care about, you can drill down and decide on the specific events and properties within each category.

3. Event names

‍

Your tracking plan should include one row for each event name (each of which will have rows for child properties). Additionally, each of your events should be named in a consistent way that’s in line with your agreed-on naming schema. This structure makes it easy for anyone to quickly scan and understand what events you’re tracking.

Your event names will depend on the kinds of events you’re tracking and on your naming schema. Within the categories we outlined above, some possible event names could include the following:

Signup Started
Signup Completed
Login Completed
Game Started
Game Completed

Note how each of these event names shares the same tense (past tense) and capitalization. This isn’t just to make your template look pretty; it makes everything easier to understand.

4. Event description

‍

Your tracking plan should include a clear description for each event, including the event source (where the action is taking place) and any additional context of when and why the event happens. That makes it easy for anyone looking at your template to quickly understand what the event is tracking.

Your event descriptions should be no longer than one or two sentences and should clearly and concisely explain what it is you’re measuring (and when). Let’s assume that we’re measuring the event “Game Completed.” Our description for this event might be:

Event sent when a user has successfully completed a game.

Creating consistent descriptions for each of your events will make it easy for anyone using your tracking plan to gain the context they need to interpret your data.

5. Properties

‍

For each event, you should include a full breakdown of its attached properties, with one row per property—again, all named consistently—so you can easily see which properties are being tracked for a given customer action.

Bonus: You should also define your property groups (these can be spaced across event groups) so you can easily see what kind of user behaviors you’re tracking.

It can be easy to let naming conventions for properties slide, but ensuring that each property follows your schema will prevent data collection and compilation errors down the road. Let’s say we’re measuring gameplay events, particularly the “Game Completed” event we identified above. We might track the following properties:

Game Mode
Game Count

Each of these properties will tell us whether or not a specific user action was completed (e.g., “Game Mode” tells us the mode of the game the user played and “Game Count” tells us how many games the user has completed).

6. Property description

‍

Your tracking plan should include a clear description for each property so that any user can understand what the property is tracking and where the data is coming from.

Just like your event descriptions, your property descriptions should fill a column to the right of your property names and clearly and concisely describe what each property measures.

For example, if we’re tracking how many games players complete during their session, we may track a property called “Game Count”. Our description of this property might look something like this:

The number of games a player has completed when this event is sent. Including the game that was just completed on Game Completed.

This extra context will help anyone looking at your tracking plan make sense of all your properties.

7. Property value types

‍

Each property within your tracking plan will collect a different data type. These types should be explicitly laid out so developers implement across codepaths and platforms consistently. This also helps your data analysts know what to expect from the tracking analytics code output.

This is one of the few sections of your tracking plan that will not greatly vary. Instead, the data in this column should include these common data types:

int
floating-point number
boolean
string
datetime
a list of any of the data types above

When you formally identify these data types for each of your events and properties, you help your developers avoid coding errors that will impact data compilation down the line.

8. Platforms

‍

For each property, you should note what platform the data is coming from so you can keep track of which applications contribute what information to your dataset.

This will depend on the development platforms you use and how your codebase is structured. But here’s a general outline of some of the platforms you may need to think about:

For web: JavaScript, TypeScript or Reason
For mobile (generally): React Native or Expo or Flutter for iOS and Android apps
For mobile (Android): Java or Kotlin
For mobile (iOS): Swift or Objective C
For backend: one or more backend sources (depending on number of programming languages and micro services)
For game engines: Unity

Including this breakdown of platforms that contribute data to your app will ensure that developers know where to implement tracking analytics across the board, and you won’t forget about any key components of your product.

9. Status

‍

This is a really important one: Your tracking plan must indicate the status of each step of tracking analytics implementation. This ensures that your team--and your tracking plan stakeholders--have a clear understanding of what work has been completed, what needs review, and what is in testing.

For example, let’s say you’re tracking events and properties related to your login authentication method. You’ll need to note when that analytics code is ready for review and testing so your developers know that it’s not ready to ship, and don’t prematurely launch what could be a buggy bit of code.

10. Code snippet

Finally, your tracking plan should include your tracking code for each event and property that needs to be tracked so that your developers can easily place it into the correct spot without naming-convention or syntax errors.

If you’re doing this manually with a spreadsheet alone—instead of using a tool, like Avo, that can house your implementation code and send it directly to developers—this section can get a little lengthy.

By explicitly giving the code for each property, you reduce the likelihood of implementation errors and make the lives of your developers easier in the process! 🎉

Download Our Ultimate Tracking Plan Template

There’s a lot of thought that goes into creating a great tracking plan. You need to dive deep into your users’ behaviors and attitudes to measure the metrics that reflect your progress toward KPIs. Even with this awesome DLC, doing this manually is a bear.

Once you’ve created your tracking plan using this template, head on over to our site to see a demo of how you can use Avo to convert your plan into an easy-to-manage and easy-to-share single source of data truth (Bonus: we can also import your tracking plan directly when you use the DLC above).

What is a Tracking plan, and why do you need one?

Kelsey Fecho — Thu, 29 Oct 2020 19:55:41 +0000

Picture the most chaotic project you’ve ever worked on that was saved at the last minute by an overhaul of project planning. You know the one--the project that kept you late at the office, blew deadlines, and caused every person on your team frustration.

That is, it did, before you and your team rallied behind one another, set out a detailed plan of attack to get things back on track, and saved the day.

To do this, you had to sit down and figure out exactly where you were going wrong and then lay out all the steps, processes, and best practices you need to correct the chaos and reach your end goal.

Now, let’s say that instead of this chaotic period of product purgatory taking up your time, it’s actually bad data that’s eating up your productivity. Or, as we say, you’re having a Bad Data Day. Like it's project management cousin, a Bad Data Day is a chaotic hole of confusion. Product managers and developers alike can never figure out what’s going on with it, causing inconsistent insights and, if we’re being honest, a bunch of colorful language and headache.

So, like you did for your chaotic product release, you need to block out time to sit down and deal with your Bad Data Day, head on. The key to doing this? A data tracking plan.

This tracking plan will help us turn our Bad Data Day into a Fantastic Data Feeling. As a centralized document that our entire organization uses, we’ll be able to conquer our Bad Data Day, and ensure our data helps us make progress toward our goals.

In short, our data will go from our biggest bummer to our greatest asset.

But before we help improve our Bad Data Day and transform into our true rockstar selves, it’s important to understand what a tracking plan truly is, and why we—and any modern business—need one to deal with bad data in the first place.

What is a tracking plan?

A tracking plan is a central document that everyone in your organization can refer to for data management best practices. It standardizes the events and properties you track, determines where within the code your analytics should be placed, and outlines the reason why each event is being tracked in the first place.

Your tracking plan should include the rundown of what events and properties matter most to your product performance. These metrics should be carefully mapped to your customer journey so that you can see how well you’re serving your users’ needs at each step and build a better product in response.

Ultimately, your tracking plan will be your single source of data truth so that all analytics across every one of your platforms tie neatly together. This will allow you to focus on what your data is telling you rather than argue with it.

Why you need a tracking plan

Long story short, you need a tracking plan so you can have what everyone at your company wants: good, clean, informative data.

But there are typically three things that get in the way of such data:

Too much tracking: This is your classic “garbage in = garbage out,” where you measure everything and then can’t parse what matters.
Too little tracking: This means no tracking was set up (or only set up for irrelevant metrics), so customer behavior is locked away in a black box.
Inconsistent tracking: This is the most common issue and is the result of chaotic event and property naming (e.g., customer_signup vs customersignup vs signup) that prevents you from getting the whole picture from your data.

Thankfully, a tracking plan can undo the damage caused by all three of these data plagues. And, in the process, it will help everyone—from your product managers to your developers to your salespeople—make better business decisions and understand the impact of their work.

Here are the four main reasons you need a tracking plan.

1. To ensure you can accurately measure progress toward your goals

If the bar you’re measuring your progress with is bent or broken (e.g., bad analytics tracking and unreliable data), you don’t actually know how you’re measuring up to your goals.

A tracking plan gives you the framework you need to measure progress toward your KPIs by ensuring that the bar with which you measure yourself is accurate. Without this central source of truth, your core set of metrics won’t be defined, your events and properties won’t match up, and you’ll be guessing at your progress.

With a tracking plan, however, you can measure progress toward your goals by examining and selecting the metrics that support your user behaviors and directly correlate with your mission. Your tracking plan will then ensure that you’re capturing all the data you need to get the full picture, unlike many companies who see 60% to 73% of their data go to waste.

2. To help you understand what customer actions matter most

Building a tracking plan forces you to identify the biggest signalers of user behavior and satisfaction. This helps you understand your customers better and build a product that best suits their needs.

You need a tracking plan to get this understanding, because simply tracking every user action doesn’t tell you an accurate or clear story of your user experience. In fact, the “track everything and we’ll sort it out later” approach is one of the most headache-inducing legacy data practices around.

You can better understand your customers’ actions thanks to a tracking plan by auditing your full user journey, identifying the main goal and purpose of your product, and then focusing on the metrics that tell you whether a customer realizes this benefit.

3. To empower developers to implement tracking consistently

A well-thought-out tracking plan is the clarity that helps developers implement tracking consistently by creating a single source of tracking truth that they can refer to for naming conventions and code placement.

Your tracking plan helps empower developers to take ownership of the implementation of analytics and ensure tracking code is placed consistently. As part of the journey to clean analytics tracking, developers can easily check to make sure naming conventions for events and properties are inline with best practices, and that tracking is implemented correctly across each platform.

As a result, all of your related data will match up, and you’ll never have a Bad Data Day again.

4. To help you make better product decisions

Finally, and perhaps most importantly, a tracking plan helps you make better product decisions by giving you good, clean metrics to back up new features and changes to your platform.

As any successful founder and developer will tell you, it’s not enough to build a great product once. You have to continue to improve and deliver more value. Data, as a result of your tracking plan, shows you where and how to do this.

You’ll make better product decisions with your tracking plan in place because you’ll have a common language (data) between all teams and shareholders. This will let you advocate for changes, help you understand what to fix and adjust, and tell you when it’s time to pivot your product offerings based on market demand and fit.

Upskill your data with the tracking plan—and data tool—that fits your needs

It’s easy to feel apathetic about adding another governance document to your to-do list, but tracking plans aren’t like the rest. These superheroes of data will completely shift how data works for your company if you put in the work to create one to match your needs.

Avo can help. We give companies the ability to make the right data-driven decisions with clean, reliable, accurate product analytics. Through our platform, you can easily manage your tracking plan, send implementation instructions to developers, and collaborate with your team to tie together all the data from the platforms you use most.

Together with good data governance best practices, we can help you quickly set up and enforce your tracking plan so you can spend less time wrestling data and more time shipping a great product.

Start using Avo today.

How we create and manage a ReasonML Code Style Guide at Avo in a democratic and open way

Avo — Tue, 27 Oct 2020 14:17:36 +0000

At Avo we write most of our code in ReasonML, a strongly-typed functional language operating on top of the Javascript ecosystem. It’s a great tool (a strongly-typed functional language operating on top of the Javascript ecosystem, you know) that also has its challenges.

Two challenges we’ll cover here are bringing new people into the project and improving code quality. Both are not new and are relevant to any programming language, but given the nature of ReasonML, building tools to address them becomes crucial for the effectiveness of the product development.

Luckily, there is an old and proven way to address those challenges - a code style guide. But, if a good code style for a popular language like Javascript or C++ is easy to find, when you work with a niche language like ReasonML you are left to create the code style on your own (or adopt ours 😉).

How Avo built a democratic approach to our code style

Here’s how we approach it at Avo. In our first attempt at defining a code style the project was already a few years old and we were 4 developers.

We started out making a list of issues we face daily in the codebase. It was a collaborative document, everyone could submit there. Next, we discussed it at our developer roundtable. It's a meeting we hold every 3 weeks where all developers discuss matters related to engineering.

One of the topics on that particular roundtable was our code style. We spent an hour going through the list of suggested ideas and ended the roundtable with an actionable - one of our engineers would make a subset of the discussed topics that everyone agrees on that would become the first iteration of our official Code Style Guide. The Avo ReasonML Style Guide was born. It felt great to have a code style. On the other hand it was small and definitely incomplete, that’s why we labeled it v0.1. We had to iterate and improve, so we designed a process for that.

We use Asana to manage topics to discuss in our developer roundtable, and we have an ongoing topic for code style contenders. There anyone can suggest a new rule for the code style. Then all the contenders are discussed at the meeting and the items we agree on go into the code style. We really like this approach because it democratizes our code style and brings all new issues to the attention of all developers, so everyone knows the latest state!

Today we open our code style to the public, you can find it in this GitHub repo. Please share your ideas of new items to add to the guide in the issues section!

Building for Collaboration

Avo — Thu, 22 Oct 2020 14:22:23 +0000

The feedback we’re most proud to consistently get from our customers is how Avo makes collaboration across teams so much easier. Bringing together engineering as well as data and product team is no small feat and we are always working to continue streamlining that process. Creating the right workflow, that works for everyone involved, is how successful product companies today operate. We’re excited to tell you more about how to make collaboration within Avo even more seamless.

‍

Enable SSO on Your Workspace

Anyone on your team can log in using SSO. There's no need to send invite links anymore, or set up each individual team member.

Protect Main Branch

Worried about accidental changes being made on the main branch with this influx of new team members now on your Avo workspace? Configure your workspace to disable direct changes on the main branch – and require at least one approval from a colleague before a branch can be merged.

Introducing Approval Workflows

We are thrilled to tell you about our approval workflows. Have your peer reviewed to maintain the data quality you've worked so hard for.

If you're still working on a branch, keep it as a draft. Ready for review from your team? Ask them to review by updating the branch status to Ready for review. Happy with the suggested changes? Approve them!

Add Branch Status

Now you can update the status of your branch and notify all branch collaborators that the status just changed. Below is how we at Avo think of the approval workflow:

And Finally, Comment on Specific Items‍

On the branch review screen, you can now comment on specific items. This is one of our most highly requested features of them all, and it’s now live!

Comment on specific item changes on the branch review screen 💬

‍For future reference all discussions from the branch review screen are kept in context of the item after the branch has been merged.

‍

Now Live!

Review workflows are now live on all Avo workspaces, with approval workflows available for upgraded accounts.

Get started today!

How to Settle your Analytics Debt

Avo — Tue, 06 Oct 2020 14:02:34 +0000

We've learned that companies go through these analytics maturity levels on their product journey:

No data. “Let’s just get our product to work and find someone to try it.”
Any data better than no data. “Whoops, we shipped without a way to know how it went. Can we add some tracking and release the app again? Maybe track this button and this button.” Data is an afterthought and a free-for-all.
Data debt: Bad data worse than no data. “I don’t trust this data. Do I use the 'Game Started' event or the 'Start Game' event? Or both?” Bad data has started confusing teams and risking detrimental product decisions.
Fix it and govern it. “We need to do something to stop making bad decisions based on misleading data; we’re breaking a chart in every feature release!” Teams start building workflows and home made tools to automate QA and maintain a single source of truth tracking plan.

Analytics debt becomes a pain when you start feeling that product market fit and your team starts scaling. When your product is available to users across platforms, and the tracking isn’t consistent across all of them. When more product managers join, that “any data is better than no data” starts becoming a growth blocker. People will make wrong decisions based on misleading data. Onboarding new developers becomes difficult. That “let’s just add this quick line of code to track this user action” is very easy to accidentally refactor out. Existing tracking breaks in every feature release, and it’s difficult for new developers know where to start when adding analytics for feature releases.

Analytics Debt is when you have incomplete, inconsistent, and bad data, and the only way to make data-driven decisions is to add more bad tracking because fixing what you have feels impossible.

At Avo, we’re here to help.

The Avo Inspector helps you:

Inspect your current state of tracking:

Install the Inspector SDK for all your platforms, to start logging event names, shapes, types, volumes, etc. and get all current tracking in a single source of truth.

Analyze tracking issues:

The Inspector dashboard will summarize your current state of tracking and highlight current issues such as volume discrepancies between platforms and missing properties.

Prioritize what to fix:

You know your tracking is a mess, but where to start fixing it? Use the Inspector dashboard Filters to share direct issue links to colleagues. Make your tracking issues are something you can reason about.

Fix important tracking:

Define what events should look like. Build your tracking plan in using the Avo Event Library and Property Libraries to prevent inconsistencies that happen when data is designed manually in a spreadsheet

Future-proof your analytics:

Avo is the state of the art for planning and implementing analytics, so you can ship faster without compromising data quality.

Collaboration: A GitHub-like branched workflow for Product, Engineering and Data to work together on multiple features at the same time.
Reliability: Type safe analytics code to implement faster without compromising data quality.
Transparency: Single source of truth tracking plan to empower the team to always know which events they can use to answer their questions.
Relevance: Unblock everyone to suggest data according to team guidelines.
‍

Avo Inspector Issue Reporter

‍

The Avo Inspector helps Product teams understand their current state of tracking so they can make good decisions, Engineering teams ship faster without compromising data quality, and Analytics teams support their product teams in maintaining clean data.

So you can get back to making data-driven decisions.

Your Company Can't Afford Data Debt

Avo — Thu, 01 Oct 2020 15:38:06 +0000

Would you rather spend your time using data to fuel innovative new product features or sit at your desk for hours trying to make sense of messy metrics? That should be a no-brainer (unless you’re some kind of data masochist).

Unfortunately, many product managers and data analysts spend more of their time fixing bad data than they do using it to propel their products forward. In fact, according to Harvard Business Review, only 3% of companies’ data is of good quality, and Forrester estimates that making sense of the bad data takes up more than 40% of data analysts’ time (some estimates are as high as 50%). Furthermore, an MIT study found that only 3% of the data from sampled enterprises was good quality, with at least 50% containing critical errors.

There’s a word (technically two) for the time and money cost of dealing with this bad data: data debt. And debt, even good debt, sucks.

Data debt is the cost of short-sighted data decisions. One of the biggest contributors to data debt is messy analytics tracking, meaning each product team implements analytics tracking however they see fit. This creates a hodgepodge of different event names and data points that takes time (and money) to untangle later on so it can be compared.

Like other debts—student loans and mortgages—data debt is ubiquitous. And, like other debts, you need to be in control of it.

The great news is that clean analytics tracking can help you wrangle your debts, get them under control, and prevent your balances from going up in the future. The opposite of messy analytics tracking, clean analytics tracking means you’re taking an active role in measuring metrics that are relevant to your business, auditing your sources of data, and ensuring that everyone implements analytics correctly so you can trust your data.

When you invest in clean data analytics, you can understand your current debt, pay it off, and prevent it in the future.

What is data debt?

If you’ve waded into the world of Agile and DevOps, you’ve probably heard of technical debt (i.e., the price of choosing ad hoc/short-term solutions over the more strategic route). Data debt is the debt you rack up when you make ad hoc data governance and management decisions without thinking about the long-term impact on your data health and usability.

The issue with data debt is that it creates problems you’ll have to untangle in the future. And each problem takes time to fix and creates further murk in the water you have to wade through to make decisions.

But despite this, data debt isn’t an inherently dirty word. It’s a way of understanding the cost of doing the right things versus just doing what works in the moment.

If we take a closer look, data debt typically takes on one of four forms (as shown in the graphic below):

Selfish debt that comes from decisions we know are bad but deliver enough immediate personal value that we think it’s worth it (think “treat yourself” shopping decisions made when you’re stressed out)
Ignorance debt that’s generated by unplanned, spur-of-the-moment decisions that don’t give us enough time to think about the long-term impact (think that last minute trip to Vegas with good friends)
Immature debt that companies generate along the way to good governance via trial and error (think the kind of debt you rack up when you’re 18 and figuring out how finances work)
Acknowledged debt that’s the result of measured decision-making that determines taking on new debt is the best option available (think mortgages and student loans)

Like their real-world financial counterparts, not all types of data debt are created equal. Some types of debt, such as immature debt, are a part of the journey to good data governance, while others, such as selfish debt, are signs that data management best practices aren’t being followed.

The trick to minimizing your data debt is a mix of good data governance and clean analytics tracking. The former prevents selfish and ignorance debt and the latter helps you uncover the sources of your debt, settle up on your balances owed, and prevent future debt down the road.

When you combine macro governance best practices with the ability to consistently implement tracking and measure metrics, you can make better business decisions and better prioritize and communicate the importance of larger, strategic product choices.

How clean analytics tracking helps conquer data debt

As much as we love clean analytics tracking, it’s not going to pay down your debts for you. Rather, as you put in the work to develop, implement, and support clean analytics, your data debt will naturally go down (and you’ll be able to avoid it in the future).

When your analytics tracking is messy, everyone from your developers to your product managers can trust your data. All the short-term data decisions you made in the past make your future data all that much harder to understand, leverage, and, ultimately, trust.

If you can’t trust your data, you can’t use it to make good product decisions. To get rid of your data debt and build trust in your information, the logic behind your analytics tracking needs to check out. That means creating a single source of data truth—aka clean analytics tracking.

Just like real-word financial debt, you can’t start dealing with data debt until you know how much of it is hanging above your head and how it got there in the first place. To understand how much debt you have, you need to sit down and audit every platform and application that you, your teams, and your product work with.

Then, you can figure out which applications generate the most data debt (that is, which individual tracking calls were implemented in a way that causes the most downstream work), come up with a plan for resolving those issues, and outline a framework built on clean analytics to prevent debt-creating decisions in the future.

Clean analytics tracking will help you understand your data debt

To develop and implement clean analytics tracking, you’ll need to come up with tracking best practices through a tracking plan.

When you’re building out these best practices--such as establishing naming conventions, outlining where code should be placed, and defining which events matter most--you’ll uncover all the instances of messy tracking that you’re currently using. This process of discovery and clean up will help you understand what previous analytics choices were causing your debt, and help you systematically eliminate them.

In many cases, data debt is caused by poor tracking-analytics implementation. Often, this happens when developers have to quickly set up and integrate new tools or third-party applications and either don’t know how to follow best practices (because they’re aren’t defined) or choose not to for the sake of speed and convenience.

This was the case for a client of ours, Termius, from day one. Like most software companies, Termius serviced several platforms, and each platform had its own applications and codebases throwing their own data. It was an uphill battle to sync all of their analytics together, and their developers often made mistakes implementing analytics across the board.

If they couldn’t check the logic of their analytics, they couldn’t trust their data. So they needed better analytics to pay off their data debt and make better decisions.

Back at the beginning of 2019 (which feels like eons ago), Termius had started developing a plan for how their data should be. Based on the document, we worked with them to identify issues and set their tracking plan up in Avo. From there, they were able to implement events in their codebase and fix future issues along the way.

As a result, Termius developed a holistic understanding of all of the issues racking up debt and took the first step toward paying it off.

Clean analytics tracking will help you settle up your data debt

Clean analytics tracking helps you settle your data debt by forcing you to standardize your messy analytics. To set up clean analytics tracking moving forward, you have to resolve the implementation issues committed in the past that caused your debt.

To start, take your list of data debt sources and look at which ones have the biggest impact on your day-to-day operations. Is there an implementation error that’s more egregious than the rest? Or does one of your applications contribute more user and product data than the others but have inconsistent event and property naming? Start there by correctly implementing your analytics tracking to be in line with your central tracking plan.

Settling up data debt will prevent headaches downstream for years to come and save your data analysts (and everyone, really) time on the back end trying to make heads or tails of miscellaneous data.

You can do this work manually by having your developers look at the implementation of your analytics tracking code for each application or by using a tool like the Avo Inspector, which analyzes your data for you and flags issues in your tracking setup.

Using tools like Inspector alongside clean analytics tracking tools like Avo will help you discover data issues and see which ones are causing the most issues. From there, you can untangle the worst data offenders within your stack and begin to enjoy the fruits of your labor.

Clean analytics tracking can help you prevent future debt

Clean analytics tracking helps you avoid future data debt by ensuring that people don’t make the same kinds of short-sighted decisions that ballooned balances in the first place. To set up clean analytics tracking, you need to adhere to a tracking plan as part of larger data governance, which will outline how all tracking decisions should be made to prevent messiness.

This benefits everyone in your company and prevents data debt in the future. Product managers now have data they can trust to back up product decisions, and developers know exactly how to implement analytics every time to prevent future debt and don’t have to try (and often fail) to track changes between releases. This central strategy for setting up how analytics are implemented—and when—prevents in-the-moment product decisions that need to be untangled down the line.

At Termius, having clean product analytics through Avo meant product managers no longer had different sets of metrics and analytics for each platform (the source of their data debt). They didn’t have to check between each application to make sure they were comparing data apples to data apples. Instead, their developers and product managers could look at the data and know that the context of it—the events and properties it was tracking—was the same no matter the source.

As long as you maintain your data governance best practices, you’ll achieve clean analytics tracking, and you’ll be able to trust your data to help you make any decision that comes your way.

Take a step toward data debt prevention today with Avo

Once you understand how your data debt came to be, it’s time to take the first step toward eliminating it and freeing your business from its grasp. Avo makes clean analytics tracking possible and easy, and our leading product analytics platform can help you use your data to support better business.

Start chipping away at data debt—and prevent future data missteps—today with Avo.

Avo CEO, Stef Olafsdottir, talks Developer Productivity at DevRelCon Earth 2020

Avo — Thu, 24 Sep 2020 20:55:04 +0000

Stef Olafsdottir, Avo’s CEO, speaks about developer productivity at DevRelCon Earth 2020.

For those who don’t know, DevRelCon is an event series for developer relations and experience for developers by developers. Normally hosted in London, San Francisco and Tokyo, Covid-19 made 2020 a global affair with all events hosted online.

We at Avo are on a mission making sure product teams aren’t constantly forced to choose between product delivery speed and data quality. We provide an easy-to-use interface to define and maintain your tracking plan (as in your taxonomy, data plan, event schema). You could say we’re in the business of efficiency, not just for developers but for product managers, data scientists, and everyone else working with developers on shipping products.

“Instrumentation used to take 1-4 days for every feature >release and now takes 30-120 minutes.”
– Maura Church, Director of Data Science, Patreon

It sure is heartwarming and wonderful to hear feedback like this, and we could take their word for it, or we could do what’s in our DNA as data scientists and engineers: measure it.

Keep reading to learn about our journey in taking a gut feeling, to qualitative customer testimonials, to learning how we now measure developer productivity through their own product measurements.

Measuring Developer Productivity Through Avo's Own Product Measurements

Stef Olafsdottir, CEO and Co-Founder of Avo, is a mathematician and philosopher, turned genetics researcher, turned data scientist, turned founder. She was the 1st data person and Head of Data Science at QuizUp, a mobile game with 100m users, where she built and led the data science division and culture. This included pioneering company-wide ways to prioritize product innovation. At QuizUp they built a culture where people had the tools, data literacy, and data reliability to ask and answer the right questions.

After QuizUp, she and a couple of friends started a company. Only 5 months in, they shipped a product update based on incorrect data. It was a frustrating misstep that helped her realize the importance of the tools and infrastructure they built at QuizUp to keep up data reliability. Furthermore, they wouldn’t afford taking the time to build the tools internally again. They would have to choose between data quality and velocity - for every single product release.

Before Avo, teams have been constantly forced to choose
between product delivery speed and reliable insights.

After a conversation with several of their colleagues at companies like Twitch and Spotify, they learned that many had built the same internal tools to address this problem of inconsistent event analytics.

Look familiar? Yes, we can’t stand it either.
‍
So they decided to build Avo to solve this problem once and for all. Using Avo to ensure the schema is always correct, means graphs displayed in tools like Amplitude and Mixpanel are accurate. This means product managers and data scientists can trust the data accuracy and provides immense value in how quickly product teams are able to ship analytics code, without bugs. This increased efficiency is what allows product teams using Avo to ship quickly without sacrificing data quality.

Qualitative Learning: Why Our Customers Like Using Avo

Looking at this qualitative feedback from our users reveals a clear theme. Everything is just a lot quicker. We’re not talking shaving off a few minutes. It’s an order of magnitude in company cost. Not only is implementing event analytics taking a lot less time, the quality is also vastly improved. Even companies like Rappi, who highly value analytics, and already have great insights in place, are spotting missing properties and other data issues that Avo is able to highlight, making it a lot easier to scope out what needs to happen next.

Two themes are clear:

Operational efficiency
Increased data quality and reliability

The question is then, how do we take this incredible feedback and have it tell this story of efficiency not just in semantics, but in cold hard data? In other words how do we measure reliable operational efficiency, quantitatively?

How does Avo measure “Operational Efficiency” quantitatively?

We looked at one of our most loved features: a branched workflow for your tracking plan. It’s like GitHub’s branched workflow for code. As we care about operational efficiency, the time to completion matters. That’s why we started measuring the turnaround time of completing the implementation of a tracking plan change, defined as branches being opened and merged within one day.

“Branch Opened” -> “Branch Merged”

After conversations with our customers we soon realized that one of our opportunities to increase the turnaround speed of a branch was making collaboration even smoother.They were desire-pathing the process by creating internal Slack channels and assigning collaborators there (this even included our own team!).

We shipped Branch Collaborators and updated our notifications based on what we heard our customers were using Slack for. The collaborative work ensures data quality and reliability as any relevant stakeholder: a data scientist, a product manager, a developer can be brought into the right branch with a single comment, for a peer review.

To measure the success of the feature release, we looked at the turnaround time of collaborative branches, where at least least one comment was made.

“Branch Opened” -> “Branch Merged” with > 0 comments

We already saw a 70% increase in this metric in the first week after release. And that’s how we measure developer productivity of our customers.

Watch Stef's talk in full

To Ship Tracking Faster Than Ever

Our mission is to enable product teams to ship quickly without sacrificing data quality. It’s critical we can measure developer productivity through our own product measurements, not just based on our guts or a nice comment from a customer, but to have that qualitative data inform a measurable impact in data.

How Termius developers make self-serve data-driven product decisions

Avo — Tue, 15 Sep 2020 14:55:37 +0000

“We believe in data-driven growth that doesn’t just come >top-down, so we build product thinking into our processes. >Avo’s integration with Mixpanel’s Lexicon has been integral >to realize this vision”.
– Kirill Yakovenko
‍Product Manager

Termius is the SSH client that works on desktop and mobile. It provides software engineers with a complete command-line interface (CLI) accessible on any device, allowing system administrators and network engineers to access their terminal from anywhere. It’s used by over 45,000 engineers daily, and is famously installed on Steve Wozniac’s iPhone.

Kirill Yakovenko is a product manager heading up analytics quality at Termius. “I think about what problems our users are solving day-to-day, while making sure our data is correct,” he says. The Termius culture empowers anyone on the team to develop their own analytics to better understand user behavior within the product.

“My role is to support this democratization of our product development, by peer reviewing suggested analytics updates and upholding our data quality standards,” Yakovenko explains. This includes assisting his team in designing and implementing high quality product analytics, while making sure they’re not already being tracked elsewhere.

Termius’s tech stack is JavaScript for web and desktop, Python on the backend, Java for Android and Swift for iOS. The team recently added Mixpanel to their product analytics stack.

Termius' challenge from day one was how to keep analytics consistent across the multiple platforms they serve. Each platform has numerous applications and different codebases, and analytics implementation is error-prone enough even on a single codebase.

How Termius Builds The Best Customer Experience Using Product Analytics

Termius is all-in on data-driven product growth. They’ve built a feedback loop between qualitative user feedback, verifying their learnings with product analytics – and vice versa. Yakovenko explains that the purpose of this approach fills in limitations of either approach.

First, the data can verify if users’ actual behaviour matches up with what they believe their behaviour to be, so insights from user interviews can be quantified with analytics. And for the reverse he adds, “it’s easy to get the numbers wrong.” “When we get insights from the data, we go back to the customer to verify that the data was right.” At the end of the day, it’s about reaching the best possible understanding of how Termius is used. “The source of the data doesn’t matter, we want the truth.”

Here’s an example that relates to Termius’s northstar metric, ‘Number of Connections to Servers.’ When the team discovered a seemingly mild issue in establishing such connections, they adjusted their analytics to measure what problem users were experiencing at a high level. “The data revealed a critical issue for our target audience,” states Yakovenko. This data-driven approach saved the team and their customers a lot of time and efforts otherwise spent on user feedback sessions.

‍

“Before Avo, We Couldn’t Trust Our Data”

Keeping analytics synchronized across all of Termius’s platforms was an impossible feat before Avo. When writing analytics code, it’s easy to produce minor issues, such as different names or inconsistent casing for the same event, that escalate into a mountain of data-debt, rendering the data you do have noisy and unreliable. What seems like a trivial error, isn’t.

‍

“Each mistake undermines our trust in our data”
Kirill Yakovenko.
‍

“To combat this we needed a place for collaboration, where we could define all events with all possible properties, values, descriptions and other event meta-data”. Since using Avo,“ our trust in our data has increased.”

The problem wasn’t only that lack of trust. “The problem with tracking mistakes,” says Yakovenko,”is that each fix takes time. It might take a month to roll out a fix for a single issue to all our applications and users.” Fixing analytics issues didn’t just waste developer hours on the fix itself, it also delayed product decisions because insights are crucial to making the right product decisions.

“The human hours spent per analytics implementation has >reduced substantially, saving a huge number of hours while >fixing differences between platforms and commonplace >mistakes”.

“Avo’s biggest impact was in reduced overheads on analytics. We’re not only saving time for developers and product managers on designing, implementing and verifying analytics – but developers are also relieved that they no longer have to monitor the analytics after every release, to make sure the tracking didn’t break.”

Modern Developers Have To Have Product Skills, And Avo with Mixpanel Helps Unlock That##

Mixpanel is a leading product analytics platform that allows companies to answer questions about user behavior in seconds, without analytics expertise. This enables product development teams to measure what matters quicker, make decisions to improve experiences, and build better products through data. Over 26,000 companies including Uber, Expedia, Twitter, and Ancestry use Mixpanel to understand how their users convert, engage and retain.

Mixpanel and Avo partnered in 2020 and the integration built between the tools allows tracking descriptions, properties, and categories to be easily published to Mixpanel’s Lexicon with a push of a button. By customizing which events in Avo are published with their tracking plans, teams can understand more easily than ever what their data means. This organization and cleanliness has given Termius a restored trust in their data.

“To power their data-driven product growth, Termius needs to >fully trust their data“
‍

“The value of having the Avo descriptions in Mixpanel is immense,” says Yakovenko. “Having the context where needed and removing any guesswork around the events saves time and effort for our developers and other product managers. Those who aren’t in the weeds of defining analytics can now see in Mixpanel what the events mean.”

“That is really important to us because we believe in data-driven growth that doesn’t just come from the product manager. Instead we build product thinking into our processes” Yakovenko explains. “The same goes for meetings; when we look at the data, the context is right there. Descriptions allow us to see immediately what is going on on our graphs.”

The long-term benefits of democratizing product thinking are clear. “We need everyone on the team to understand what we’re trying to achieve, not just with our code but what our customers need. When the developers ‘get it,’ they generate good ideas, challenge us as managers and challenge us on the product. Their suggestions are richer and provide better solutions for our customers when they understand the business and our goals.”

“Some developers just care about the technical work and don’t want to understand business, goals and customers. But in modern product development and for a modern start-up, you need all hands on deck to move your business forward: combine skills, combine ideas from everyone on the team” says Yakovenko, “and then: Prioritize. Analyze. Iterate.”

Recommendations

For anyone who’s looking to start standardizing their analytics and streamlining the implementation process, Yakovenko has the following insight: “Avo offers real benefits, especially if you are cross-platform or have a big team.”

Announcing Inspector and Avo’s $3M Seed round

Avo — Thu, 03 Sep 2020 15:54:03 +0000

We started Avo in 2018 because we believe we can change the way organizations use data to make better decisions for their customers. We’ve been blown away by the impact Avo has had on data quality and developer productivity for our customers. From startups to consumer brands like Rappi, Patreon, TripAdvisor, Sotheby’s, and more, it’s been incredible to see our product fundamentally change the way PMs, devs and data scientists collaborate to plan, track and govern their product analytics. Today, we have some exciting news to share about our progress, a new powerful product offering, and where we’re headed next.

What is Avo?

Avo is next-generation analytics governance. We’re changing how product managers, developers, and data scientists plan, track, and govern analytics across organizations. Before Avo, teams were forced to choose between product delivery speed and reliable insights.

By using Avo, Patreon has reclaimed 9 out of every 10 hours they used to spend implementing or fixing analytics, going from 4 days for every feature release, to 1 hour.

Companies have never had to understand their customers better or faster. Consumers choose the product with the best experience and companies can’t afford to stall product decisions while waiting days or weeks for answers from a centralized BI team. In truth, the industry gold standard is to decentralize business intelligence completely, so that every team is autonomous in making data-driven decisions quickly. Spotify is just one example of a company working under this org-structure.

But data is brittle and bad data leads to incorrect assumptions. With everyone making data-driven decisions, it’s critical to govern data quality, iterate quickly on the product and business, and avoid customer churn.

We solved this problem ourselves at QuizUp, to ensure engineering and product time wasn’t wasted re-implementing analytics every time we shipped to our 100M users. Avo solves this more permanently as a SaaS platform without diverting precious time from the core product or accruing technical debt. The result is that we’re helping organizations grow by removing friction around analytics governance and implementation.‍

Introducing Inspector

The first step to better analytics governance is knowing what’s wrong with your data. Typically, getting that understanding has been a company-wide initiative that takes months or years, and requires buy-in and collaboration from the VP Product, Head of Data, and VP Engineering.

Today we’re excited to announce the Avo Inspector. Avo Inspector plays into our larger vision of empowering self-serve analytics.

Inspector processes event streams, parses event shapes (no PII data), visualizes the entire current state of tracking for the company, highlights tracking issues such as type mismatches, missing properties, and volume discrepancies. We built Inspector because we had helped our customers do this manually too many times.

With Inspector, our customers get instant insight into what is wrong with their analytics, so they can prioritize the most important issues to fix, and start cleaning and future proofing their analytics step-by-step.

So far, we’re getting great early feedback. On-demand delivery unicorn Rappi is just one of the customers using Inspector:

“This year we scaled to meet the demand of 100,000 new customers digitizing their deliveries and curbside pickups. The problem with every new software release was that we’d break analytics. It represented 25% of our Jira tickets.” Says Rappi’s Head of Engineering, Damian Sima, “In our first week with the Avo Inspector, we’re already discovering tracking issues like missing properties and type mismatches. Now we know what to fix and can do that with Avo.”

Here’s how Inspector works:

1. Inspect your current tracking automatically.
Install the Inspector SDK to observe a living summary of current tracking across platforms. Inspector doesn’t gather any user data, only event shapes and volumes.

2.Analyze tracking issues instantly
Inspector dashboard highlights your current event tracking issues, so different stakeholders can discuss and prioritize what to fix.

3.Prioritize what matters
The inspector dashboard gives you and your team the overview you need, to prioritize the tracking changes that will have the biggest impact on cleaning up mission-critical metrics so you can make progress quickly.

4.Clean, step-by-step
Use your complete overview of what needs to be fixed across platforms, to fix top priority issues with clear event and property definitions, implemented with type safe analytics.

5.Future proof
Great product analytics help teams make the best decisions to grow their business. Truly useful metrics for today and beyond are transparent — where everyone knows which events can help answer their questions — and reliable, consistent data, easy to evolve and implement as the product grows.

If you’re curious about the infrastructure and behind the scenes (as you should be!), learn more about Inspector, reach out or subscribe to our newsletter.

Avo is scaling with the help of world-class developer and data tool investors

To build on our momentum, we’ve raised $3M from GGV Capital with participation from Heavybit, Y Combinator and others, to make Avo a game changer for democratizing analytics.

I’d like to use this opportunity to thank all the incredible people who have believed in our team and our mission, and supported us throughout this journey. A special shoutout to Hjalli and Investa, Gustaf, Jared, Aaron, Kevin, Kat, Michael and all the YC folks, Joe, Tom, Dana, Jesse and James at Heavybit, Glenn, Oren, Tai and the entire crew at GGV, the Brunnur team, Jenny and co at Crowberry, Pete at Optimizely, Coby at Radar, Sandy, Ari and more. In addition to our investors, we’re surrounded with smart and generous people who have hosted us on their couches in San Francisco, helped us hire, advised us on Avo, introduced us to great people, et cetera; thank you to Spencer, June, Gunni, Jói, Aliya, Drew, Kiddi, Siggi, Hilmar, Arndís, Andrés, Kjartan, Paul, Gummi, Vala, Austin, Brian & Michael, Leslie, Shuo, Alex, Ron and so many more.

Sölvi and I are proud to have been joined by an outstanding team of exceptionally kind, talented, and driven humans on this mission, who we are honored to be working with every day.

Our focus in the coming months will be helping more organizations uplevel their analytics governance fast, so they can join the global shift to self-serve analytics culture. We will also continue to focus on developer experience and seamless collaboration between product managers, developers and data scientists – because we don’t want teams to have to choose between product delivery speed and reliable analytics anymore.

‍

P.S. We're hiring! Come work with us in our remote-first culture (since way before COVID 😅) and diverse and inclusive team 💛