Advanced event naming rules

To ensure anyone on your team is able to create events that match your naming convention, you can define advanced event naming rules. The advanced rules setting lets you break down your events into its components and define and enforce rules for each component.

Naming conventions typically have four aspects:

• Casing: snake_case, camelCase, Title Case, etc
• Format: the order of the event name component, most commonly an order and an action, but some teams include further context
• Tense: the tense of the action
• List of allowed words: For example we use game and not match and completed and not ended.

Advanced naming rules in Avo will help teams configure rules to guide workspace editors making new or updated event names to…

• adhere to the correct event name structure (e.g object action)
• ensure they use allowed values for certain components of the event
• prevent them from making casing mistakes, even with complex casing conventions.

To define advanced event name rules, click the tracking plan audit icon next to the Tracking Plan item in the sidebar and then click “configure”. This will open up a view to configure your tracking plan audit. Under “Event naming conventions”, click “set advanced rules”.

Event name components

Event name components refer to the different parts that make up an event name. When defining your event naming convention, you add each of these components in order and define the rules that apply to each of them.

When adding a component you have three options:

• Free input
• Allowed values
• Separators

Free input

An event name field where any string value is accepted, with the only constraint being that it adheres to the correct casing.

The casing rule for the free input will serve to prevent users from typing values that don’t match the correct casing when creating new events.

Example: A common example of this is an object component – where the object value could represent any feature, flow or ui element the user interacts with.

Allowed values

An event name field where only values from a predefined list of allowed values are accepted.

The allowed values can be added or removed on the advanced rules configuration screen, accessible from the tracking plan audit, or added directly from the event creation modal when creating new events.

When adding allowed values, the casing rule for the component will prevent users from typing values that don’t match this casing.

When adding allowed values, the casing rule for the component will prevent users from typing values that don’t match this casing. If you need to bypass casing rules for your allowed values, you can set the component casing to “custom” to permit values that deviate from your casing.

Example: A common example of this is an action component – where there is an established terminology for user actions in your product (such as “clicked”, “opened” or “viewed” and you want to prevent duplicate events being created for the same action (such as “banner_viewed” and (“banner_seen”)

Separators

One or more characters that separate the event name fields. Separators are usually between other event name components, but can also be added before the first event name component or after the last. This is useful for teams that use a hybrid naming convention where the separator between name fields is different from those within

Example: If your naming convention is object_action, the _ (underscore) is a separator.

Guardrails for advanced event name rules

Guardrails guide users to correctly name events when a workspace has advanced name rules in place:

The name input is broken down into its components and each name field is labeled to help users adhere to the correct name structure.

• When typing values into free input fields, they will automatically be written in the correct casing
• For allowed value fields, users can select an allowed value
• Separators are already in place and do not need to be typed manually