First-party architecture
MarketBasketAnalysis is structurally first-party. Mining runs on the merchant's own server (WooCommerce, Magento) or in our isolated per-shop backend (Shopify). We never see customer PII, and we do not pool data across merchants to train a shared model. This page walks through the data flow per platform, what we never see, what stays where, and the legal posture (Article 28 processor, named sub-processors).
Where mining actually runs
Isolated per-shop backend
Each Shopify install gets its own isolated database row at app.marketbasketanalysis.com (Fly.io, US region by default). Order data is fetched via the Shopify Admin GraphQL API, mined in-memory, and the raw line items are discarded after the job completes. Only aggregated co-purchase rules (support, confidence, lift) persist. Per-shop encryption keys; no cross-tenant queries are possible at the database layer.
Merchant's own server
The WP plugin runs entirely on the merchant's WordPress install. Order data is read from the merchant's own WooCommerce tables and rules are stored in the same database under the mba_* table prefix. No order data ever leaves the merchant's server. We have no access to the host.
Merchant's own server
The composer module (marketbasketanalysis/module-reports) runs as a native Magento 2 module on the merchant's install. Order data is read via the Magento sales repository and rules are persisted to the merchant's database under the mba_reports_* table prefix. No order data ever leaves the merchant's server.
Customer PII does not enter our systems
Not collected, not stored, not transmitted
- Customer names. Mining engines work on
(order_id, product_id)tuples. The customer identity field is dropped at extraction time. - Email addresses, phone numbers, shipping or billing addresses. None of these are read by the mining pipeline. They live on the merchant's order record and are never copied.
- Payment data (card numbers, tokens, gateway IDs). Not in scope. We are not a PCI processor.
- Individual customer purchase histories. Rules are aggregated across all baskets; the output is
P(B | A)across the merchant's order corpus, not per-customer profiles.
Data residency by platform
| Data | Shopify | WooCommerce | Magento |
|---|---|---|---|
| Raw order line items | Merchant's Shopify, read in-memory | Merchant's WP database | Merchant's Magento database |
| Aggregated co-purchase rules | Isolated per-shop row at app.marketbasketanalysis.com | Merchant's WP database | Merchant's Magento database |
| Customer PII | Never read | Never read | Never read |
| LLM prompts (Pro AI features) | Direct to merchant's provider key | Direct to merchant's provider key | Direct to merchant's provider key |
On Shopify, the only data that crosses to our systems is the set of aggregated rules and their statistical signals (support, confidence, lift, item ids). On WC and Magento, even the aggregated rules stay on the merchant's own database.
We do not train a shared model on your data
Explicit non-pooling statement
MarketBasketAnalysis does not aggregate order data, basket data, or co-purchase rules across merchants for the purpose of training a shared recommendation model. There is no cross-merchant graph. There is no pooled embedding space. There is no “the more merchants you have on the platform, the better your recommendations get” flywheel, because that flywheel would require pooling, and we do not pool.
Each merchant's recommendations are derived exclusively from that merchant's own order history. This is the opposite of the generic-graph model used by large platform AI. It is also what makes the per-merchant signal genuinely accurate, our recommendations reflect what your customers actually buy, not a population average.
Processor relationship and named sub-processors
We act as a processor under Article 28
Where MarketBasketAnalysis does process data on behalf of a merchant (specifically: the hosted Shopify backend), the merchant is the controller and we are the processor as defined in Article 28 of the General Data Protection Regulation. A Data Processing Addendum (DPA) is available on request and is included by default with the hosted-tier contract.
On WooCommerce and Magento, where mining runs entirely on the merchant's own server and no order data reaches our infrastructure, the processor relationship does not apply to that data flow. We are still the processor for the marketing site and the AI features described in our main Privacy Policy.
Sub-processors
The following sub-processors handle limited scopes of data on our behalf. DPA links are available on request.
| Sub-processor | Scope | Region |
|---|---|---|
| Fly.io | Shopify backend hosting (compute + database) | US (default), EU on request |
| Vercel | Marketing site hosting (no merchant order data) | Global edge |
| Resend | Transactional email (account + support correspondence) | US |
| Sentry | Error tracking (PII scrubbed at SDK) | US |
| PostHog EU | Marketing analytics (no merchant order data) | EU |
| Stripe | Payments + subscription billing | US |
| Cloudflare | DNS + email routing | Global |
We notify customers of material changes to this sub-processor list in advance. To request a current DPA or to be added to the sub-processor change notification list, contact [email protected].
First-party intelligence, on your platform
Install MBA on Shopify, Magento, or WooCommerce. Mining runs where you specify, customer PII never leaves your store.