Retail
Every interaction is a signal. Pricing, recommendation and demand read the same event history, so they stop contradicting each other.
the entity here isa customer, or a SKUWhat the model actually reads
No aggregation, no feature engineering — the events your systems already write, in the order they happened.
- views and searches
- cart events
- purchases and returns
- price and promotion changes
- stock movements
- support contacts
What breaks with one model per problem
Segments are always one step behind
A customer who changed behaviour this week is still being served last quarter's segment. The sequence updates itself.
Long tail, cold start, sparse history
A model that learned the whole catalogue's behaviour has something to say about a SKU with four sales.
Peaks break the pipelines
Black Friday is exactly when the aggregation jobs fall behind. Reading raw events removes the job from the critical path.
One foundation, a specialisation per question
Each of these is a head on the same trained model, not a separate project with its own pipeline.
Dynamic pricing
Price against observed demand and elasticity per SKU, not against a rule table maintained by hand.
Personalised recommendations
The next item follows from the whole sequence of the visit, not from the last click.
Demand forecasting
Forecast per SKU per location from the events themselves, including the ones with almost no history.
Basket intelligence
What goes together, for this customer, right now — rather than what went together on average last year.
What we can point at
personalisation — one action per customer, per interaction
faster inference across the catalogue
events processed in real time