• About
  • Plans
  • Docs
  • Blog
  • Jobs
  • Login
  • Get started
  • About
  • Plans
  • Docs
  • Blog
  • Jobs
  • Login
  • Get started

Tracking Plan

Table of Contents

The tracking plan tab consists of all your event, property and metric definitions.

  1. Events
  2. Properties
  3. Metrics

1. Events

An event represents something that a user does or that happens to them. For example "Signup Attempted" is an action that the user did, while "Credit Card Validated" is something that happened to the user.

Event Definition

An event is defined in the Events section of the Tracking plan and can be organized into categories. The definition of an event includes:

  • A descriptive Event Name
  • A Description including the timing of when the event should be sent as well as other useful implementation details
  • The Source(s) that the event should be sent from
  • The Actions(s) associated with the event
  • The Metrics(s) related to the event
  • The category(s) that the event is a part of


Actions is an umbrella term over all the tracking methods the analytics platforms offer. In Avo you can define your actions in the Actions part of the tracking plan and organize them into categories. Actions can be triggered on their own or together, for example it's common to trigger any of the actions along with logging an event.

Below is a list of possible actions and supported platforms, in the order of which they are triggered:

  1. Identify User: Amplitude, Segment, Mixpanel and Fullstory
  2. Update User Properties: Amplitude, Segment, Mixpanel and Fullstory
  3. Log Event All supported analytics platforms
  4. Log Revenue: Amplitude, Segment and Mixpanel
  5. Log Page View: Segment
  6. Undentify User: Amplitude, Segment, Mixpanel and Fullstory

Log Event

Logging an event is the fundamental action for behavioral analytics. An event describes an action that a user does in your application or something that happens for them. Additional information about the action, Event properties, can be logged with the event.

Avo wraps your the SDKs of your current analytics tools so you get one function for each event. By doing so, Avo makes your analytics as type-safe as possible, and takes care of sending the event to all your analytics tools.

Here's how sending and event called "Signup Completed" would look like:

Avo.signupStarted({authenticationMethod: 'Facebook', email: 'hi@avo.sh'})

And here is a list of methods that are wrapped in each analytics tool when Avo.signupStarted is called:


