Real-time recommendations

Your recommender is good. Its inputs are a day old.

Signals computes behavioral attributes from what this customer is doing now and serves them to your model at inference time, in 6ms, so the recommendation reflects the session in progress.

  • 6ms p50 read, in-region
  • <1s event to attribute 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 model looks worse in production

The model is not the problem. What it gets fed is.

Before

Features computed overnight

The batch job ran at two in the morning. Everything the customer has done since then, which is the only reason they are on the page, is invisible to the model scoring them.

last_computed = 02:00
With Signals

The same features, current to the event

One definition computes in the serving layer and is current <1s after the event that moved it, so inference reads the session in progress rather than yesterday's aggregate.

categories_viewed_10m = 3
Result

Cold start ends inside the first session

A first-time visitor stops being an average. Three minutes of behavior is enough to score from, and it is there before the second page renders.

first visit, real inputs
What changes at inference time

What a recommender can use once its inputs are seconds old.

None of this needs a better model. It needs the model to be told what is happening while it still matters.

End the cold start inside the session

Most sessions are anonymous or new. Keying on the session rather than the person gives the model something real to score from the second page view, with no identity to resolve first.

coverage of scored sessions

Serve the features you trained on

One definition builds the training set and serves the request path, so the lift you measured offline is the lift you get online instead of a quarter spent tracing the skew.

offline-to-online lift gap

Score the basket, not only the shopper

Attributes key on whatever the recommendation is about: a basket, a listing, a store, a playlist. The entity does not have to be a person.

entities per model

React within the session, not after it

A customer who has switched category twice in four minutes wants something different from the one who has been on the same product page since they arrived. Both are visible now, neither is visible tomorrow.

session conversion · click-through
How it works

One definition. Live at inference, correct in training.

The streaming engine keeps the value current for serving; the same definition builds a point-in-time correct training set from your warehouse history.

  1. 01Collect. Add a Snowplow SDK to your application and behavioral events start flowing in. No stream to stand up first.
  2. 02Define. Say what the model should know about the customer, in the console or in code, versioned through CI/CD.
  3. 03Serve. An event updates its attributes in <1s, and your model server reads them at 6ms p50, on every request.
Signals → your app6ms p50
categories_viewed_10m3
items_viewed_session7
seconds_on_product_page47
basket_value184.00
sessions_last_7d4
Trigger intent_shiftdelivered to your model server
Questions

Before you sign up

Does this replace my recommender?

No. Signals does the knowing. Your model, your rules engine or the packaged recommendation product you already run keeps doing the deciding, with inputs that are seconds old instead of a day old.

Will it fit inside my inference budget?

6ms p50 and 10ms p95 for an in-region round trip, and one call returns a whole service rather than one attribute at a time. It is a number with a boundary on it; whether it fits your budget is your call.

How do I train on these features?

The dataset builder computes each attribute from only the events before the moment you are predicting from, using the same definitions the live path reads. Nothing that happened afterwards can leak into training.

Do I need an event stream already?

No. Collection is part of Signals, and it is usually the half of this project that takes the longest. Add a Snowplow SDK to your application and events start flowing in.

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.

Score your own traffic on what happened a minute ago.

Add the SDK, define one attribute, then click around your own product and watch the value your model would have read move while you do it.

The real engine · no card · no sales call
Or hand it to your coding agent
npx plugins add snowplow/skills
Then: Let's add Snowplow Signals to this app. Understand how recommendations are served first, then define an attribute for categories viewed this session and read it back before the model scores.
Signals, about you
connecting...