Avo tracking plan audit rules

Learn how to read, fix and configure your tracking plan audit

Audit rules

Following are the static rules Avo tests for in the tracking plan audit. To learn more about how to get started with the tracking plan audit, see Quickstart: Get your first audit.

You will recognize the Tracking Plan Audit by the yellow exclamation point next to the Tracking Plan item in the sidebar. It’s meant to help teams follow their naming convention and surface issues like when a type is missing from a property.

Below is an overview of the reported issues and how you can resolve them.

Avo tracking plan audit UI

Event Rules

All events have unique names

Checks if any two event names in the tracking plan conflict with each other. For event name to be unique, no other event can have the same name, independent from their case. Example of conflicting event names:

"App Opened", "app opened", "app_opened", "app-opened"
"Add to Cart", "Add to cart", "add_to_cart", "add-to-cart"
"Checkout Started", "checkout started", "checkout-started"
"Checkout Completed", "checkout completed", "checkout-completed"

How to resolve

Pick the casing that matches the one that is dominant one in your workspace and fix the implementation of those that don't fit your standards. Note that changing your existing tracking might cause issues in downstream tools and metrics. Make sure to discuss with the consumers of the data before making such change.

💡

Best practice: Have all event names unique to avoid confusion and conflicts in downstream tools, such as in data warehouses and dashboards.

Casing of event names is consistent

Checks if the casing of event names in the tracking plan is consistent. For event name to be consistent, it should be the same casing across all events. Example of inconsistent event names:

"App Opened", "checkoutStarted", "checkout_completed"
"Add to Cart", "addToCart", "add-to-cart"

💡

Best practice: Have all event names defined with consistent casing to increases the usability of the data. If the casing is not consistent the person using the data would not only need to know the event name they are looking for, but also the casing of the event name.

How to resolve

Fix the names and implementation of the events that don't fit your standards. Note that this will only be fixed for the data going forward, not historical data. Note that changing your existing tracking might cause issues in downstream tools and metrics. Make sure to discuss with the consumers of the data before making such change.

All events have description

Checks if all events in the tracking plan have a description.

💡

Best practice: A well defined event description contains information such as when the event should be sent and why it's being tracked.

Property Rules

No conflicting properties

Checks if there are more than one definition of a property with the same name. This is the case where two properties have the same name, but different type definitions or descriptions. Example of conflicting properties:

"User Id", type: string
"User Id", type: int

How to resolve

Aligning the descriptions, types and property constraints of the conflicting properties and fix the implementation of those that don't fit your standards

All property names are unique*

Checks if any two property names in the tracking plan conflict with each other. For property name to be unique, no other property can have the same name, independent from their case. Example of conflicting property names:

"User ID", "User Id", "user_id", "user-id"
"email_adddress", "Email Address", "email_address", "Email-address"

How to resolve

💡

Best practice: Have all property names unique to avoid confusion and conflicts in downstream tools, such as in data warehouses and dashboards.

Casing of property names is consistent

Checks if the casing of property names in the tracking plan is consistent. For property name to be consistent, it should be the same casing across all properties. Example of inconsistent property names:

"User Id", "userId", "USER_ID"
"Product Name", "product_name", "product-name"

How to resolve

Fix the names and implementation of the properties that don't fit your standards. Note that this will only be fixed for the data going forward, not historical data. Note that changing your existing tracking might cause issues in downstream tools and metrics. Make sure to discuss with the consumers of the data before making such change.

💡

Best practice: Have all property names defined with consistent casing to increases the usability of the data. If the casing is not consistent the person using the data would not only need to know the property name they are looking for, but also the casing of the property name.

All properties have defined types

Checks if all properties in the tracking plan have a defined type. Every property should at least have their base type defined, one of: string, int, float, boolean or object. In Avo you can in addition to the base types define a list of possible values for string properties, and min and max values for numeric properties.

How to resolve

Assign the intended type for the property and make sure that the tracking implementation matches the assigned type.

💡

Best practice: Have well defined types for all properties to increase the quality of the tracking implementation. Having well define types is the prerequisite for having your tracking consistent across all products and platforms.

All properties have description

Checks if all properties in the tracking plan have a description.

How to resolve

Add descriptions to all properties to increase the quality of your tracking plan.

💡

Best practice: A well defined property description contains detailed description of what the property is describing, and how it's value should be fetched.

* These rules can only fail after importing an existing tracking plan to Avo. When editing your Tracking Plan in Avo, Avo prevents you from introducing conflicting events and properties.

Audit Rule Configuration

For new workspaces all rules are enabled in their default settings. Workspaces on the Team and Enterprise plans have the Tracking Plan Audit Config enabled which allows members that are Editors or Admins to change the audit behavior. All rules can be toggled on or off and the preferred casing can be configured separately for events and properties. Additionally workspaces on the Enterprise plan have the ability to force the preferred casing when events names are set, blocking the creation and editing of events and/or properties with invalid casing.

Tracking Plan Audit Configuration

Branch audits What is a tracking plan?