Design tracking with Event Studio

• Cloud: available
• Private Managed Cloud: available
• Self-Hosted: not available
• Add-on: available

Event Studio is a set of tools for designing and implementing behavioral data event tracking. The Event Studio UI is included in Snowplow Console. Event Studio provides:

• Schema management: define and version data structures for events and entities
• Tracking plans: document your tracking implementation, assign ownership, and establish data contracts with tracking plans and event specifications. See Introduction to tracking plans
• Observability: monitor data quality and tracking implementation
• Code generation: automatically generate tracking code from your designs, using Snowtype

Start with best practice

New to tracking design? Start with the best practice guide to learn how to approach designing your tracking implementation.

How the pieces fit together

Event Studio connects source applications, tracking plans, event specifications, and data structures. This diagram shows how they relate:

flowchart LR SA[Source application] --> AID[App IDs] SA --> AE[Application entities] TP[Tracking plan] -->|references| SA TP -->|contains| ES[Event specification] ES -.->|inherits| AID ES -.->|inherits| AE ES -->|one version of| EDS[Event data structure] ES -->|versions and cardinality of| NDS[Entity data structures] ES --> PIT[Property instructions and triggers] subgraph lifecycle [Data structure lifecycle] DS[Data structure] -->|deployed to| DEV[Development registry] DEV -->|promoted to| PROD[Production registry] end EDS -.->|is a| DS NDS -.->|is a| DS

The same relationships, as a list:

1. A source application lists the application IDs it sends, and the application entities expected with every event it tracks.
2. A tracking plan references one or more source applications, and contains event specifications. Each event specification belongs to a single tracking plan.
3. Each event specification inherits the app IDs and application entity data structures of the tracking plan's source applications.
4. Each event specification uses one version of an event data structure, and optionally versions of entity data structures, with how many of each entity to expect.
5. Each event specification adds instructions for how to populate each property, and triggers that describe when the event occurs.
6. A data structure starts as a draft. You deploy it to your development environment for testing, then promote it to your production environment. By default, each pipeline has a development and a production Iglu Server instance.

A data structure describes the structure of the data, and validates the values of the properties in your events and entities. An event specification is a narrower definition: it also defines the right values for fields when the event is triggered, and the entities to attach. For example, an add_to_cart data structure permits currency to be either "USD" or "EUR". An event specification can narrow currency to "USD", so event specification validation flags an event that declares the specification with currency = "EUR", even though the data structure accepts it.

Example

This diagram shows how a tracking plan, its event specifications, and data structures relate:

This example Ecommerce Checkout Flow tracking plan groups two event specifications for ecommerce checkout behavior:

• Checkout Started describes a checkout_started event, with an associated cart entity
• Product Add To Cart describes an add_to_cart event, with cart and product entities

The individual event and entity data structures can also be used in other event specifications and tracking plans.

Work through the design workflow

Design tracking in the order the objects depend on each other. An event specification references data structures and source applications, so create those first:

1. Find existing events in the Event Catalog, to see whether a team has already defined a similar event.
2. Plan your source applications, then create them.
3. Create the data structures for your events and entities.
4. Create a tracking plan, or start from a template.
5. Define event specifications in the tracking plan.
6. Hand off the tracking plan to developers.
7. Test, promote, and publish your data structures and event specifications.
8. Monitor tracking plan data quality.
9. Evolve your tracking design as your data structures change.
10. Manage your tracking design as code with the Snowplow CLI or the Console API.

You can also work through any of these steps with an AI assistant connected to the Snowplow MCP server.

Event specifications also drive data modeling: they enable automatically generated dbt models that transform atomic events into analysis-ready tables. The models follow the structure defined in your specifications, creating consistent table schemas and joining related entities. When you update specifications, you can regenerate the corresponding data models, keeping your warehouse transformations in sync with your tracking design.

Related concepts

Event Studio builds on these concepts:

• Events: actions that occur in your systems
• Entities: the objects associated with events, such as a user or a product
• Schemas: the structure that events and entities are validated against, called data structures in Console
• Tracking plans: logical groupings of related business events with defined ownership
• Tracking design best practice: how to approach designing your tracking implementation