Product/Event collection

Add the SDK and Signals starts collecting.

Every attribute, trigger and agent context starts with an event. Signals collects them for you, from web, mobile and server. You do not need an event stream before you begin.

The real engine · no card · no sales call
Your app → Signalstrack
// your storefront, when a price is shown
trackSelfDescribingEvent({
  event: {
    schema: "iglu:com.acme/view_price/jsonschema/1-0-0",
    data: { sku: "TRL-2201", price: 92.0 }
  }
});
Illustrative. One call from the web SDK. Page views, clicks and form activity are tracked automatically; custom events like this one you define.
Signals → your app● in the stream
{
  "event": "view_price",
  "schema": "iglu:com.acme/view_price/jsonschema/1-0-0",
  "data": { "sku": "TRL-2201", "price": 92.0 },
  "user_id": "u_48213",
  "session_id": "9f3c1a…",
  "device": "mobile", "country": "GB",
  "collector_tstamp": "2026-09-14T09:41:07.212Z"
}
Validated against your schemaevery attribute that depends on it recomputes
35+ SDKs

web, iOS, Android, React Native, Flutter, server-side languages and many more.

1 schema

per event type. Checked on the way in, before anything computes on it.

0 streams

to build or run before your first attribute

The problem

Every real-time project starts with a pipeline nobody wants to build.

Feature stores assume good events already exist. A DIY build starts with Kafka, a tracker, a schema registry and a team to run them. So responding to live behavior becomes a data-platform project, and the first use-case is quarters away.

In Snowplow Console

Every event you collect, listed with its schema.

A tracking plan lists each event, the schema it is checked against, how much is arriving and when it was last seen.

The Snowplow Console showing a storefront tracking plan with its event specifications, volumes and publish status.
Snowplow Console, shown with example data.
How it works

Add the SDK. Events arrive validated. Attributes compute on them.

A single trackSelfDescribingEvent call sending a view_price event with sku TRL-2201 and price 92.0.01 · Instrument

Add one SDK to your web, mobile or server app.

Page views, clicks and form activity are tracked automatically. Custom events are one tracking call with the fields you choose. Point your coding agent at the Snowplow MCP server and it creates your events, writes the tracking call and checks the first events arrive.

A schema check on view_price where a numeric price is valid and a string price is set aside with the reason "string found, number expected".02 · Validate

Each event is checked against its schema as it arrives.

A schema is the shape you expect an event to have. Events that do not match are set aside, not silently dropped and not counted. Bad data never reaches an attribute.

A view_price event arriving both in live attributes, recomputed in under a second, and in the warehouse on Snowflake, BigQuery or Databricks.03 · Available

The event is in the stream and in your warehouse.

Live attributes recompute the moment it lands. The same event is written to Snowflake, BigQuery or Databricks for history, so streaming and batch see one record.

Works with
  • Snowflake
  • BigQuery
  • Databricks
  • AWS
  • Google Cloud
Capabilities

Collection built in, so the project starts at the attribute.

Web, iOS, Android and server apps feed one validated, enriched stream, where a view_price event gains device, country, referrer and campaign fields before going to live attributes and to the warehouse.
01

web · iOS · Android · React Native · Flutter · Node.js · Python · Java · Go · Ruby · .NET. One event model across all of them.

Web, iOS, Android and server apps feed one validated, enriched stream, where a view_price event gains device, country, referrer and campaign fields before going to live attributes and to the warehouse.
02

You describe the shape of each event once. Anything that does not match is kept aside with the reason, so a broken release cannot poison an attribute.

Two view_price events checked against their schema: the one with a numeric price passes into the stream, and the one with price sent as the string "92.00" is set aside as a failed event with the reason "$.price: string found, number expected".
03

Track what matters to your product, not a fixed menu. Add a field, version the schema, and old events keep their meaning. Design and instrument it from Claude Code or Cursor through the Snowplow MCP server.

A coding agent in a terminal uses the Snowplow MCP server to create a view_price schema and event specification, adds a trackSelfDescribingEvent call to the product page, then confirms the first events arrived with 0 failed.
04

Device, geography, referrer and campaign fields are added to each event before it reaches an attribute. Nothing to join later.

A view_price event as sent, with its IP address, user agent, referrer and page URL, next to the same event after enrichment, which adds geo_country and geo_city from an IP lookup, device class and browser from the user agent, refr_source and refr_medium from the referrer, and mkt_source, mkt_medium and mkt_campaign from the campaign parameters.
05

The event that recomputes an attribute now is the same event that lands in your warehouse minutes later. Production matches training.

One view_price event with a single event_id updates live attributes now and appears as the same row, with the same event_id and timestamp, in the atomic.events warehouse table.
06

Events land in your AWS or GCP account, or ours. Consent is recorded at the collection point, before anything is computed or served.

Events from web, iOS, Android and server apps enter a boundary labeled your cloud (AWS or GCP), where a collector, consent recorded with each event, and validation and enrichment come first, before Signals and the warehouse.

Full reference: SDKs →

Collect. Define. Serve.

Connect the Snowplow MCP server and let your coding agent do the instrumenting. Then define one attribute and watch it change while you interact in real-time. Free tier, no card, no sales call.