For AI agents: a Markdown version of this page is at https://docs.snowplow.io/docs/event-studio/tracking-plans.md. The index of all documentation pages is at https://docs.snowplow.io/llms.txt, and the index for this section is at https://docs.snowplow.io/docs/cdi/llms.txt.
Tracking plan and event specification elements
A tracking plan is a logical grouping of the data you collect as an organization by domain, with an explicit owner. See Introduction to tracking plans for how tracking plans support ownership and governance.
Each tracking plan contains event specifications that define the events you want to track. By grouping related event specifications in tracking plans, you organize your data collection by domain, with clear ownership and implementation instructions for each event specification. Event specifications act as data contracts between teams: they define what data your applications should send, what your data warehouse will receive, and what your downstream consumers can rely on.
Tracking plan elements
A tracking plan has these elements:
| Element | Description |
|---|---|
| Name | A descriptive name for the tracking plan. The name must be unique |
| Description | A description of the data that the tracking plan captures |
| Owner | The individual responsible for the tracking plan |
| Domain | The team or business domain that owns the tracking plan |
| Source applications | The source applications the tracking plan is implemented in |
| Event specifications | The events that the tracking plan describes. See Event specification elements |
A tracking plan also shows event volume metrics for its event specifications, which help you monitor data collection over time. See Monitor tracking plan data quality in Console.
Event specification elements
An event specification has these elements:
| Element | Description |
|---|---|
| Name | A descriptive name for the event |
| Description | A description to help people understand what action the event is capturing |
| Source applications | The source applications inherited from the tracking plan. The event specification inherits their application IDs, which are sent with this event, and references their application entity data structures, which are expected with each event |
| Triggers | Instructions on where and when the event gets triggered, for example when a user clicks the "Add to basket" button |
| Event data structure | One version of the event data structure that this event validates against as your pipeline processes it. It can be a standard data structure, provided by the Snowplow tracker by default, or a custom one, provided by your organization |
| Entity data structures | The versions of the entity data structures to attach to this event, for example user or product, and how many of each entity to expect |
| Properties | Instructions for how each property of the event and entity data structures should be populated, as exact values or as a description |
Event specification statuses and versions
Each event specification has one of three statuses: Draft, while you edit it and before it's active in the pipeline (development environments still match events against drafts); Publishing, a transitional state lasting a few minutes while the pipeline propagates it; and Published, once it's active in the pipeline. Event specifications also have versions, which the History tab of each specification lists, with the changes between any two versions. See Test, promote, and publish a tracking design and Evolve a tracking design.
To create a tracking plan, see Create a tracking plan or Tracking plan templates. To add event specifications to it, see Define an event specification.