The problem
Market-basket analysis is one of the oldest questions in retail data: when a basket holds A, how often does it also hold B? The classic answer is a batch job (Apriori, FP-growth) that writes a frozen rule table. The table is stale the day after it is built, and somebody has to own the job that rebuilds it.
The rules are also directional, which a plain co-occurrence count hides. The share of A baskets that also hold B is usually not the share of B baskets that also hold A, and a cross-sell or shelf decision depends on which way the rule points.
How it works
For each anchor category, one _relate over the orders whose basket contains the anchor returns the related categories with the counts behind the lift. Confidence (the share of anchor baskets that also hold B) and support come from the same counts. Rules that clear the lift, confidence, and support gates are ranked by lift, so the table is a query over the current orders rather than a stored artifact.
Pattern Explorer runs the same query for one anchor you pick and shows the whole lift band. Basket Rules sweeps the anchors and keeps only the directional rules strong enough to act on.
For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🛒 E-commerce demo today. Click through to the live application and inspect the queries that produce the result.
