--- title: "Real-time recommendations | Snowplow Signals" description: "Your recommender is good. Its inputs are a day old. Signals computes live behavioral attributes and serves them to your model at inference time." source: https://signals.snowplow.io/lp/real-time-recommendations --- 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 ## Start free 5M events a month · unlimited attributes · no card Work email Continue A work address, please. We cannot provision on a personal domain. Or [talk to an engineer](https://signals.snowplow.io/start?intent=engineer&lp=real-time-recommendations). [ Try it on yourself ↓ ](#live-panel) 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. Implement this this page · events 0 writes Product Solutions Developers Pricing Start free Start free Engineer this panel the rest of the page nothing sent yet write attribute store · your session no 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. hand it to your agent one prompt 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. Copy the prompt[How to connect the MCP server](https://docs.snowplow.io/docs/llms-support/snowplow-mcp/) or write it yourself three steps 01 Track the event once, in your app trackPageView(); // browser tracker, already on this page 02 Define the attribute once, in Signals Attribute(name="pages_last_5_min", events=["page_view"], aggregation="category_count", property="page_urlpath", period=timedelta(minutes=5)) 03 Read it back every request await signals.getServiceAttributes({ name: "signals_site_session_service", attribute_key: "domain_sessionid", identifier: "…", // your session id, once set }); 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. 01 **Collect.** Add a Snowplow SDK to your application and behavioral events start flowing in. No stream to stand up first. 2. 02 **Define.** Say what the model should know about the customer, in the console or in code, versioned through CI/CD. 3. 03 **Serve.** An event updates its attributes in <1s, and your model server reads them at 6ms p50, on every request. Signals → your app 6ms p50 categories\_viewed\_10m 3 items\_viewed\_session 7 seconds\_on\_product\_page 47 basket\_value 184.00 sessions\_last\_7d 4 Trigger intent\_shift delivered 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. [Start free](https://signals.snowplow.io/start?lp=real-time-recommendations) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer&lp=real-time-recommendations) The real engine · no card · no sales call Or hand it to your coding agent $ `npx plugins add snowplow/skills` Copy Copied 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.