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.
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.
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"
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.
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
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.
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.
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.
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.
* 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.