Retail runs on the next thirty seconds.
Baskets, listings, stores and sessions all move faster than a nightly model. Signals keeps the attributes your storefront, search and service teams read current while the visit is still happening.
- Entities
- basket · listing · store · SKU
- Read from
- storefront · search · CX desk
- Runs in
- your cloud · AWS · GCP · Azure
- Served in
- 6ms p50 in-region
What retail teams are up against
Three problems a nightly table cannot solve.
Margin
Discounting people who were going to buy anyway
Intent read from last week's cohort, not from this visit, so the code goes to everyone.
Discovery
Search that does not learn inside the session
Three failed queries in a row and the ranker still behaves as though it is the first.
Service
Agents who cannot see the last five minutes
The customer describes what just happened; the console shows yesterday's profile.
Where teams start
Four surfaces, one set of definitions.
PDP & basketIn-session personalisationSwap the module while the visit is live. Keyed on session and basket.Read the use case →SearchRanking that reacts to failed queriesFeed the ranker session-level features at request time, the same ones it trained on.Read the use case →Service deskAgent context on openThe last five minutes of behaviour in the ticket, not the nightly profile.Read the use case →Loyalty & CRMTriggers that fire on the condition, not the scheduleSend when the behaviour happens, with the same attribute the site used.Read the use case →
Fits the stack you have
No replatform. One SDK call.
Signals sits beside the commerce platform, the search engine and the warehouse you already run. It adds the live attributes none of them keep current.
Commerce platformreads attributes at render
Search & recommendationsfeatures at request time
Warehousesame definition, batch engine
CRM & messagingtriggered on the condition
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.