How to Keep Bot and Internal Traffic Out of Your Shopify Conversion Data

TL;DR

Shopify started hiding bot sessions from its own reports on September 21 to 23, 2026, which moved conversion rates on stores that changed nothing. GA4 excludes known bots automatically and won't tell you how many. GA4's internal-traffic rule matches IP addresses, and a purchase delivered server-side has no staff IP in it to match. The ad platforms do get the shopper's real checkout IP, and we found no ad-platform setting that drops a received conversion by IP. So bot and staff browsing can be cleaned up with filters, and staff purchases can only be kept out by not sending them.

Key Takeaways

• Shopify's bot filter applies to sessions, conversion rates and visitor counts, only for data from October 7, 2025 onward, and older sessions aren't reclassified [2].
• Shopify's session change rolled out September 21 to 23, 2026; sessions now end after 30 minutes of inactivity instead of at midnight UTC, and conversion rate can move "even when your orders or sales haven't changed" [1].
• GA4's known-bot exclusion is always on: you "cannot disable known bot traffic exclusion or see how much known bot traffic was excluded" [3].
• GA4's internal-traffic rule is defined per web stream under Configure tag settings → Define internal traffic; the data filter that acts on it is created per property, and a property holds at most 10 data filters [4].
• An Active developer-traffic filter drops everything collected in debug mode [6]. With debug mode on for a live GA4 pixel, that includes every visitor and every purchase.
• Google Ads IP exclusions stop ads from serving to up to 500 addresses per campaign [8]. They don't touch conversions.
• WeltPixel Conversion Tracking has no IP, email, tag or test-order exclusion. Its one order-level exclusion covers admin and API orders, and that also removes subscription renewals, POS and marketplace orders.

What changed in Shopify's numbers on September 21?

Shopify rewrote how it counts sessions, and the conversion rate in Shopify Analytics moved with it. The rollout ran from September 21 to 23, 2026 [1]. Three changes matter here:

• Sessions are based on continued activity and end after 30 minutes of inactivity, instead of ending at midnight UTC [1].
• Some sessions without a page view now count, such as a customer going straight to checkout from a cart link [1].
• "Identified bot sessions are filtered out of session-related reports by default" [1].

Shopify's own note on the consequence: "When your session count changes, your conversion rate can also change, even when your orders or sales haven't changed" [1]. Historical data isn't reprocessed, so any chart that spans September 21 compares two counting methods.

The bot side has limits worth knowing before you lean on it. Shopify labels each online store session as human or bot, and supported reports carry a Human or bot session dimension and filter [2]. The classification is "designed to be conservative because it's better to miss some bots than incorrectly label real customers as bots", and it "applies only to new incoming data as of October 7, 2025" [2]. The page describes session reports. It says nothing about orders or about what third-party pixels receive.

If your Shopify conversion rate stepped up or down this week and nobody touched the store, check the date before you check the theme. Why Shopify Analytics and GA4 revenue never match covers the gap this widens.

Four filters, four delivery paths

A Shopify store running server-side tracking has four filters, run by three parties, each watching a different path.

The app's check has a defined scope. It looks for search, AI and social crawlers, SEO and uptime tools, headless and automation browsers and HTTP libraries, plus two automation signals from the browser itself, and when it finds one it skips the browsing events it sends to GA4 for that page. It was built for GA4 browsing events. The purchase path doesn't run it, because a completed order in Shopify is an order, whoever placed it.

Traffic you lost to ad blockers is the opposite problem to traffic you want gone, and it has its own guide: ad blockers and server-side conversion tracking on Shopify.

Why doesn't an IP rule catch a staff purchase?

Because the purchase never arrives from the staff member's browser, and the reason differs by destination.

GA4 first. The internal-traffic rule lives in the web stream's tag settings and matches the IP address of incoming traffic; Analytics then adds a traffic_type parameter that the Internal Traffic data filter excludes [4]. The Google tag in a staff browser sends storefront page views, so those get caught. The purchase is different. The app builds it from the Shopify order and sends it from its own servers through the Measurement Protocol, carrying the shopper's user agent and no shopper IP. Google documents the Measurement Protocol's IP field, ip_override, as the address "Google Analytics uses to derive geographic information" [7], and nothing more. There's no staff address on the purchase for the rule to match.

Run the arithmetic on an illustrative store. GA4 shows 10,000 sessions and 200 purchases, a 2.00% purchase rate. Staff account for 400 of those sessions and 8 test purchases, so the real customer rate is 192 out of 9,600, also 2.00%. Activate the internal-traffic filter and GA4 drops the 400 staff sessions but keeps all 200 purchases: 200 out of 9,600 is 2.08%. The filter made the number worse. It removed the browsing and left the buying.

The ad platforms get the opposite setup. Purchases sent to Meta, TikTok, Reddit, Snapchat, Pinterest, ChatGPT Ads and Klaviyo carry the shopper's real checkout IP from the Shopify order. Google Ads uploads carry no IP at all. We found no ad-platform setting that drops a conversion by IP after it's been received. The closest thing, Google Ads IP exclusions, blocks "all ads in that campaign" from the listed addresses, up to 500 per campaign, and the page says nothing about conversions [8].

On every destination, an IP rule can't remove a purchase; what you send is the only lever.

The debug-mode trap

GA4's developer-traffic filter is the one filter that can delete real revenue, and it takes two settings that each look harmless on their own.

Google describes the filter as removing "activity from internal developers who use debug mode", and once it's active, GA4 "will filter out any data collected from users when debug mode is enabled" [6]. Like every data filter, the effect is permanent [6].

