We’re bringing more precision to your schema design and validation and new ways to reduce the scope of tracking changes. 

The power of Avo lies in having a single source of truth for all your event schemas—across platforms, products, and even subsidiaries in large organizations. Because the only way to scale data quality across large organizations with complex product offerings is to be consistent, and the only way to be consistent is with visibility.  We went deep on this problem in our recent post on Why data governance at scale is so broken (and how we're fixing it).  

But even while there are fundamental data structures that need to be consistent across multiple teams and platforms, the challenge arises when domain-specific teams need to add their nuances to a data structure that should otherwise be consistent across the organization. Specifically:

Large organizations are forced to choose between these two bad scenarios: 

1. Event schemas blow up with “optional” properties that can’t be set as “required” because they are only meant to be sent in very specific scenarios (classic example: “return_destination” should be required if and only if “trip_type” == “round_trip”). 
   ‍Impact: No way to validate whether these scenario-specific properties are present in the right places. Additionally, those scenario specific “optional” properties add confusion for everyone else who don’t know when that property is supposed to be present.
2. Domain teams create duplicate versions of the events (e.g. append something domain specific to the event name) in order to be able to require properties for their specific use case. 
   ‍Impact: Inconsistent data causing confusion for cross-domain data consumers.

To this end, we’re introducing features to support domain-specific data design and validation at scale.

Event variants: The devil’s in the details

Yesterday we introduced Domains as stakeholders of events. Today, we introduce Event Variants so domains can own their own version of a company-wide event, with their little spin on it. 

Event Variants allow you to add scenario-specific required properties, descriptions and screenshots, as well as customize the set of allowed property values even if the property is used across multiple other events (such as a general property like “item_type”).

Example: Let’s look at “add_to_cart”, a widely used event across multiple domains at a food delivery company. For example both the Checkout team and the Search team rely on this event. It’s probably best for the checkout team to own the “add_to_cart” event with the org-wide required properties, including the property “cart_product_origin”. 

The Checkout team might also have a variant when the “add_to_cart” event is sent from the Wishlist page, where they’ve pinned the “cart_product_origin” property value to “wishlist” and added required property only relevant for that context: “wishlist_item_count”.

Then  the Search team would own a variant for when the “add_to_cart” event is sent from the Search Result page, where they’ve pinned the “cart_product_origin” property value to “search_result_page” and added a property that’s required only for this context: “search term”.

Want to try Event Variants? Learn how ->

Event-specific property constraints

With event-specific property constraints you’re able to tweak any property on your domain-specific events without needing buy-in from everyone using that property on other events. 

Example: Imagine you're on the Stories team for a social media app, adding a feature to comment on stories. With this, you need to update tracking for the "Comment Added" event by allowing "Story" as a value for the "Item Type" property.

Previously, you'd have to update this value across all events and platforms where "Item Type" is used. Now, you can simply specify "Story" as a value for "Item Type" only for the "Comment Added" event, and even restrict it to certain platforms (e.g., mobile but not web).

Want to try Event-specific property constraints? Learn how ->

Implementation and validation are more efficient with Event Variants and event-specific property constraints

With the arrival of Event Variants, along with the release of Domains, implementation and validation just got a lot easier and more reliable. 

Developers and data designers will no longer need lengthy conversations and dragged out QA processes to clearly define and validate which properties are required for a specific scenario, and what constraints should apply. With Event Variants, domain teams will have computational validation for their own special cases of widely used events. Event Variants and event-specific property constraints provide a layer of granularity that makes it clear and unambiguous what the tracking call is meant to capture.

Try out domain-specific data design and shape what’s next

Domain-specific data design makes sure your schema changes have a narrow, targeted impact on organization-wide schema. This is powerful for several reasons. It speeds up the data planning process, because more targeted schema changes mean less impact on other domains, which means fewer people who need to review as much. It also allows developers to move faster with implementation, because more granular schemas mean more granular implementation instructions and streamlined validation.

With Event Variants and event-specific property constraints, we’re bringing powerful new ways for domain owners to take charge of their data and build greater precision into the tracking plan. 

We can’t wait for you to try these new solutions and share how you’ll be taking your event data design to the next level. 

Want to try domain-specific data design in your workspace? Learn about Event Variants -> and event-specific property constraints ->

New to Avo and want to learn more? Book a demo ->