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.
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:
The result of the purpose meeting is usually a draft of events that someone takes forward to the next step.
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
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:
Example: Event definition
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:
Example: Adding collaborators and asking for review
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
At this point we recommend to have automatic tracking plan publishing enabled. Learn how to do it here.
When you’ve reached consensus about the changes it’s time to start implementing. The typical implementation workflow looks like this:
Example: Implementation instructions and code snippet
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:
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.
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.