How the mining engines work
MarketBasketAnalysis ships seven mining engines. They are complementary, not interchangeable. The order-based engines answer one question, what gets bought together, from your real sales evidence. AI catalog pairing answers a different question, what should go together, from your catalog semantics. Most engines emit two-item pairs; FP-Growth additionally emits multi-item bundles. Co-occurrence is the always-on default and the safety net every other engine falls back to.
Two families, two questions
The engines split into two families that answer different questions, and they complement each other.
Order-based engines
Co-occurrence, SQL pairs, FP-Growth, seasonal cohort, return-aware, hosted HUI
These engines mine your real sales. They answer what gets bought together from evidence. The trade-off is coverage: they only surface combinations that customers actually co-bought, so brand-new products and rarely-paired SKUs get no recommendations yet.
Catalog-semantic engine
AI catalog pairing
This engine reasons over your catalog with your own LLM. It answers what should go together from product semantics, so it covers brand-new and rarely-sold items. The trade-off is evidence: its support, lift, and order count are derived from the model's confidence, not measured from sales.
The takeaway: AI catalog pairing complements the order-based engines, it does not replace them. Order engines bring evidence; AI brings coverage for the items evidence cannot reach yet.
The seven engines at a glance
Most engines emit two-item pairs; FP-Growth additionally emits multi-item bundles up to your maximum itemset size.
| Engine | Availability | Primary signal | Best for | Itemset size |
|---|---|---|---|---|
| Co-occurrence | Included on every plan | Lift and confidence over co-occurrence support. Each pair is scored by lift times confidence times (1 minus return rate), so a high-lift pair whose second product gets refunded a lot is down-ranked automatically. | Small-to-mid B2C storefronts that want reliable, explainable cross-sell with no AI key and no Plus plan. It is the sensible default for any store. Very large catalogs can hit the unique-SKU cap and should shrink the window or raise the limit. | Pairs only. Every rule has a single product on each side, and both directions are emitted when each clears the confidence threshold. |
| SQL pairs | Included on every plan | Co-purchase frequency expressed as support, with confidence and lift derived from per-item frequencies. It adds an explicit support-count floor before counting pairs. | Stores that want a fast, explainable, deterministic pair miner with an explicit support floor and a stable, fully sorted rule order. It is close to co-occurrence and a good default for any store. | Pairs only. Single product on each side, both directions emitted when each clears the confidence threshold. |
| FP-Growth (multi-item) | Included on every plan | Frequent-itemset support, with confidence and lift derived from each itemset and its sub-itemsets. A three-item itemset of A, B, C can yield a rule like A and B together imply C. | Stores that want true multi-item bundles (three or more products), not just pairs, for example a cart bundle that fires once a shopper already has several specific products. It honors the maximum itemset size setting (2 to 5), so raising that setting actually changes the output. | Pairs up to your maximum itemset size (configurable 2 to 5). It is the one engine that emits genuine multi-item bundles. |
| Seasonal cohort | Included on every plan | Recency and season-weighted lift. Each basket contributes a fractional weight: recent baskets and same-season baskets count for more, so the surfaced pairs reflect what customers buy now and in the current season instead of a flat all-time average. | Stores with strongly seasonal or recency-sensitive catalogs (apparel, holiday gifting, outdoor gear) where a flat window smears summer-only or trending bundles against stale, off-season orders. | Pairs only. Not configurable to larger itemsets. |
| Return-aware | Included on every plan | Reliability-weighted co-occurrence. Each product is down-weighted by its return rate before pairs are counted, so frequently-returned pairings fall below the thresholds before they ever reach a recommendation surface. | Stores with a meaningful, uneven return problem (apparel, footwear, fit-sensitive catalogs) where certain products are returned far more than others, and that have refund data available. With few or no returns it behaves exactly like co-occurrence. | Pairs only. Single product on each side, both directions emitted. |
| AI catalog pairing | Included on every plan, needs your own LLM key | A semantic merchandising judgment of complementarity from your own LLM, expressed as a per-pair confidence score. There is no transaction data behind any rule; the metrics are derived from the model's confidence so they compose with the statistical engines. | A new or low-volume store with too little order history for the statistical miner that needs a first set of cross-sell bundles based on catalog semantics rather than sales data. It reasons over your catalog, so it covers brand-new and rarely-sold products. | Pairs only. Single product on each side. |
| Hosted FP-Growth / HUI | Plus | Itemset utility: the sum of per-unit profit margin times quantity across matching orders, surfaced as a utility rank. The signal that sets it apart from the local engines is profit and utility, not co-occurrence frequency. | A Plus store whose products carry meaningfully different margins, where you want cross-sell optimized for profit (high-margin attachments) rather than just the most-frequently-co-bought items, and which has enough orders with real SKUs to produce useful itemsets. | Pairs as delivered. The hosted miner finds larger high-utility itemsets, then expands each one into pairs so the single-product recommendation lookup can resolve them. |
How to choose
You select an engine per mining run, or use Run both to pair an order engine with AI catalog pairing in one merged ruleset (see Combining engines below). When in doubt, co-occurrence is the safe default.
- A reliable, explainable default with no setup: co-occurrence or SQL pairs. Both are local, deterministic, and open to every plan; SQL pairs adds an explicit support floor and a stable rule order.
- Multi-item bundles (three or more products), not just pairs: FP-Growth. It honors your maximum itemset size and emits multi-item bundles that a cart rail can read.
- A strongly seasonal or trend-driven catalog (apparel, gifting, outdoor): seasonal cohort. It up-weights recent and same-season baskets.
- Certain SKUs returned far more than others (sizing, fit): return-aware. It suppresses high-return items before they surface, when refund data is available.
- Little or no order history but a rich catalog: AI catalog pairing. It reasons over the catalog and needs your own LLM key.
- Cross-sell optimized for profit, not just frequency (Plus): hosted FP-Growth / HUI. It ranks by margin-weighted utility and needs a hosted API key plus product margins.
Combining engines: what is possible today
An honest statement of how the engines combine right now.
One engine per run, or run both in one pass
A single-engine run uses exactly one engine. You select it in Settings, and that single engine produces and stores the run's rules. The built-in safety net is fallback: if a selected engine fails or is gated, the run degrades to co-occurrence and records a fallback note. The hosted FP-Growth / HUI engine also falls back to co-occurrence on the free tier because it is Plus-gated.
Run both: an order engine plus AI catalog pairing in one pass
Run both runs an order-based engine and AI catalog pairing together in one pass and saves one merged, de-duplicated ruleset. The order engine supplies evidence-backed pairs from your real sales, and AI catalog pairing fills the cold-start and rarely-paired gaps the order data cannot reach yet. Each pair is tagged by source, order, ai, or both, and order-based evidence is kept as the primary signal: when both engines emit the same pair, the de-duplication keeps the order-based metrics and tags the pair as both. On the free tier the order half is co-occurrence; on Plus it can be FP-Growth or the hosted HUI engine. The two halves compose because the AI engine's synthesized metrics are kept consistent with the statistical engines on purpose, and the recommendation lookup reads single-product pairs either way.
Bundle size: pairs, plus multi-item from FP-Growth
Most engines produce two-item bundles: one product implies one other product. Co-occurrence, SQL pairs, seasonal cohort, and return-aware are all pair miners. The hosted FP-Growth / HUI engine receives genuine larger high-utility itemsets and then decomposes each one into two-item pairs so the single-product recommendation lookup can resolve them.
FP-Growth is the exception: it mines itemsets of size 2 up to your maximum itemset size (configurable from 2 to 5), so it emits genuine multi-item bundles. A three-item itemset of A, B, C yields a rule like A and B together imply C. FP-Growth is the one engine that reads the maximum itemset size setting, so raising that setting changes its output; for the pair miners the setting has no effect.
Multi-item bundles surface only on a placement that seeds several products, such as a cart rail, which fires a bundle only when the cart already contains every product in it. A single-product page seeds just one product, so it can never satisfy a two-or-more product bundle.
Current limits and honest caveats
The fine print, so the comparison above is not over-read.
- Most engines emit two-item pairs. FP-Growth is the exception: it emits multi-item bundles up to your maximum itemset size.
- The maximum itemset size setting (2 to 5) is read only by FP-Growth; for the pair miners it has no effect on the output.
- FP-Growth's multi-item bundles surface only on a placement that seeds several products (a cart rail matches a bundle against the cart's products); a single-product page can never satisfy a two-or-more product bundle.
- AI catalog pairing's support, lift, and order count are derived from the model's confidence, not observed from sales.
- Return-aware and the return-aware scoring penalty only do something when refund data is available; with no returns they behave like plain co-occurrence.
- Hosted FP-Growth / HUI confidence and lift are proxies derived from the utility rank, not measured association statistics; only support and order count trace back to real itemsets.
- Co-occurrence and its local variants cost grows with the square of the unique-SKU count; very large catalogs can hit the SKU cap.
For the developer-facing reference, including the shared rule contract, the per-job thresholds, and the extensible engine layer, see the mining engines reference.
Ready to turn your order data into revenue?
Install on your platform in under 10 minutes. Or book a consulting call and we'll do the launch for you.