Your passion for better data is what drives us. And based on your valuable feedback, we’re announcing better ways to govern your data and bring even more precision to your data design. 

Introducing Event Variants: a powerful way to create variations of existing events to suit specific scenarios. We briefly touched on Event Variants in our last update, but this time let’s take a closer look at how you can use Event Variants to add a layer of granularity to your tracking plan and bring clarity to your developers when it comes to implementation. 

Today, we’ll cover:

➡️ What Event Variants are, and why they’re useful

➡️ How to pin properties to variants

➡️ Adding images to show when a variant should be triggered

➡️ Making variants source specific

🧪 Beta previews: Set advanced event naming rules and define allowed property values at the event level.

Event Variants: An airline example  ✈️

Imagine you’re managing data governance at a major airline. You have an event “Flight Booked”, but you want to get more precise when it comes to variations of that event, let’s say for roundtrip and one-way flights. 

With Variants for “Roundtrip” and “One-way” bookings, you can add specific rules and conditions to the event to describe these scenarios.

1. Use Variants to only require properties where relevant

When creating the event, you add the typical properties you’d want to see included in all scenarios in the base event, such as name, ticket number, and so on. For your different flight booking types, you’ll also need variant-specific properties. So for roundtrip flights, you may want to specify “Inbound Flight Number” and “Inbound Departure Time” properties which are only required for roundtrip bookings. With Event Variants, you’ll now have this crucial information clearly documented without needing to set up a separate event for each booking type. 

2. Specify booking type with a pinned property value

Let’s say you’ve added “Booking Type” as a property on the base event. You can bring more clarity here by pinning the property value “One-Way” or “RoundTrip” to either variants, to ensure events for one way bookings always have “Booking Type” set as “One Way Booking Type”, and vice versa. Pinning properties in this way will make implementation easier, since developers will get clearer instructions on how the event should be sent for each scenario. If you're using Codegen, developers won't even have to think about the pinned property value—it's automatically sent to all your destinations when the Event Variant is triggered.

3. Show where the flight booking originates with Event Triggers 

When collaborating on data design, it’s a good idea to make it crystal clear where an event should be triggered. Now, we can add triggers to each variant with screenshots, to make it clear when each variant should be triggered. 

It’s as simple as taking a screenshot and uploading it under “Event Trigger” to paint a picture of where the event should trigger. In this example, we can add a screenshot of the different types of flights being booked to precisely describe where and when our variants should be sent. 

4. Toggle sources for each variant

There may be occasions when you want to create an Event Variant, but it’s not relevant for all your sources. It’s easy to toggle which sources your variant should apply to. In our Airline scenario, let’s imagine the iOS team is still working on their flight booking experience for one way flights. In a couple of clicks, we can easily toggle the “One Way” variant off for iOS, and turn it back on again later when they’re ready to roll out the feature.

Stay tuned for more Event Variant updates (coming soon)

With these upgrades to Event Variants, we’ve made significant steps towards a more granular tracking plan that works for domain owners and global governance leaders alike. To sum up, our latest Event Variant updates include:

• Descriptions
• Event triggers
• Source selection
• Property presence
• Pinned property values
• Variant specific Code Changes and Codegen functions
• Variant details included in Publishing integrations

Join the Beta: Advanced event naming rules and define allowed property values at the event level 

Still reading? Awesome, because we wanted to use this opportunity to let you know about two new beta features we are very excited about.

Advanced event naming rules

Creating perfectly named events is about to get a lot easier, for anyone on your team! Set advanced rules to ensure workspace editors structure their events correctly (like object before action), use approved words (for example for describing generic user actions), and nail the casing every time, even with complex casing conventions. 

Curious? Dive into our docs or reach out to us (at the email provided below) to request access!

Define allowed property values at the event level

We heard you loud and clear, you’d like to be able to define allowed property values at the event level, and that’s exactly what our latest beta release enables you to do.

We’ll be rolling out a private beta over the next few weeks—reach out to us (email below) if you’re interested in taking it for a spin in your workspace!

That’s it for now, but we’ll continue to roll out more functionality to Event Variants and to other Avo features, so if there’s something you’d love to see included, let us know!

As a reminder, you can reach us at support@avo.app with ideas, questions, feedback, or to get access to these latest beta features. Otherwise we wish you good luck, and have fun on your journey to better data.