Real-time session classification

Classify every session, without a frontier model in the render path.

Q: Why not keep the general model and cache its answer?

Caching helps for a visitor who does nothing. The reason to classify in the session is that the state changes on every click, so a cached answer is last minute's answer. Precomputing the state and asking a small typed question is what makes a fresh answer affordable on every render.

Q: Why not send the raw event history?

Accuracy and cost. TypeSafe's documentation says accuracy falls as state fills with material the question does not need, and to retrieve and filter in code first. A named context is that filter, applied before the call, and it is also why the call stays small.

Q: Does this only work with Jev?

No. The context comes back as JSON over the REST API, the Node.js or Python SDK, or the MCP server, and as a plain string in narrative form. Anything that takes a state object or a prompt can read it. Jev is the model this page is written for because a typed question with a probability is the shape a render-path classifier needs.

Q: Does Signals classify anything?

No. Signals computes what the visitor is doing and hands it over. The classification is the model's answer, and what happens next is your code's call.

Q: Do I need an event stream already?

No. Collection is part of Signals. Add a Snowplow SDK to your web, mobile or server app and events start flowing in. If you already run Snowplow, Signals reads the pipeline you have.

Q: 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.

Signals computes what this visitor is doing and hands it over as compact state in 6ms. Jev answers a typed question about it in a fraction of a second, with a probability you can gate on. No prompt over the raw clickstream, no seconds of latency, no answer that changes each time you ask.

6ms p50 read, in-region
<1s event to state current
Free tier, no card

Try it on yourself

Below is your own visit to this page, computed by Signals as you read.

Signals, about you

connecting

See live events firing as you browse this page on the left; what Signals computed about you on the right, refreshed every few seconds.

this page · events0 writes

nothing sent yet

write

attribute store · your sessionno read yet

reading_now

pages_last_5_min

seconds_since_last_action

sections_read

seconds_engaged

pricing_views

menus_explored

features_wanted

cta_clicks

arrived_from

waiting for the first computed value…

Your first events are in flight through a real Snowplow pipeline. Attributes appear as the stream computes them, usually within a few seconds.

Why the first attempt gets pulled

The prototype classified sessions well. The bill and the latency killed it.

Before

A general model over the clickstream

Put the session's events in a prompt, ask which kind of visitor this is, wait seconds, pay per token for history the question did not need, and get a different answer when you ask again. Fine for a demo. Not for a render.

latency in seconds, cost per session

With Signals

Compact state, typed question

Signals keeps a named context current as of this click, holding only the activity the classification needs. Jev reads it as a state object and returns a choice with a probability, in a fraction of a second.

intent = comparing (0.88)

Result

On the render path, at render cost

The classification runs on every page, inside the budget the page already has, and the same state gives the same answer. Gate on the probability and act in your code.

every render, same session

What changes

Four things the prototype could not give you.

A classifier earns a place on the render path only if it is fast enough to sit there, cheap enough to run on every session and stable enough to build a rule on.

Latency you can render behind

The state is precomputed by Signals and read in 6ms. The typed question is answered by a model built for that shape of call. Together they fit inside a render, which a general model over raw history never did.

p95 render time

Cost that scales with decisions, not history

The context holds the activity the question needs, current as of this click, rather than the whole clickstream re-sent on every call. A visitor who did a lot does not cost more to classify than one who did a little.

cost per classified session

The same answer for the same state

A typed choice with a calibrated probability lets you set the threshold your code acts on. Below it, the default. Above it, act. No parsing prose, no answer that drifts between calls.

precision at threshold · rule stability

A decision you can read back

When a classification looks wrong you can read the exact state it was given, because it is a named context with a handful of fields rather than a prompt nobody kept.

time to debug a decision

How it works

Precompute the state. Ask a typed question. Act on the probability.

Signals does the knowing, ahead of the request. Jev does the classifying, inside it. Your code does the acting.

01Collect. Add a Snowplow SDK to your app and behavioral events start flowing in, validated on the way.
02Read. Name the activity the classification needs. Signals keeps it current within <1s of the event and returns it as JSON in 6ms p50.
03Classify. Pass it as state, ask a typed choice or a yes-or-no question, gate on the probability and act in the same render.

Signals → your app6ms p50

namesession_state

formatjson

eventslast 30 this session

seconds_since_last_action12

failed_searches_session2

Trigger stuck_high_intentdelivered to your app

Questions

Before you sign up

Why not keep the general model and cache its answer?

Caching helps for a visitor who does nothing. The reason to classify in the session is that the state changes on every click, so a cached answer is last minute's answer. Precomputing the state and asking a small typed question is what makes a fresh answer affordable on every render.

Why not send the raw event history?

Accuracy and cost. TypeSafe's documentation says accuracy falls as state fills with material the question does not need, and to retrieve and filter in code first. A named context is that filter, applied before the call, and it is also why the call stays small.

Does this only work with Jev?

No. The context comes back as JSON over the REST API, the Node.js or Python SDK, or the MCP server, and as a plain string in narrative form. Anything that takes a state object or a prompt can read it. Jev is the model this page is written for because a typed question with a probability is the shape a render-path classifier needs.

Does Signals classify anything?

No. Signals computes what the visitor is doing and hands it over. The classification is the model's answer, and what happens next is your code's call.

Do I need an event stream already?

No. Collection is part of Signals. Add a Snowplow SDK to your web, mobile or server app and events start flowing in. If you already run Snowplow, Signals reads the pipeline you have.

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.

Classify your own session, on this page, today.

Add the SDK, define one context, ask one typed question from the code that renders. The panel at the top of this page is the state that question would run on, computed from you as you read.

Start free Talk to an engineer

The real engine · no card · no sales call

Or hand it to your coding agent

npx plugins add snowplow/skills

Then: Add Snowplow Signals to this app. Find where we classify or would classify a visitor, define an agentic context holding only the activity that classification needs, read it as JSON and pass it as the state on a Jev typed question. Gate on the probability before acting.