Paste a Shopify URL and get back what the store is running: catalogue and pricing structure, installed apps, theme, pixel stack, visible ad activity, review volume and velocity, and labelled estimates of sales velocity and revenue.
Nothing here requires the store's permission, because nothing here reads the store's private data: only what it publishes, and what third parties publish about it.
Where to use it
| Surface | For |
|---|---|
| /intelligence/inspect | Single-probe inspectors: theme, apps, ads, emails |
| /intelligence/radar | What is moving right now |
| /intelligence/transparency | Method and provenance, in public |
| /<org>/intelligence | Your organization's view |
| /<org>/<store>/intelligence | One store's competitive picture |
| Intelligence API | The same data, programmatically |
Estimates are labelled as estimates
A revenue figure inferred from the outside is an inference. The model computes each revenue and sales-velocity estimate with a low bound, a high bound and a confidence score, and the record keeps all three next to the figure. Before calibration the band is wide on purpose; it tightens as the model is checked against connected stores that opted into the calibration program.
Not every screen prints the band yet. The Hub's store list shows the central revenue figure only, with a note that calls it directional: read it as a direction, not as a measurement.
A signal's confidence also decides how loudly it is surfaced: a confident anomaly raises a critical alert, a weaker one a warning, and a weak one stays a data point.
Freshness is tiered
Refreshing every tracked store at the same rate would be both slow and wasteful, so the refresh runs in bands: hot stores hourly (with a deeper pass four times a day), warm every six hours, cold daily. Market aggregates, prediction rollups and a weekly backtest run on their own schedules.
The Store Graph
Stores are related to each other by what they share: tracking ids, theme-and-app fingerprints, creatives. That inverted index is what turns "this store" into "this network of stores": the same operator behind several brands, the same agency's fingerprint across a portfolio.
What we do not collect
The honest limits, because a tool that hides them is worse than one without the feature:
- No traffic panel of our own. Rebuilding a multi-million-user measurement panel is a nine-figure entry cost. The monthly visits in a store record come from a third-party web-traffic estimator, and they are stored as an observed estimate, never as a measurement.
- No email honeypot fleet. Harvesting email cadence with a warmed fleet of fake inboxes is how competitors get that corpus. It is also a GDPR exposure measured in percent of global revenue. We collect what is observable without one (popups, landing pages) and stop there.
- No history we did not live. Our timeline starts when we started.
Being on the receiving end
Our scanner identifies itself as BoostEcom-Scanner/1.0 and cites
/about/scanner in its user agent, so a store owner
reading their logs can find out who we are and what we do. That page is
a policy, not a landing page.
Records at /intelligence/stores/<domain> are noindex, nofollow and
out of the sitemap, and outbound links to a scanned store carry no UTM
and a nofollow. We do not benefit from indexing someone else's
storefront.