In the app, GA4 debug mode is a setting on the GA4 pixel, off by default. Turned on, it marks every visitor's events: the Google tag's page views, the browsing events the app sends, and the server-side purchase all carry the debug flag. Our testing guide, linked further down, already warns that test switches on a pixel apply to real customers. The developer filter is what turns that into data loss. Leave debug on for an afternoon of checking in GA4 DebugView with an Active developer-traffic filter in place, and the whole store's GA4 data for that afternoon is gone, purchases included, with no way to bring it back.

Pick one. Either keep the developer filter off and use debug mode freely, or keep the filter Active and do your debugging against a separate test property.

How do you set up the filters that do work?

This cleans what filters can see; purchases come in the next section.

1. Shopify. In your Shopify reports, add the Human or bot session filter where it's supported [2], and mark September 21 to 23, 2026 on any conversion-rate chart you share [1].
2. Define internal traffic in GA4. Go to Admin → Data collection and modification → Data streams, open the web stream, then Configure tag settings → Show more → Define internal traffic, and add your office and staff IP addresses or ranges [4]. Each web stream has its own tag settings, so a property with several streams needs the rule on each.
3. Create the data filter in Testing. Under Admin → Data collection and modification → Data filters, create an Internal Traffic filter set to Exclude and leave it in Testing. An Active filter is permanent and only applies going forward [4][5], and the Testing-to-Active walkthrough is in the GA4 hostname filter guide.
4. Activate after a few days. A filter can take 24 to 36 hours to apply [4]. You get 10 data filters per property, internal and developer filters included [4], so don't spend them on one-off IPs.
5. Decide on the developer filter using the rule in the previous section.
6. For views you might want back, use report filters instead. Google's own advice is to use them "if you want to hide data from certain reports without permanently filtering out the data" [4].

What can the app exclude, and what can't it?

The app has no IP exclusion, no email or customer exclusion, no order-tag exclusion and no staff exclusion. The one order-level exclusion is admin and API orders: on the Plus plan it's a per-pixel setting, off by default, and on the free plans admin and API orders are skipped for every channel. The catch is what counts as admin. Anything that didn't come through the online store checkout qualifies, so the setting also removes subscription renewals, POS sales, Shop app and marketplace orders from that pixel. Draft orders your staff complete in the admin are excluded by it; a draft the customer pays through the invoice link is treated like a storefront order. A staff member buying through the storefront checkout isn't. Admin and POS order tracking on Shopify explains what you give up before you switch it on.

Test orders are the subject of how to test server-side conversion events without polluting live reports, including why nothing un-sends them. Two facts that guide doesn't carry: the app applies no Shopify test-order check at all, so a test order placed through the storefront is processed like any other order, and Shopify's sales reports leave test orders out ("Test orders aren't included" [9]). A storefront test order can therefore show up in GA4 and your ad platforms and never appear in the Shopify sales report you reconcile against.

FAQ

Does GA4's internal traffic filter remove purchases sent server-side?

Not through the IP rule. The server-side purchase reaches GA4 from the app's servers with no shopper IP, and Google documents the Measurement Protocol's IP field for location only [7]. Staff page views from the Google tag are removed; staff purchases stay.

Can I turn off GA4's bot filtering or see how much it removed?

No. Google says you "cannot disable known bot traffic exclusion or see how much known bot traffic was excluded" [3].

Did Shopify's bot filtering change my historical conversion rate?

No. Historical data isn't reprocessed by the September 2026 update [1], and bot classification only covers sessions from October 7, 2025 onward [2].

Why did my GA4 revenue disappear after I turned on debug mode?

Check for an Active developer-traffic filter. It drops all data collected in debug mode [6], and the app's GA4 debug mode applies to every visitor on that pixel, purchases included. The removal is permanent.

Send only the purchases you mean to send

WeltPixel Conversion Tracking skips its GA4 browsing events for detected crawlers and automation, keeps GA4 debug mode off until you switch it on, and on the Plus plan lets you exclude admin and API orders per pixel. Clean the traffic your filters can see, and decide what gets sent for everything else.

Sources

1. Shopify Help Center, session measurement update (rollout dates; bot sessions filtered by default; historical data not reprocessed), help.shopify.com/en/manual/reports-and-analytics/discrepancies/session-measurement-update, accessed September 28, 2026
2. Shopify Help Center, bot filtering (human or bot session labels; conservative classification; data from October 7, 2025), help.shopify.com/en/manual/intro-to-shopify/bots/bot-filtering, accessed September 28, 2026
3. Google Analytics Help, "Known bot-traffic exclusion", support.google.com/analytics/answer/9888366, accessed September 28, 2026
4. Google Analytics Help, "Filter out internal traffic" (10 data filters per property; permanence; 24 to 36 hours), support.google.com/analytics/answer/10104470, accessed September 28, 2026
5. Google Analytics Help, "Data filters" (filter types; no effect on historical data), support.google.com/analytics/answer/10108813, accessed September 28, 2026
6. Google Analytics Help, "Filter out developer traffic", support.google.com/analytics/answer/13296662, accessed September 28, 2026
7. Google for Developers, "Measurement Protocol reference" (ip_override), developers.google.com/analytics/devguides/collection/protocol/ga4/reference, accessed September 28, 2026
8. Google Ads Help, "Exclude IP addresses" (500 addresses per campaign), support.google.com/google-ads/answer/2456098, accessed September 28, 2026
9. Shopify Help Center, sales reports (test orders excluded), help.shopify.com/en/manual/reports-and-analytics/shopify-reports/report-types/default-reports/sales-report, accessed September 28, 2026