The problem
Patterns hide in operational data in two forms: statistically discoverable (you can find them by running an analysis) and predictive (you can use them to predict the next event). Most BI tools surface the first kind — show me which categories co-occur, which customer segments correlate, which products are bought together. Few tools surface the second kind cleanly, because that requires a predictive operator running over the same data.
The Patterns view in the e-commerce demo surfaces both at once. For an anchor product category, it returns the categories bought in the same orders ranked by lift: which products are bought together, and how strongly. The same _relate runs with a season or a declared pet or diet as the anchor ("who buys what, and when"), and over clicks and purchases.
How it works
_relate returns, for an anchor, how much more (or less) often each other value occurs with it than without: the lift, with the counts behind it. The Patterns query asks "for anchor X, which categories share an order with it?" The demo shows a lift only when its 95 % interval clears 1 across the whole section, with the interval widened because one customer's orders are not independent, and ranks what remains by lift. The strongest basket pair in the PetNord data is 3.17×, so the bar for "worth a look" is set by the interval, not by a fixed lift.
The view has four sections: what goes with clicks and purchases, who buys what and when, baskets as directional rules, and search words. Each opens with a sentence on what its strongest rows mean for the shop, and every row carries its counts, so a thin pattern reads as thin. The view is for discovery: turning a pattern into a rule, a recommendation seed or a tracked metric is left to the application.
{
"from": "orders",
"where": {
"line_categories": {
"$match": "dog_dryfood"
}
},
"relate": "line_categories",
"limit": 100
}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.
Frequently asked
How is this different from a typical analytics dashboard?
Analytics dashboards show pre-aggregated metrics — total sales, churn rate, average order value. Pattern Explorer surfaces the conditional relationships in the data — which attributes correlate, which segments behave differently, which combinations co-occur. Dashboards answer "what happened?"; Pattern Explorer answers "what patterns exist that I have not named yet?"
Does this surface causation or just correlation?
Correlation, ranked by statistical significance (lift × support). The system does not claim causation; it surfaces patterns worth investigating. The user (or downstream causal analysis) determines whether a pattern reflects causation or some other mechanism. For most operational questions ("are these patterns real and stable enough to act on?"), correlation at high lift × high support is what matters.
How do we avoid information overload from many patterns?
Two filters do the work in the demo. A lift is shown only when its 95 % interval clears 1, with the confidence held for the whole section rather than per row (the Baskets section tests 44 pairs at once), and the interval is widened for repeat customers. What survives is ranked by lift, with the counts beside each row. A stricter or looser confidence level gives a shorter or a broader list.
Can the patterns be exported to other tools (Tableau, Looker)?
Yes — the _relate query returns JSON; the result is exportable to any analytics tool that accepts JSON. The typical pattern is: Pattern Explorer surfaces the discovery; the team picks a pattern to track; the metric goes into the BI dashboard for ongoing monitoring. Aito stays in the discovery role; the BI tool handles the dashboard.
What is the difference between Pattern Explorer and Rule Mining?
Pattern Explorer is the discovery surface — wide, exploratory, no expected action. Rule Mining is the workflow that turns discovered patterns into authored rules — focused, decision-oriented, with promote/dismiss/override actions. The two share the same underlying _relate operator; they differ in the UI and the workflow on top.
