The two-layer stack many stores run
A common pattern: keep Google Analytics (or similar) for familiarity, and add a lightweight privacy tool alongside it — pageviews, referrers, a cleaner banner story. That is a reasonable hygiene layer. It is not the same as store analytics.
General-purpose tools — even good ones — are built around pages and sessions. E-commerce depth (product → cart → checkout → revenue as native objects, cart-abandonment visibility, channel-to-order linkage) is bolted on, tier-gated, or absent. Running two general layers does not add store depth; it adds another traffic lens on the same abstraction.
What "store-native" means in practice
Store-native analytics treats the buying journey as the default unit of analysis:
- Products and variants are first-class, not custom events you hope survive a theme change
- Cart and checkout are stages in a funnel, not inferred from URL patterns
- Revenue ties to channels — including AI referrers — without stitching a separate e-commerce module
- Privacy is structural (cookieless-by-design), not a configuration mode you enable after legal review
Qusto is built for that job: privacy-first, EU-hosted, open-core so the privacy claim is verifiable, managed so you do not run the infrastructure.
Why "alongside GA4" is still a valid entry
You do not have to choose on day one. A parallel install — Qusto alongside your existing analytics — is low-risk: add the script, change nothing else, compare what each tool shows. That is especially useful when your team treats peak season as a freeze on vendor swaps. Store-native depth becomes the reason to promote Qusto from second lens to first-class stack when you are ready.
Run both, and let your assistant reconcile them
Google publishes an official, read-only GA4 MCP server. Qusto ships its own first-party MCP server too — qusto-mcp on npm, also read-only, EU-hosted, no PII. Configure both alongside each other in Claude, Cursor, or any MCP-capable assistant, and ask it to compare what each source reports for the same period. Qusto's job in that conversation is simple: be the number that came from your store's own order record, not a browser tag.
Three prompts to try once both are configured:
- "Compare total revenue in GA4 and Qusto for the last 30 days — do they agree?"
- "In Qusto, how many orders came from the store's own order record with no matching browser session?"
- "Which channels does GA4 show driving traffic that Qusto's order data doesn't confirm converted?"
See the MCP setup docs to add Qusto's server alongside Google's.
client_id — GA4 would either invent a new user for each one or drop them into "Unassigned," making your GA4 reporting worse, not better. Reconciliation happens by asking an assistant to compare both sources side by side, never by writing into either one.
What general-purpose layers typically cannot answer
Even running alongside GA4, a general traffic layer often cannot answer operator questions like:
- Which channel drove orders, not just sessions, after consent decline thins GA4's view?
- Where in the checkout does the journey thin — by step, by device, by market?
- What is revenue by geography, not just visitor counts on a map?
Store-native analytics exists to answer these directly — product, cart, checkout, and revenue as the default view, not an add-on module.