Avo tracking plan audit rules

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

Audit rules

Following are the rules Avo tests for in the tracking plan and branch audits. 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.

💡

To enforce more granular event name rules in your workspace, including event name structure (such as “object action”) or hybrid casing conventions, you can set up [advanced event naming rules](/audit/advanced-event-naming-rules

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 by default, and casing rules default to the most common casing seen in the workspace. Workspaces on the Team and Enterprise plans are able to configure the audit to include or exclude each rule and manually set their casing rules for events and properties.

Additionally, workspaces on the Enterprise plan are able to define advanced event naming rules that include event name structure (such as “object action”) and hybrid casing conventions.

To configure your audit – click the yellow exclamation point next to the Tracking Plan item in the sidebar and then click “configure”

Enforcement

Workspaces on the Enterprise plan are able to enforce each audit rule to ensure no new issues are introduced to your tracking plan. Depending on your team’s preferred workflow, you can set the enforcement to two different stages of the branch lifecycle:

Request for review: Requires the branch to pass all enforced audit rules before being reviewed
Branch merge: Requires the branch to pass all enforced audit rules before it is merged to the main branch.

💡

Marking the branch status as Request for review will also block the branch from being merged if any changes where made after approval

Tracking Plan Audit Configuration

Branch audits Advanced event naming rules