Avo Workflow

Day to day for onboarded customers

It’s time to start working on a new feature or improvement for your team and of course you want to measure the success of the change. In this guide you will find the recommended workflow from beginning to end for teams that have adopted Avo and are ready to use the tool in their routine feature work.

The steps described here are usually performed by different people with different roles within teams – all depending on the structure of your company and the responsibilities of the roles. Within each step we list what role typically leads it, but of course it can be different.

Step 1 – Decide what to track

Role: product (this initiative is usually led by a product oriented person)

This is usually the hardest part, deciding on what events and properties you need to measure the success of the change you are about to make. There are many paths you can take to lead you to a decision, but no matter which one you take, we recommend doing it as early as possible.

We always recommend starting with formulating the metrics that you hope to move with your change. Our favorite way to do that is what we like to call a “Purpose Meeting”. The outcomes of that meeting are:

Learn what's the “Purpose Meeting”.

1. Goals – what does success look like?
2. Metrics – how will we measure how successful we are?
3. Data – what analytics events do we need for our success metrics?

The result of the purpose meeting is usually a draft of events that someone takes forward to the next step.

Step 2 – Open a branch in Avo

Role: product (usually the same person as performed step 1)

The first thing you do in Avo, for a new feature or iteration, is to open up a new branch. That allows you to draft changes to the tracking plan in isolation from the source of truth that lives on the main branch.

Example: Opening a branch

Step 3 – Define events and properties

Role: product (usually the same person as performed step 1 and 2)

The results of the purpose meeting can all be documented in Avo in context with your event definitions. Check out our guide on using Categories and Metrics to document Purpose Meetings in Avo to learn more.

Example: Purpose meeting outcome

Example: Metric definition

Once you have an idea of what to track, you can start defining the event structures on your branch in Avo.

There are a few things to keep in mind when doing so:

• Check if there are any existing events that you can use or expand with additional properties
• Check if there are any existing properties that you can use instead of defining new ones. The property library will help you find what you are looking for.
• Make sure to follow the naming convention used in your workspace. Our issue reporter and naming assistant will help you do so.
• Make sure to add descriptions to your events and properties to avoid any misunderstanding between those who design, implement and consume the data
• Try to use constraints on your properties if possible. This is especially useful when you have a string property that has a finite number of possible values.

Example: Event definition

Step 4 – Ask for review

Role: product (usually the same person as performed step 1, 2 and 3)

Once you have drafted changes to your tracking plan we recommend asking some of your teammates to review your suggested changes.

A great way to do that is going to the review screen of your branch and adding them as collaborators. A collaborator will receive an email when added to your branch, when discussions are started and when the branch is closed.

We typically see a few types of reviewers added as collaborators to a branch:

• Someone from the data team that can validate that the changes made are according the the data standard of your company
• Someone from another team that is responsible for the feature or user flow (if that is another team) that this event is a part of can review for completeness and accuracy of data coverage.
• If the changes made affect multiple sources, then it can be a good idea to get a thumbs up from someone from each of the platforms the sources represent

Example: Adding collaborators and asking for review

Step 5 – Review and approve

Roles: data, product and/or development (one or more of the reviewers described in step 4)

The role of the reviewer(s) is to make sure that the suggested changes are according to the existing standards and naming conventions. The review screen in Avo summarizes the changes that have been made and is good for a general overview. You can use the commenting functionality in the review screen to discuss the overall branch and give thumbs up for approval.

Example: Giving approval on a branch

For a deeper understanding of the changes, we recommend going into individual events and take a look at the structure and see how it will look if they will be implemented in that way. You can use the commenting functionality of each event and property to discuss them specifically.

Example: Discussions on a property

What's next?

At this point we recommend to have automatic tracking plan publishing enabled. Learn how to do it here.

Step 6 – Implement

Role: developer(s)

When you’ve reached consensus about the changes it’s time to start implementing.The typical implementation workflow looks like this:

1. Open a git branch – if you have multiple development platforms (sources in Avo), we recommend having one git branch per source for each Avo branch.
2. Use the Avo CLI to pull the updated code from the branch
3. Use the Avo functions provided in the generated code to implement your events in your source code. The implement tab in your workspace provides detailed instructions and code snippets)

Example: Implementation instructions and code snippet

Step 7 – Verify

Roles: developers and QA

Avo provides a number of tools that help you verify that the events you’ve implemented are correct according to the definition made in Avo:

• Avo status command in the CLI that will report on where the analytics functions provided by Avo are being called, and which events have not been implemented yet.
• Data validation logs and warnings that warn you whenever a mistake is made during implementation
• Implementation status checkmark that shows you whether the event has been seen in development on your branch
• Avo debuggers that give extended feedback when triggering the events from your mobile or web application
• Avo Inspector that analyses the data coming in from development, staging and production and surfaces issues in the data

Step 8 – Merge

Role: developers and/or Avo admins

When you have finished the implementation and verified it’s correctness you are ready to merge your Avo feature branch.

However, we recommend merging the git branch first and then the Avo branch. The reason for that is that a git branches often

That is because if an Avo branch is merged first and the git branch lives for an extended period of time after the Avo branch was merged, conflicts can arise. The conflicts happen when other people create new Avo branches after the Avo branch has been merged to Avo main, while the git branch is still open so the code changes have not reached git main.

Note: At this point avo.json on your git main branch is pointing to an Avo branch that has already been merged, which is perfectly fine! The Avo CLI will take care of automatically updating avo.json on next avo pull.