You can build it. Then you own it forever.
Signals computes live attributes from what your customer is doing and serves them to your app in 6ms. Run it on your own traffic this afternoon, before anyone writes the staffing plan.
- 6ms p50 read, in-region
- 0 streaming jobs you run
- Free tier, no card
Below is your own visit to this page, computed by Signals as you read.
Signals, about you
connectingSee live events firing as you browse this page on the left; what Signals computed about you on the right, refreshed every few seconds.
Add the Signals MCP server to Claude Code, Cursor or any MCP client, then run this. The agent adds the SDK, defines the attribute and wires the read into your own app.
$ npx plugins add snowplow/skills
> Use the Snowplow MCP server and Signals skill, then help me plan and implement a use case. Make sure everything is tested and works as intended.
trackPageView(); // browser tracker, already on this pageAttribute(name="pages_last_5_min", events=["page_view"], aggregation="category_count", property="page_urlpath", period=timedelta(minutes=5))
await signals.getServiceAttributes({ name: "signals_site_session_service", attribute_key: "domain_sessionid", identifier: "…", // your session id, once set });
Almost none of the work is the attribute logic.
Ingestion, state, serving
Collector, schema registry, failed events, windowing, watermarks, late arrivals, hot keys, checkpointing, a low-latency API, auth, TTLs, versioning. Most of them discovered in production.
still upstream of the featureYou own the definitions
The engine handles windowing, late events, hot keys and backfills. What your team writes is what you want to know about a customer, and the code that reads it.
define it, then read itThe roadmap gets its engineers back
The people who would have maintained a profile API go back to the ranking, the experience and the product a customer actually notices.
on-call, oursThe build has a launch date. It does not have an end date.
A build plan is a staffing plan. Price it that way and the comparison stops being a license fee against a sprint estimate.
Two implementations that drift
The streaming logic and the batch logic have to agree forever. When they stop agreeing the model degrades quietly, and nothing pages anyone.
On-call for plumbing no customer sees
Hot keys at peak, a bad deploy, the state rebuild after it. The rota is permanent and the work is invisible to everyone reading the roadmap.
pages per quarter · engineer retentionEvery new attribute is a ticket
When a PM has to queue behind data engineering for each new definition, personalization stays next quarter for three quarters running.
attributes shipped per quarterYour agent writes it, your team runs it
A coding agent can produce the first streaming job in an afternoon. It cannot hold the state model, rebuild after a bad deploy or take the page at peak. Point it at Signals instead and the afternoon ends with nothing new to own.
The parts you would have built, already running.
Managed SaaS or a private deployment in your own AWS or GCP account, on identical architecture, so what you evaluate is what you run.
- 01Collect. Add a Snowplow SDK to your application and behavioral events start flowing in, schema-validated on the way.
- 02Define. Say what you want to know about the customer, in the console or in code, versioned through CI/CD like the rest of your stack.
- 03Serve. Your app reads it at 6ms p50, on every request, and the on-call rota is ours.
The questions your architect will ask
How do we justify this internally?
Compare it against a staffing plan, not against a license fee. The build cost is mostly people, it does not end at launch, and the engineers it needs are the ones already assigned to product work.
Are we locked in?
Events are yours and land in your warehouse. Definitions are portable. Leaving costs you the engine, not the data.
Can we run it in our own cloud?
Managed SaaS, or a private deployment in your own AWS or GCP account. Identical architecture either way, so what you evaluate is what you run.
What if our attribute logic is unusual?
Custom functions are supported and versioned like the rest. Counts, recency and ordering cover most of what teams build by hand.
Do I need an event stream already?
No. Collection is part of Signals, which is the half of the build that usually takes the longest. Add a Snowplow SDK and events start flowing in, validated against your schemas on the way.
What does the free tier include?
The full product against your own traffic, up to 5 million events a month, with no card and no sales call. You should see an attribute updating against your own traffic in the first session.
Try the alternative before you staff the build.
Add the SDK, define one attribute, then click around your own product and watch it change. That is the whole thing, on your own traffic, this afternoon.
npx plugins add snowplow/skills