The most likely explanation isn’t edge filtering — it’s consent gating, and the geography in your post points straight at it.
The store’s Analytics data preference setting (Settings → Customer privacy) controls whether Shopify records analytics before or after consent. Set to “collected after consent,” Shopify never creates a session for a visitor who hasn’t accepted the banner, while a third-party script that fires on page load records it anyway. Other merchants have traced session undercounting to exactly this setting — accurate numbers with “collected before consent,” undercounting with “collected after consent.” London and Italy are both consent-banner jurisdictions, so VPN exits there would be disproportionately affected.
Second factor: Shopify’s tracking runs client-side through its trekkie script. Privacy browsers, ad blockers, and hardened or emulated Android builds block it at higher rates than a generic first-party tag. “Emulated Android devices with atypical browser engines” is the exact profile that blocks it.
Third: the multi-store-from-one-IP observation doesn’t indicate cross-store filtering. Shopify sessions are scoped per shop domain via first-party cookies, so those would be independent sessions regardless.
On your direct question — yes, Shopify does drop traffic at the edge before a session record exists, separate from the reporting-level filter shipped in October 2025 (the “Human or Bot session” filter and dimension in Analytics reports). But the criteria aren’t documented and almost certainly never will be, since publishing detection heuristics makes them trivial to evade. As an analytics vendor you can’t replicate the filtering — only reconcile against it.
Concrete test: flip the consent preference in a test store and re-measure, with that as the only variable, segmented by country. If the discrepancy collapses for EU/UK traffic, it was consent, not edge filtering. Worth also asking at community.shopify.dev — that’s where platform engineers actually read.
-–
2. Should I filter sessions by duration when checking conversion rate
Should I filter sessions by duration when checking conversion rate
Answer:
Use it as a diagnostic, never as your reported number.
Is it correct? The moment you change the denominator, you break comparability with your own history and with every external benchmark. Your 2% isn’t a “truer” conversion rate; it’s a different metric measuring a different population. Report the 0.9%, keep the filtered view as a second lens.
Does Shopify include them? Yes. Any session Shopify records enters the denominator unless you filter it. The human/bot filter catches what Shopify’s classifier is confident about; sub-second sessions that survive it are the ones it wasn’t confident about.
What those sessions actually are — usually a mix of four things: bot traffic that evaded classification, link prefetching (many themes and Chrome’s speculation rules preload pages nobody viewed), ad-platform click verification, and genuine accidental taps on mobile ad units. Only the last is a real person, and they were never going to convert.
The useful move is to treat the gap itself as the metric. Track the ratio of sub-1-second sessions to total, week over week. Stable ratio means structural noise you can ignore. Rising ratio means a traffic-quality problem — then segment those sessions by referrer and country, because they nearly always cluster in one or two ad placements. Audience networks and display partners are the usual culprits. That’s actionable in a way the conversion rate isn’t.
For funnel diagnosis specifically, lean on session-to-add-to-cart rate broken out by landing page and channel. It’s far less sensitive to junk arriving at the top, so the signal survives.
One caution: the duration filter also removes real people who bounced instantly for real reasons — slow load, wrong expectation from the ad, broken mobile layout. Those are genuine problems, and filtering them out hides them.
-–
3. Feature request — Shopify Market Catalog prices in Product Listings
https://community.shopify.com/t/feature-request-shopify-market-catalog-prices-in-product-listings/6…
Answer:
There’s no native way to set market catalog prices from the product page. Create product → navigate to Markets → Catalogs → find it again is currently the only manual path. Three ways to make it bearable at 4,500 products:
CSV, for bulk work. Catalog pricing and product availability can be managed in bulk via CSV from Markets → Catalogs — select a catalog, click Export, then export all or selected catalogs. Edit and re-import. This is the practical answer if you create products in batches.
The Admin API, if new products are constant. The `priceListFixedPricesAdd` mutation writes fixed prices to a price list, accepting up to 250 prices per request and acting as an add-and-replace operation — an existing fixed price for a variant gets replaced. A small private app subscribed to the `products/create` webhook could set every market’s price at creation time from a metafield or lookup table. At your volume this is the real fix — a few days of dev work against permanent manual labour.
Bulk import apps — Matrixify and similar handle market/catalog pricing columns if a custom app isn’t appealing.
On where to file it: there’s no public voting board. Tagging the post `product-feedback` here is the closest thing, and Shopify’s product teams do read those threads. Raising it through support and asking for it to be logged also works, slowly.