Introduction to Snowplow events
Events are the primary way to capture data with Snowplow. Every time something happens that you want to track, you can send an event to your Snowplow pipeline. Each event is a JSON object that describes what happened. Events flow through your pipeline where they're validated, enriched, and loaded into your data warehouse or lake for analysis.
Snowplow event types
All Snowplow events have the same underlying structure and standard fields. However, there are two types of events in Snowplow:
- Schema-less baked-in events
- The baked-in event types are page views, page pings, and structured events
- Self-describing events that are based on a JSON schema
- All other events are self-describing events
- This includes out-of-the-box events that come with Snowplow, and custom events that you define yourself
Whether an event is baked-in or self-describing affects how you'll model the data.
All Snowplow events are by default tracked with schema-defined entities attached to them.
Baked-in events
The following events are "baked in":
In the data warehouse, any event-specific information will be in standard columns in the Snowplow events table. You can find those listed here.
Find out more about how to track and model page view and page ping events here.
We recommend using self-describing events instead of structured events whenever possible. Structured event tracking is a legacy format used to track events that were not natively supported by Snowplow.
The legacy transaction and transaction_item events are also "baked-in". Several Snowplow trackers provide ecommerce tracking APIs; we recommend using these instead, as they support current Snowplow best practise, and are compatible with the Snowplow ecommerce dbt package.
Self-describing events
Self-describing events can include arbitrarily complex data, as defined by the event's data structure or schema. We call them "self-describing" because these events include a reference to their underlying JSON Schema data structure.
Each self-describing event consists of two parts:
schema: a reference to a schema that describes the name, version and structure of the eventdata: the event data as a set of key-value properties in JSON format
Because the event references a specific version of its schema, it's always clear to downstream users and applications what each field in the event means, even if your definition of the event changes over time.
Snowplow provides a large number of self-describing events out-of-the-box, for example:
Check out the full range of included events here.
You can also create custom self-describing events to match your business requirements. Snowplow provides tooling to help you define and track custom events.
Find out in the warehouse tables fundamentals page about how self-describing events are structured in the data warehouse.
We originally called self-describing events "unstructured events", to distinguish them from structured events. This was misleading, because these events are actually more structured than structured events. The old term is deprecated, but you might still see it in some docs, APIs and database column names, such as unstruct_event or ue.
How to track events
Track events in your applications using one of the Snowplow tracking SDKs. Each SDK provides built-in APIs to track different types of events.
All the trackers also support custom tracking, so you can define the events that are relevant to your business.
You can also use webhooks to track automated actions. The Snowplow Collector endpoint accepts all valid Snowplow event payloads, regardless of their source.