What each install can collect

StorePilot has three ways in, and they do not all collect the same things. This page is the whole table, and the reason for every gap.

Your dashboard already applies it: a module this site's install cannot fill is not shown in the sidebar, and opening its address directly gives you a sentence explaining which install would give it to you.

The table

Module	WordPress plugin	Script tag	Node SDK
Errors	✅	✅	✅ (your server's, only)
Pageviews and analytics	✅	✅	—
Visitors	✅	✅	—
Leads (forms and carts)	✅	✅ (no cart contents)	—
Session recordings	✅	✅	—
Heatmaps	✅	✅	—
Surveys	✅	✅	—
Conversion funnels	✅	✅	—
Orders, carts, products	✅	—	—
AI digest	✅	✅	—
Uptime monitoring	✅	✅	✅

A Shopify store uses the script tag — there is no StorePilot app for Shopify — and loses one more thing there: its checkout runs on Shopify's own pages, where no script of ours loads. Shopify has the details.

Why orders need the plugin

Orders are money, and money arrives under your site's secret key — the credential that lives on your server and is never printed into a page.

The loader script authenticates with your public key, which a browser holds in plain sight. A public key names a site; what decides whether we believe it is the Origin header, which the browser sets and page script cannot forge. That is a good enough answer for "which site is this page on" and not for "this shop earned £412 today": anybody who can read a public key out of your page source could otherwise post invented revenue into your dashboard.

So there is no browser-postable order route, deliberately, and the same applies to the product catalogue. This is not a gap we plan to close for the script tag, on Shopify or anywhere else: a page cannot vouch for money.

Everything else on a script-only site works exactly as it does anywhere.

Why a backend install collects only errors

@store-pilot/node runs inside your own service. There is no browser, so there is no page view, no click, no form, no recording and no survey — not as a restriction but as a fact about where the code is running.

Uptime is the exception, and for the same reason: it is an outside probe of an address you give us, so it needs no install at all.

What decides which install you have

Not what you picked in the setup wizard — that only chooses which instructions you are shown. It is decided by the first request that actually authenticates as your site:

• the WordPress plugin fetching its configuration ⇒ plugin
• the loader script posting from your page ⇒ script
• @store-pilot/node reporting an exception ⇒ server

A site that has never been reached shows you everything, because at that point nobody — including us — knows which one it is going to be.

Two of those are sticky on purpose. A site seen as plugin is never downgraded, because the plugin is the only install we can ask to delete its own stored files. And a site seen as server is never reclassified, because the commonest request a headless service makes without its SDK header is its own build pipeline uploading source maps.