logEvent('Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})


trackEvent('Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})

Facebook Analytics

fbq('trackCustom', 'Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})

Firebase Analytics

logEvent('Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})


event('Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})


Intercom('trackEvent', 'Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})


track('Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})


track('Signup Completed', {'Authentication Method': 'Facebook', 'Email': 'hi@avo.sh'})

Identify User

The Identify User action should be used when you want to identify users from your system in your analytics platform. This would typically be on done when users either Sign up or Login or in other ways users are becoming authenticated users according your system.

The Identify User action can be triggered individually or along with logging an event. It's common to trigger the Identify User action along with log Signup Completed and a Login Completed events - in such cases, the Identify user call will occur first and then the log event call. When the Identify User action is selected, Avo will require a user property called User Id. Below is a list of Identify User methods used for each supported analytics platform:

Unidentify User

The Unidentify User action should be used when you want to unidentify users from your system in your analytics platform. This would typically be done when users Log Out, but not limited to that.

If you forget to unidentify users in your analytics platform you could potentially track two or more users as the same user in your analytics platform if they share a computer.

Below is a list of Undentify User methods used for each supported analytics platform:

Update User Properties

The Update User Properties action is used when the state of the user in your analytics platform should be updated. User properties are often updated at the same time as logging an event but they can also be updated independently.

User properties are updated with the following methods according to analytics platform:

  • Amplitude: setUserProperties
  • Appsflyer: user properties not suppported
  • Facebook Analytics: fbq('setUserProperties')
  • Firebase Analytics: setUserProperty
  • Fullstory: setUserVars
  • Intercom: Intercom('update', userProperties)
  • Mixpanel: people.set
  • Segment: identify

Log Revenue

Amplitude, Segment and Mixpanelsupport tracking revenue specifically. It's recommended to add the Log Revenue action with events that represent a successful purchase, such as `Purchase Completed`

Below are details for what Avo automatically does for each analytics platform.


For the Amplitude destination, Avo will add 4 event properties that match the Amplitude logRevenue API with the prefix "Amplitude: ".

  • Amplitude: Product Id
  • Amplitude: Quantity
  • Amplitude: Price
  • Amplitude: Revenue Type

Call logRevenueV2 with these properties as well as all other event properties, and then call logEvent.


For the Segment destionation, Avo will add 2 event properties that match the Segment revenue properties with the prefix "Segment: ".

  • Segment: Revenue
  • Segment: Currency

Segment currency will have constraint that the currencies need to be in a valid ISO format. For compiled languages this will generate an enum to guarantee that the currency is a valid ISO format, for Javascript this will be validated during runtime.

Enums are currently not supported on Android and iOS.

Call track with the Segment revenue properties set in the correct keys to make sure that Segment recognises the event as a Revenue event.


For the Mixpanel destination, Avo will add 1 event property that matches the Mixpanel track_charge API with the prefix "Mixpanel: ".

  • Mixpanel: Amount

Call people.track_charge with the price and all additional event properties and then call track

Log Page View

Adding the Log Page View action will trigger page tracking on web and screen tracking on mobile. Log Page View is only available in Segment, other supported platforms do not offer page tracking at the moment.

When Log Page View is set on events, Avo will do the following for each platform


For the Segment platform, Avo will add 1 property that matches the Segment page property with the prefix "Segment: ".

  • Segment: Page Name

Call either page or screen (depending on your apps platform) with the Page Name property and then call track. If you want to only log a page view, not an event, you can remove the Log Event action from the event.

2. Properties

Properties are also known as traits, attributes, metadata, etc. They are information that is attached to events, that describe the state of the user or the product at the time of the event. Avo allows you to define event, user and system properties - each category described below.

Event properties

Event properties describe the current state of your product at the time of the event.


For example the property "Game Mode" on the event "Game Started", is relevant for that specific event, when you analyse your data. You might be want to correlate the completion rate of the game with the Game Mode, to decide how valuable the Game Modes are.


Event properties are sent with the event in the event call.

User Properties

User properties to describe the state of your user. It is information that is usually relevant in a larger scope than for exactly that event.


For example, you might want to correlate the Total Games Played of your users with how likely they are to recommend your product to their friend, to make sure you ask them to do that at the right time.

Some User Properties change rarely, such as "Email", which mostly changes on Signup. And many analytics platforms support you in analysing all of your data by your user properties, while only sending them along with your events when they actually change.


User properties are updated with the Update User Properties action.

System properties

System properties represent information that's relevant for all events that you send, and yet do not describe the state of the user.


For example, the user could alter between mobile and web platforms, so you would not necessarily have "Platform" be a user property that gets overwritten each time the user switches platforms. Instead you could set "Platform" to be a System Property in Avo, which are properties that we send along with all events, as event properties for you. The values for such a property could be "Web App", "Desktop App", "iOS App", "Android App", etc.


System properties are set in the Avo.initAvo() function. They can be updated with Avo.setSystemProperties() if needed, but otherwise the values persist during the lifecycle of the application.

Property groups

Property groups are a way to group two or more related properties to quickly and consistently add them to all related events.

An e-commerce website might want to attach all product properties to cart and checkout events. An example property group could be "Product" containing the following properties:

  • Product ID
  • Product Name
  • Product Price
  • Product Quantity

Property types and constraints

In the property modal for event, user and system properties you need to define the type of the values allowed for the property. That definition is used to validate the property.

Avo supports properties with values of the following types and constraints:

  • string (enumeration of allowed values)
  • integer (minimum and maximum value)
  • float (minimum and maximum value)
  • boolean (true or false)

Properties values can also be a list of the above mentioned types:

  • [‘foo’, ‘bar’’]
  • [1, 2, 3, 4, 5]
  • [1.2, 1.3, 1.6]
  • [true, false, true, true, false]

Properties can be marked as optional. That means that Avo will not give you an error if that property is missing from an event that the property is attached to.

3. Metrics

Metrics are used to measure the success of a feature. Usually more than one metrics are necessary to be able to evaluate the success of a feature. Example metrics for a feature that is meant to improve signup experience are: Conversion to complete email step of the signup funnel Conversion to complete signup Proportion of daily active users that are signed up

Events are tied to metrics and can be thought as the building blocks of the metrics - the events necessary to be able to visualize the metric in your analytics tool. The metrics are therefore not only visible in the Metrics tab, but also in the event view. That way everyone can easily understand why this particular event should be track - because it is associated with a metric which is a part of a goal.

Read more about how to organize metrics and events.