Change the page while they are still on it.
In-session personalisation needs to know what this customer is doing in the next thirty seconds, not what their cohort did last week. Signals computes that on the event stream and hands it to whatever renders the page, mid-request.
- 00:00Third visit to the same product page
Nothing in the warehouse knows yet.
- 00:41
showing_price_hesitationflips to trueRecomputed inside a ten-minute window.
- +6msYour ranker reads it before the page paints
Reassurance module in, upsell rail out.
The signal arrives after the visit ends.
Most personalisation reads a table that was written overnight. It can tell you this person is a lapsing mid-value shopper. It cannot tell you they have looked at the same jacket three times in four minutes and bounced off the delivery estimate twice.
Three attributes, one service, one call in your renderer.
Name the behaviour you want to react to
Repeat views on one listing, idle time in the basket, failed searches this session. Counts, recency and order cover most of it.
Bundle them into a service your app owns
One storefront service, one round trip. Front-end teams do not need to know which attributes exist.
Call it where the decision is already made
Inside the ranker, the module selector or the edge function. No new decisioning layer to adopt.
| Attribute | Key | Window | Read by |
|---|---|---|---|
showing_price_hesitation | session | 10 minutes | PDP module selector |
basket_idle_seconds | basket | since last add | Checkout nudge |
failed_searches_session | session | this session | Search ranker |
Measured on the surface you changed.
Streaming infrastructure for your team to run
Added to the render path, p50 in-region
Shared by the live surface and the model that trained on it
user · session · basket · listing · store
Start with one attribute.
Define it, read it in your own product, and see it change while you click around. 14 days, no card, no sales call.