Shopify Changes How It Counts Sessions in Analytics

The rollout ran from 21 to 23 September 2026 and reached stores in stages, so the day a merchant sees their numbers shift depends on when the update landed on their account. Nothing about the underlying trading has changed. What has changed is the definition Shopify applies when it decides whether a piece of activity counts as a session at all, and whether that session belongs to a human being or to a bot.

The practical consequence is narrow but sharp: sessions, conversion rate, bounce rate and the rest of the session family are now calculated on a different basis from the figures sitting in last month's reports. Orders, sales and customer counts are untouched, which is the detail that tells you whether a shift in the dashboard is real or definitional. Shopify has published a fuller explanation in its Help Centre guidance on sessions and conversion rate.

How it works

There are four mechanical changes underneath the update. First, a session is now defined by continued customer activity rather than being cut off at midnight Coordinated Universal Time. Previously a visit that carried on past midnight UTC was recorded as two separate sessions. It is now recorded as one. Second, a session ends after 30 minutes of inactivity, which is the conventional web analytics timeout and brings Shopify into line with how most other tools draw the boundary.

Third, some sessions that never included a pageview are now counted. The example Shopify gives is a customer who goes straight to checkout from a cart link, which is a genuine shopper journey that the old measurement quietly discarded because no product or collection page was ever loaded. Fourth, and the change most likely to move the numbers, identified bot sessions are filtered out of session-related reports by default.

That bot filtering is not uniform across the admin. In reports that support the Human or bot session filter you can switch it to include bot traffic if you want to see the unfiltered picture. Some surfaces do not offer the control at all: the Home page and Live View always show filtered data and the filter cannot be adjusted. Search and product recommendation reports filter identified bots automatically and do not display the filter either. One limit matters for anyone looking backwards: bot classification only applies to sessions recorded from 7 October 2025 onwards, so periods earlier than that cannot be filtered on the same basis.

Historical data has not been deleted or reprocessed. The stored records are the same records they were last week. What can differ is how a report chooses to display them once bot sessions are excluded by default, which is why an old month can read differently today without anybody having rewritten it.

Examples and use cases

Take a store that has been picking up a steady stream of automated traffic, which is most stores of any size. Its session count will fall, because sessions that were previously counted are now classified as bots and dropped from the default view. Because conversion rate is orders divided by sessions, a smaller denominator with the same numerator produces a higher conversion rate. That store will appear to have improved, on a week where nothing about its trading or its marketing changed at all.

Now take a store running a lot of cart-link traffic, which covers abandoned-cart emails, SMS recovery flows and paid campaigns that drop shoppers straight into checkout. Its session count will rise, because those pageview-free journeys now register. The same arithmetic runs the other way and the conversion rate falls. Nobody has done anything wrong, but a marketing report produced in early October will show a decline that has no cause in the business.

The midnight change has a particular flavour for UK merchants. In September the UK is on British Summer Time, an hour ahead of UTC, so midnight UTC falls at one in the morning here. A shopper browsing from half past midnight to a quarter past one used to generate two sessions and now generates one. Stores with genuine late-night trading, and late-evening is a well-established peak for UK ecommerce, will see a slightly lower session count for that reason alone. The effect is small relative to bot filtering, but it moves in the same direction and compounds with it.

What this means for UK merchants

The immediate issue is reporting, not trading. Any period-over-period comparison that straddles 21 September 2026 is no longer like for like on session-based metrics. That catches the September board pack compared against August, and it catches every monthly retainer report going out in the first week of October. If a client reads a conversion-rate movement in that report as a result, they will be reading a measurement change as a commercial one.

It also catches experiment results. Any conversion rate optimisation test, landing-page change or paid media campaign whose before-and-after window spans the update has a confound in it that has nothing to do with the work. The honest response is to say so in the report, mark 21 September as a baseline break on the chart, and judge the test against a comparison period that sits entirely on one side of the line. Where a result genuinely matters, orders and revenue are the metrics to lean on, because those are unaffected.

Year-on-year work needs more care than month-on-month. The 7 October 2025 boundary on bot classification means a comparison of September 2026 against September 2025 cannot apply the same filtering to both halves, so the older period carries bot traffic the newer one does not. Black Friday and the Christmas peak are more forgiving, since November and December 2025 both sit inside the classification window, but the filtering basis still differs across the update itself. For anyone judging organic performance on a Shopify store from acquisition reports, the sensible move is to rebuild the baseline now, in the quiet weeks before peak trading, rather than discovering the discontinuity in the middle of a Black Friday post-mortem.

Practical considerations

Shopify's position is that most merchants need to take no action, and for a standard Liquid storefront that is right. The exceptions are technical. Stores that received a message about their storefront may have a session cookie rotation problem to resolve, Hydrogen storefronts have a tracking cookie migration to complete, and custom headless setups have their own migration path. On headless builds the available filters and session behaviour can differ depending on how storefront analytics were implemented in the first place, so a headless store should not assume its reports behave like the documentation describes. If you are unsure which of these setups your store runs on, whoever handled your Shopify store build will know, and it is worth confirming before the October reports go out.

Third-party apps are the quieter risk. Any app that reads session data from Shopify Analytics inherits the new basis, so an app's own dashboard can move for the same reason the admin did. Shopify's advice is to ask the app developer how the app uses session metrics rather than guessing, which is sound, because the answer varies a great deal between apps.

Custom reporting deserves a deliberate look. Anything built on the sessions or searches datasets will return different results across the 21 September boundary, and the report editor may show a notice when a query crosses that date. This is worth pairing with any automation that queries those datasets on a schedule, including the ShopifyQL work that became available when Shopify Flow gained a ShopifyQL action for analytics, since an automated query will keep running happily and simply return numbers on a new basis without anyone being told. The failure mode throughout this update is the same one: nothing breaks, nothing errors, and the figures just quietly mean something slightly different from what they meant a fortnight ago.

For a related Analytics change that landed a week later, see our note on category metafields arriving in Shopify Analytics, which lets sales reports be grouped and filtered by product attributes such as colour and material.

FAQ