Why Is There Bot Traffic in Your Shopify Analytics?

Because the bots that matter don’t announce themselves. Most analytics tools filter the ones that do: search engine crawlers say who they are, and they are easy to drop. The expensive bots are scrapers watching your prices, rendering services that load full pages in a real browser engine, monitoring tools and link checkers. They run JavaScript, fire page views, and look like a visit.

They also never buy. So every bot session lands at the bottom of every rate you care about. Sessions go up, conversion rate goes down, add-to-cart rate goes down, and a collection that bots happen to crawl hard looks like it is failing.

This came to a head in early October 2026. A merchant sent us a GA4 report showing a surge in sessions that went nowhere. We traced it to a single rendering farm: the same browser build every time, a screen of exactly 1800×1125, and an outer browser window of 1808×1210. That window is bigger than the screen it runs on, which a real browser can’t do.

It wasn’t one store’s problem. Because we see every store we serve, we could follow that one fingerprint across the network, day by day.

One merchant looking at their own analytics sees a traffic spike. Looking across the network, it is plainly one bot.

What Does Bot Traffic Do to Your Conversion Rate?

It sinks it. A bot session adds to the denominator and never to the numerator. Take one fashion store from that week: bots were about 30% of its sessions. With them counted, its collection conversion rate was 0.27%. With them removed, 0.39%. Its cart rate moved from 1.30% to 1.85%.

The same goes for every comparison you make. If one collection gets crawled twice as hard as another, its conversion rate looks worse for reasons that have nothing to do with the products on it. Removing bots makes collections comparable again.

What Changed in Dynasort Insights?

Every storefront session Dynasort measures now gets one of three labels, and Insights count the first two by default.

A fingerprint we identify as a bot today is also removed from the days it visited before we caught it, so Insights get cleaner after the fact, not only going forward.

How Does Dynasort Tell Shopping Agents From Bots?

By what they do at the cart. Shopping agents are new, and they are customers. When someone asks an assistant to find and buy a pair of running shoes, the assistant visits your store, browses a collection, and adds to cart on that person’s behalf. Filtering those visits out would hide real demand. So the hard part of this project wasn’t spotting automation. It was telling automation that shops from automation that doesn’t.

Our rule is short: agents shop, bots don’t. An agent exists to buy something for a person, so over time its traffic produces carts and checkouts. A bot never does.

A single store can’t apply that rule, because it only sees its own traffic. We can. Every day we group sessions by device fingerprint across every store we serve and compare what each fingerprint did with what it should have done at those stores’ normal add-to-cart rates.

The network test sits alongside four other signals:

• Declared identity. Crawlers that name themselves are bots. Assistants that fetch a page live for a person, and say so, are agents.
• Signed agent requests. Some agent operators sign their requests using Web Bot Auth, so we can check who sent them. A signature from a known shopping-agent operator marks an agent.
• Impossible browser geometry. A browser window bigger than its screen, a window with no screen, or the square screens headless browsers ship with. We allow for rotated tablets and the quirks of phone browsers.
• Hosting networks. People rarely shop from a data center. A session from a hosting network with almost no activity counts against it; the same session with a cart counts as a shopping agent.

One honest limit: an assistant that hides what it is and browses without ever buying looks exactly like a scraper, so we count it as a bot. It produced no shopper outcome, so leaving it out doesn’t hide a sale.

What Will You See in Insights?

Cleaner numbers, a line telling you how much was left out, and a setting if you want a different view. There is nothing to turn on.

• Your numbers count shoppers. Sessions, conversion rate, add-to-cart rate, exits and bounces now count people and shopping agents.
• A marker on your timeline. The day bot filtering started is marked, so a step up in conversion rate there is easy to read.
• A setting if you want a different view. Settings > Traffic in Insights offers Shoppers (the default), People only, or All traffic, with your last seven days by type shown before you pick.
• Sorting doesn’t change with the setting. Your sort order never used bot visits and never will. The setting only changes what Insights display.
• A flag for traffic that doesn’t add up. If a collection’s sessions at least triple week over week while its cart rate falls by two thirds or more, Insights show “Traffic jumped without carts following”. That is the shape of a bot we haven’t identified yet, and it is worth a look.

Does Dynasort Store Shopper IP Addresses?

No. To recognize hosting networks we look at where each visit comes from, and we built that so we never keep the address itself. From each visit we keep the country, the network owner (for example, a home internet provider or a hosting company), a truncated address, and a one-way hash of the full address made with a key that changes every day and is deleted soon after. That is enough to spot one machine sending thousands of sessions today, and not enough to follow a person from one day to the next.

Country and network data come from IP Geolocation by DB-IP, licensed under CC BY 4.0.

Frequently Asked Questions

Does Dynasort count bot traffic in Insights?

No. Since October 13, 2026, Dynasort Insights leave bot sessions out by default. Sessions, conversion rate, add-to-cart rate and every other Insights number count people and shopping agents only. You can switch to People only or All traffic in Settings > Traffic in Insights.

Does bot traffic affect how Dynasort sorts my collections?

No. Dynasort sorting never uses bot visits, whatever you pick in the Insights traffic setting. Product views, cart adds and conversion rate used for sorting always come from people and shopping agents.

What is the difference between a shopping agent and a bot?

A shopping agent is an assistant that browses and buys on behalf of a real person, such as ChatGPT’s agent. A bot is a crawler, scraper or page-rendering service that never buys. Dynasort counts shopping agents as shoppers and leaves bots out. The short rule: agents shop, bots don’t.

How does Dynasort tell bots apart from shoppers?

Dynasort sees every storefront it serves, so it judges each device fingerprint by its behavior across the whole network. A fingerprint with many sessions and zero carts, where those stores’ normal rates would predict many carts, is a bot. Dynasort also uses declared identities, signed agent requests (Web Bot Auth), browser windows bigger than the screen they run on, and hosting-network signals.

Why did my conversion rate go up in Dynasort Insights?

Because bots no longer pad the session count. Your orders and carts did not change; the number they are divided by got smaller and more honest. At one fashion store where bots were about 30% of sessions, collection conversion rate moved from 0.27% to 0.39%. The Insights timeline marks the day bot filtering started.

Are older Insights days filtered too?

Days from October 6, 2026 on are filtered. Earlier days stay as they were, and the Insights timeline marks when filtering began so the change is easy to read.

Does Dynasort store shopper IP addresses?

No. Dynasort never stores a shopper’s raw IP address. It keeps the country, the network owner, a truncated address and a one-way hash that changes every day. Location data comes from DB-IP Lite, licensed CC BY 4.0.

Can a real shopper be counted as a bot by mistake?

A person who adds to cart or checks out is counted as a shopper unless the visit also carries strong automation evidence, like a declared bot identity. The one honest gap: an undeclared assistant that browses and never buys looks exactly like a scraper, so it is counted as a bot. It produced no shopper outcome, so leaving it out does not hide a sale.

The short version: the same recipes that already rank your collections and your search results can now pick and rank the products in your “You may also like” sections. On your product pages, in your cart, on collection pages, on your home page, and on the one surface almost nobody merchandises: the page your customer sees right after paying.

The problem with most recommendation widgets

Most recommendation apps are a black box. You install them, they show something, and you hope it fits. You cannot see why a product was recommended, you cannot tell the widget that your margin matters, or that sold-out sizes should sink, or that the new drop should get a push this week. The logic that runs the most valuable slots on your store is the one piece of merchandising you cannot merchandise.

Dynasort has always taken the opposite view. A recipe is a ranking you can read: real signals with weights you control. Recent sales, inventory depth, newness, margin, your own custom attributes. If you can explain your merchandising strategy out loud, you can write it down as a recipe. Recommendations now run on exactly that.

Powered by your own store’s data

Alongside the merchandising signals you already know from collections, recommendation recipes add seed-aware signals: bought together, viewed together, and added-to-cart together, mined nightly from your own orders and browsing sessions. Plus tag similarity, shared collections, same product type, same vendor, and price proximity, so recommendations stay on-brand even before the purchase history piles up.

Every store already has ready-made recipes waiting: Customers Also Bought, Bestsellers You May Like, Trending Now, and High-Value Picks. Use them as they are, or clone one and make it yours. They are ordinary recipes, so every weight is visible and editable.

It looks like your store, not like a widget

Recommendation cards support badges, color swatches, compare-at pricing, ratings, hover images, and quick add to cart, all configurable per placement from the Dynasort admin, with a live preview beside every setting. Headings localize to your shopper’s language automatically. And every serve is tracked, so you can see exactly how many recommendations each surface showed, what got clicked, and what got added to cart, per recipe.

Getting started takes two steps

1. Pick a recommendation recipe and bind it to a placement on the Recommendations page in the Dynasort admin.
2. Add the Dynasort app block where you want it in your theme editor. For the post-purchase surface, add the block in the checkout editor. No code, and just as easy to undo.

Rather do it together? Book a free setup session and we will configure it with you on a screen share, recipe tuning included.

Launch week

This is day one of a week of recommendations content. Tomorrow we open the hood and show exactly how a recommendation gets picked and ranked. Wednesday is the data: what a million real orders say about multi-item baskets, and why the second product view is the whole game. Thursday is a practical guide to recipes, placements, and card settings.

Install Dynasort free for 30 days or read the recommendations docs. Already a Dynasort merchant? Recommendations are included on your plan right now, and the setup session is free.

Every search is really two jobs

When a shopper types “linen shirt”, two separate questions need answering. First: which products match? That is membership, and it is genuinely hard. It means handling typos, applying synonyms, and respecting any filters the shopper has applied. Second: in what order should the matches appear? That is ranking, and it is a business question, not a text question.

We split the two jobs cleanly. Shopify’s search engine keeps the membership job: it decides which products match a query, including synonyms, typo handling, and the filters shoppers use to narrow down. Dynasort takes that matched set, scores every product with your active search recipe, and re-orders it. Then we render the results grid and the predictive dropdown in your theme. That is search re-ranking, and it is all we do.

What a search recipe actually scores

A search recipe scores every matching product on the merchandising signals you choose and weight. Out of the box that includes recent sales over the last 7 and 30 days, all-time sales, inventory depth measured in variants in stock, newness measured by the age of the newest variant and days since published, on-sale status, sold-out status, margin, and price.

Then there are custom attributes: any product data you can express, you can rank by. Tags, metafields, even a spreadsheet upload. A common recipe choice is sold-out demotion, which pushes sold-out items to the bottom of the results instead of hiding them, so shoppers still find the product but never hit a dead end in slot one.

What we deliberately did not build

We could have built our own search engine with its own index of your catalog. We chose not to, and we consider that the best decision in the whole product. Here is what not replacing Shopify’s engine buys you:

• No index drift. There is no second copy of your catalog to sync, so a product can never exist in one engine and be missing from the other. No sync jobs, no migration, nothing to babysit.
• Your synonyms keep working. Anything you configured in Shopify’s free Search & Discovery app flows through automatically.
• Your filters keep working. The filter definitions you set up in Search & Discovery render on the Dynasort results page and narrow results exactly as before.
• Nothing to unlearn, and nothing risky to undo. Shopify keeps answering “what matches” the way it always has, so removing Dynasort simply returns you to the default order. No re-indexing, no rebuild.

Fast, and never stale

Both surfaces are built for speed. The full results page re-ranks the complete matched set. The predictive dropdown re-ranks a smaller candidate set, because as-you-type has to feel instant.

Ranked results are cached briefly, about 15 minutes per query and recipe, so warm queries serve in tens of milliseconds. The product cards themselves, price and stock included, are always built fresh, so a shopper never sees a stale price or a phantom “in stock”. And because the cache is keyed to your recipe version, editing a recipe takes effect immediately. Change a weight, run the search again, see the new order.

Honest caveat: new stores start plain

Re-ranking is only as sharp as the data behind it. On a brand-new store with little sales history, many products score the same, and tied scores need a tie-breaker. You can choose “Shopify relevance” as that tie-breaker, so on thin data the order gracefully degrades toward Shopify’s default instead of something arbitrary. The system is designed to degrade gracefully, and it gets sharper as your sales and inventory data accumulate.

Every serve is measured

Every search Dynasort serves is logged: which recipe served it, what was shown, what got clicked, and what got added to cart. That powers per-recipe performance stats, and it powers A/B testing, built into Dynasort, where two recipes run head-to-head on live traffic so you can see which order actually sells.

Setup is three clicks, not a project

Because there is no index to build, setup is short: activate a search recipe, connect your storefront with one click, and add the app block plus the live search embed in your theme editor. No code. Rather do it on a screen share? Book a free setup session and we will configure it with you.

Install Dynasort free for 30 days or read the search docs. Tomorrow: the data, what fleet-scale search behavior says about default ordering, and how Dynasort Search compares with the other search platforms you have heard of.

The short version: the same recipes that already rank your collections can now rank your search results and your predictive search dropdown. Shopify keeps deciding which products match a shopper’s search. Dynasort decides the order they come back in.

The problem with default search order

Type “hoodie” into most Shopify stores and the results come back ranked by text relevance: how well each product’s title and description match the word “hoodie”. Relevance is great at finding the right products. It is terrible at ordering them, because it knows nothing about your business. It does not know which hoodie is your best seller, which one is sold out in every popular size, which one just dropped, or which one carries your margin.

So your search results page shows a sold-out product in slot one and your best seller on page two. Shoppers who search are your highest-intent visitors, and default ordering treats them worse than any other page on your store.

What Dynasort Search does

Dynasort Search re-ranks two surfaces: the search results page and the predictive dropdown that appears while a shopper types. Both are driven by a search recipe, the same kind of recipe you already use on collections, with signals like recent sales, inventory depth, newness, margin, and your own custom attributes.

The part we are most proud of is what it does not do. Dynasort Search does not replace Shopify’s search engine, and that is a deliberate choice. Shopify still decides which products match a query, which means:

• Your synonyms keep working. Anything you set up in Shopify’s free Search & Discovery app flows straight through.
• Your filters keep working. The filter definitions you configured in Search & Discovery render right on the Dynasort results page and narrow results exactly as before.
• There is no second search index to sync, no migration, and no risk of a product existing in one engine but not the other.
• Zero performance impact on your store, theme, and search results.

If a shopper searched your store yesterday, the same search works today. The only thing that changes is that the order finally makes business sense.

It looks like your store, not like a widget

Result cards support badges, color swatches, compare-at pricing, ratings, hover images, and quick add to cart, all configurable from the Dynasort admin, and all styled to be overridable with your own theme CSS. The predictive dropdown matches your theme’s look. Every serve is tracked, so you can see exactly how many searches Dynasort handled, what got clicked, and what got added to cart.

Getting started takes three steps

1. Activate a search recipe in the Dynasort admin. Every store already has ready-made defaults waiting, including Relevant & Popular and In-Stock Bestsellers.
2. Connect your storefront with one click on the Search page.
3. Add the Dynasort Search app block in your theme editor and toggle the live search embed. No code, and it is just as easy to undo.

Rather do it together? Book a free setup session and we will configure it with you on a screen share, recipe tuning included.

Launch week

This is day one of a week of search content. Tomorrow we will open the hood and show exactly how the re-ranking works. Wednesday is the data: what fleet-scale search behavior says about default ordering, and how Dynasort Search compares with the other search platforms you have heard of. Thursday is a practical guide to getting the most out of search recipes and result cards.

Install Dynasort free for 30 days or read the search docs. Already a Dynasort merchant? Search is included on your plan right now, and the setup session is free.

Starting now, Dynasort ranks your products everywhere shoppers decide what to click next:

Search re-ranking. Shopify decides which products match a search. Dynasort decides which ones deserve the top of the page. Your search results and your live-search dropdown are re-ranked on every request by the same recipes you already use for collections: real sales, real clicks, real margin, not just keyword matches. Here is why that matters: in 188,000 real storefront search clicks we analyzed, fewer than a third went to the first result, and nearly half went past the top three. Shoppers are digging for products that should have been in front of them.

Product recommendations. A “you may also like” that actually knows. Ranked rows like Customers Also Bought, built from your store’s own purchase patterns, placed anywhere in your theme: product page, cart, home page, or custom placements. Add the block in your theme editor, bind a recipe, done.

Post-purchase offers. The order confirmation page is the one page every buyer sees, and most stores show nothing there. Dynasort serves a ranked offer the moment the order completes.

Ranked live, measured honestly

Search and recommendations rank live on every request. Every serve is measured: you see serves, clicks, adds, and checkouts per recipe, right next to the collection insights you already have. If a surface is not earning, the numbers will tell you.

On every plan, including yours

All three surfaces are live today on every Dynasort plan, with a monthly serving allowance sized to your tier. Nothing you have configured changes; the new surfaces are additive. Open the app and you will find a Search page and a Recommendations page waiting, each with seeded recipes so you can activate in minutes:

1. Search: pick a recipe, click Connect storefront, add the search block.
2. Recommendations: bind a recipe to a placement, add the Dynasort block where you want the row.
3. Post-purchase: bind the post-purchase placement, add the extension in checkout settings.

The docs walk through every step: https://docs.dynasort.io/

The same promise, three more places

Shopify decides what shows up. Dynasort decides what shows up first. That has been true for your collections since day one. From today it is true for search, recommendations, and the thank-you page too.

Install Dynasort free for 30 days

Read the docs

Reference version of this post, with the full click data and methodology: Where Storefront Search Clicks Land

That’s the point, but it has a cost. Once things work, nobody looks at them again. And stores change: catalogs grow, traffic shifts, a collection that converted well in March quietly stops converting in June. The data to catch all of this has been sitting in your Insights the whole time. Someone just has to read it every week.

Now something does.

What it is

Weekly Recommendations is a new card on your Dynasort dashboard, included on every paid plan. Every Monday morning it reviews your store’s own data and posts 3 to 6 prioritized recommendations: specific, quantified, and each linked to the exact place in Dynasort where you act on it.

Not “improve your product pages.” More like: “This collection drew 8,500 sessions in the last 28 days but converts at a third of your store average, and it still runs your generic default recipe. Here is the recipe that’s outperforming everything else. Consider assigning it.”

What it looks at

Each week’s review covers your last 28 days and how they compare to the 28 before, including:

• Enabled collections converting well below your store average, ranked by traffic so the highest-impact fixes come first
• Collections whose conversion or revenue dropped sharply this week versus last
• Enabled collections with no recipe assigned, and high-traffic collections still on the default recipe
• Recipes that haven’t been touched in months while their collections decline
• Your best-performing recipe, and the laggard collections that aren’t using it
• Collections where shoppers add to cart normally but complete purchase far less than average, which usually points to price, shipping, or stock rather than sorting. When that’s the story, it says so.
• Plan features you already pay for but aren’t using, like A/B testing, suggested only when your data indicates they’d help
• Tracking anomalies. In our first week, it flagged two stores whose orders mostly bypass the online storefront, which makes conversion look artificially low. Knowing that is worth more than any sorting tweak.

Every number it quotes is your own, pulled from the same Insights data you already see in the app. It cannot invent statistics and it cannot link to things that don’t exist in your store. If your store is new and doesn’t have enough traffic yet, it says so and waits.

It learns what you want

Every recommendation has three controls: mark it done, dismiss it, or rate it with a thumbs up or down. That feedback feeds the next week’s review. Dismissed recommendations don’t come back unless the underlying number gets meaningfully worse. Thumbs tell it which categories of advice you want more of and which to drop.

And it writes in your language. If you run your Shopify admin in German, Czech, Hebrew, or any of the other languages Dynasort supports, the recommendations arrive in that language, quoting revenue in your currency.

What it costs

Nothing extra. Weekly Recommendations is included on all paid plans, from Basic up. There’s nothing to install or configure: if you’re on a paid plan, it’s already on your dashboard.

If you’re evaluating Dynasort, every paid plan starts with a 30-day free trial.

Start your free trial or book a demo.

A typical collection might convert a handful of times a week. That’s not enough signal to confidently rank forty products against each other — you’d be sorting on noise. So merchants either wait for sales data to slowly accumulate, or they sort on something else and hope.

Meanwhile, shoppers are voting constantly, with a much faster signal: what they click. The new Most Clicked Products attribute turns that signal into sort order. And it does something no Dynasort attribute has done before.

### Every collection, its own ranking

This is the first Dynasort attribute that scores differently in every collection, even when those collections share the same recipe.

That’s worth sitting with for a second, because most “sort by popularity” features treat popularity as one store-wide number. Every collection inherits the same global list. But the same product can be a star in one collection and wallpaper in another, and a single popularity score can’t capture that.

Here’s a concrete example. Collection X and Collection Y both run your “Engagement” recipe. In Collection X, Product A is the most-clicked item. In Collection Y, Product B leads. With Most Clicked Products in the recipe, Product A rises to the top of X while Product B rises to the top of Y — automatically, from that one shared recipe. You don’t build two recipes. You build one, and each collection adapts to its own audience.

### How the scoring works

The merchant picks two things: a timeframe (24 hours to 90 days) for the click-counting window, and how many top products earn points (default 10). The collection’s click leader gets the attribute’s full point weight, second place gets a bit less, and so on down to the last qualifying spot. With the default top 10, first place earns 100% of the points, second earns 90%, sliding to 10th at 10%. Everything below the top 10 earns nothing from this attribute.

Crucially, points scale by rank, not by raw click counts. This is a deliberate design choice, and it solves a real problem.

Raw clicks vary wildly between collections. A niche collection’s leader might get 40 clicks in a month while a flagship collection’s leader gets 4,000. If you scored on raw counts or fixed thresholds, you’d have to tune the attribute differently for every collection, and a single runaway product could flatten all the meaningful differences among everything below it. Rank-based scoring sidesteps all of that. It behaves identically in the niche collection and the flagship, with nothing to configure per collection, and the relative ordering stays meaningful no matter the absolute volume.

### A trending collection that maintains itself

As a Managed Collection condition, the attribute (there called Product Clicks) uses a product’s total clicks across your whole store. That makes a “Trending Now” collection a one-condition setup: for example, products with more than 50 clicks in the last 7 days. Products join the collection as they gain attention and drop out automatically as that attention fades. It’s a storefront merchandising surface that tracks this week’s demand without anyone touching it.

### Where it shines

The most obvious win is for stores with lower sales volume. Clicks accumulate far faster than orders, so your sorting gets smart long before sales data could tell you anything reliable. If you’ve been frustrated that sales-based sorting feels random on your smaller collections, this gives those collections a dense signal to work with.

It’s also a merchandising blind-spot finder. The product you assume is your hero, versus the product shoppers actually click, are not always the same thing, and this attribute surfaces the gap. And with a short window like 7 days, your collections follow seasonal demand automatically, leaning into a holiday as interest builds and easing back out as it passes.

### An honest word on feedback loops

There’s a dynamic worth being upfront about: clicks at the top of a collection tend to beget more clicks. A product that’s surfaced gets seen, gets clicked, and that click reinforces its position. Left unchecked, that can become a feedback loop where early attention compounds into permanent placement regardless of merit.

The right way to use this attribute is as one input among several, not the whole sort. Balance it with merchandising attributes like margin, inventory, and newness. Engagement is valuable information about what your shoppers find interesting, but it works best when it informs the sort rather than dictating it. Sophisticated merchants will recognize this immediately, and the attribute is built to be weighted alongside everything else precisely so you can strike that balance.

### A few more notes

Click data updates periodically through the day, not in real time, so expect influence within hours rather than instantly. Brand-new or very low-traffic collections have no click history yet, so the attribute contributes nothing there until shoppers arrive — your other recipe attributes carry the sort in the meantime.

### Pairs with Back In Stock

Most Clicked Products shipped the same day as the Back In Stock attribute, and they’re natural partners. One captures attention, the other captures availability. Used together, your collections stay both interesting and buyable: the products people are clicking rise, and the products that just came back in stock rise, so shoppers see things they want and can actually buy.

### Available now

Most Clicked Products is live today on all plans, as a standard attribute. Add it to a recipe to give each collection its own audience-driven ranking, or use it as a Managed Collection condition to build a self-maintaining trending collection.

Questions or feedback: hello@dynasort.io or in-app chat.

For most stores, the answer is no — and not because anyone decided that. It’s just what happens by default.

### The problem nobody has time to solve

While a product is out of stock, it tends to sink in your collection’s sort order. It’s not selling, it’s not converting, so whatever logic orders your collection pushes it down. That’s reasonable while it’s unbuyable.

The trouble is what happens when it returns. The product comes back in stock and lands wherever it sank — often several pages deep. So at the exact moment back-in-stock demand is highest, your returning bestseller is facing the shoppers least likely to ever see it.

The fix has always been manual: remember that the product restocked, go into the collection, and pin it to the top. Then do that for every collection it belongs to. Then do it again for the next product that restocks, and the next. Across a real catalog, nobody keeps up with this. The restock window quietly passes with the product buried.

### What the Back In Stock attribute does

Back In Stock is a new Dynasort attribute that detects when a product returns to stock and automatically boosts it in your sorted collections for a window you choose, anywhere from 24 hours to 90 days.

Dynasort continuously monitors inventory levels and records a restock event whenever an item crosses from out of stock back to in stock. Any product with a recent qualifying restock gets the attribute’s full boost in any recipe that includes it. No tagging, no manual pinning, no spreadsheets, no remembering.

### The returns filter: the part that matters

Here’s the detail that separates this from a naive implementation.

A customer return puts a unit or two back on the shelf. Technically, that takes a product from zero units to “in stock” — which means a simple back-in-stock boost would fire on it. You’d end up promoting a product that has two returned units and is, for all practical purposes, still sold out. Worse, it would happen constantly, on every minor return across your catalog.

Dynasort handles this with a minimum restock quantity setting, defaulting to 3 units. A restock smaller than that threshold is ignored. Only genuine replenishments — the kind that mean a product is actually buyable again — trigger the boost.

This is the kind of logic you only think to build if you’ve actually lived with inventory data. “Back in stock sorting” is easy to claim. Not firing on a single returned unit is the part that proves the feature was built by people who understand how stock really moves.

### You decide what “back” means

There are two detection modes.

Entire product back in stock fires when a product that was completely sold out has stock again. This is the default, and it matches what most shoppers mean when they say something is “back.”

Any variant back in stock fires when an individual variant returns — a popular size, a sold-out color. This is useful for stores where a single variant coming back is itself worth promoting.

Configuration is three fields in total: the timeframe (how recent the restock must be), the detection mode (entire product or any variant), and the minimum restock quantity (the returns filter). That’s the whole setup.

### One signal, two surfaces

Because Back In Stock is a standard Dynasort attribute, it works everywhere attributes work.

Inside a recipe, it’s weighted alongside everything else you sort by — sales, margin, newness, clicks, behavioral signals. A restocked product that shoppers were already viewing and adding to cart gets compound priority, surfacing for exactly the reasons you’d want it to.

As a Managed Collection condition, it lets you build a self-maintaining “Back In Stock” collection on your storefront. You set it up once with a single condition: products join the collection when they restock and drop out automatically as the event ages past your window. It’s a merchandising surface that maintains itself.

You can also layer recency. Stack a high-weight 7-day instance with a low-weight 30-day instance, and the boost steps down gracefully as the restock ages — strong while the product just came back, tapering as the moment cools.

### A few honest notes

Detection follows your store’s regular data sync schedule, so a restock is reflected within minutes to about an hour, not literally the instant it happens. Restock history starts accumulating from June 2026, which means the longest windows (60 and 90 days) reach full usefulness once that much history has built up. And products that don’t track inventory in Shopify never trigger the attribute, which is the correct behavior but worth knowing.

### Available now

The Back In Stock attribute is live today on all plans, as a standard attribute. Add it to a recipe, or use it as a Managed Collection condition — or both.

Questions or feedback: hello@dynasort.io or in-app chat.

—

*Install Dynasort free on the Shopify App Store at [dynasort.io](https://dynasort.io)*

“Conversion rate is 2.3% over the last 30 days” is a fact. But it’s a fact with no context. Is 2.3% good for this collection? Is it up or down? Did it move because of the recipe you swapped two weeks ago, or the pins you added last Tuesday, or nothing you did at all? The old Insights left you to answer those questions yourself, usually by exporting data and guessing.

We rebuilt Insights so it answers them for you. This is the largest performance-visibility update we’ve shipped, and it spans six connected features.

Metrics Timeline, on everything

The centerpiece is the Metrics Timeline, now at the bottom of every collection, product, and recipe page. It charts your key rates — conversion, add-to-cart, exit, and bounce — over time.

What makes it more than just a chart is what’s plotted alongside the curve: change markers. Every time you swapped a recipe, added a pin, adjusted attribute weights, started or stopped an A/B test, or made any of a dozen other meaningful configuration changes, a marker appears on the timeline at that exact moment.

This is the difference between seeing a number and understanding it. If your conversion rate climbed over the last two weeks, you can now see whether that climb started the day you swapped recipes — or whether it was already happening and your change had nothing to do with it. Cause and effect, on the same chart.

A dashboard, not a settings panel

Open Dynasort now and the first thing you see is a store-wide performance timeline for the last seven days. Below it sit three Top Movers panels: your top collections, top products, and top recipes.

We chose “movers” deliberately. It’s not just a list of your best performers frozen in place — it surfaces what’s changing, in both directions. Each tile shows a thumbnail trend chart, the current conversion rate, and a colored arrow indicating the percentage change versus the prior week. Green arrows mark wins worth repeating. Red arrows flag problems worth fixing. Click any tile to drill into that entity’s full timeline.

The point is that you no longer have to hunt for what’s working or what’s slipping. The app puts it in front of you the moment you open it.

Stop guessing whether you’re improving

The Insights page now opens with a six-KPI strip: sessions, conversions, conversion rate, cart rate, exit rate, and bounce rate. Each shows the value for your selected window plus a colored arrow showing how it compares to the equivalent prior window.

Pick “30 days” and you immediately see how the last 30 days stack up against the 30 before them. The arrows handle the directional intuition for you — conversion rate up is green, exit rate up is red. “Are we trending up?” used to mean exporting data to a spreadsheet and building a comparison by hand. Now it’s the first thing you see.

A change log you don’t have to maintain

Below every timeline chart is a chronological list of every meaningful configuration change: what changed, when, and by how much. Attribute weight bumps, A/B test starts and stops, manual sorts, pin updates, recipe swaps — all named with the friendly attribute and recipe names you actually use, not internal IDs.

For teams sharing Dynasort access, this is a shared audit trail. You can see what a colleague changed and tie it directly to the movement in the metrics above it. For solo merchants, it’s a changelog you get for free instead of trying to remember what you did and when.

Recipe performance that’s actually trustworthy

Recipe pages get the same timeline treatment, with one subtle but important detail handled correctly: time-accurate attribution.

If you moved a collection from Recipe A to Recipe B last Tuesday, Recipe A’s history correctly shows the traffic from before Tuesday, and Recipe B shows the traffic after. The data reflects what was actually true at each point in time, rather than taking today’s recipe assignments and projecting them backward across the whole history. That means when you compare two recipes, you’re comparing real performance, not an artifact of who happens to be assigned where right now.

Click a row, land on the chart

Finally, a small quality-of-life addition: clicking any collection, product, or recipe row in the Insights table takes you straight to that entity’s page, already scrolled to its timeline. No scrolling past settings to find the data you came for.

Built to be reliable from day one

A few things happening beneath the surface, for merchants who care about the plumbing:

Enterprise stores were backfilled with 90 days of historical timeline data, so your charts are populated immediately rather than starting empty. The underlying analytics pipeline was rebuilt to keep high-volume stores current — previously, very large stores could silently fall days behind; now the pipeline catches up adaptively. And the entire system is timezone-correct, so international merchants see complete data through their own “yesterday,” not the server’s.

Available now

The reworked Insights is live today on all plans. Open the app and you’ll land on the new dashboard. From there, every collection, product, and recipe has its timeline waiting at the bottom of the page.

Questions or feedback: hello@dynasort.io or in-app chat.

What min and max actually do

Every numeric attribute you use for sorting has a minimum and a maximum value. These two numbers do more work than they appear to.

When Dynasort scores a product, each attribute’s raw value gets normalized into a 0 to 1 contribution. The min is the floor and the max is the ceiling: a product at or below the min contributes 0, a product at or above the max contributes 1, and anything in between is interpolated linearly. For attributes where lower is better, like bounce rate or exits, the score is inverted.

This is a clean, standard way to turn wildly different metrics — revenue in dollars, conversion rate as a percentage, inventory as a count — into comparable scores that can be weighted and combined. But it only works well if the min and max reflect your actual catalog. Set the revenue ceiling too low and half your products max out at a score of 1, flattening the signal. Set it too high and nothing ever approaches the top, compressing everything toward zero.

The problem nobody revisits

Here’s what happens in practice. During setup, you configure your attributes and set reasonable min/max values, often using the recommendation Dynasort already shows next to each field. Then you move on. The store runs. Months pass.

In those months, your catalog grows. Your traffic patterns shift. Your best-selling products change. The revenue distribution that made sense in October looks nothing like the one in March. But those min/max values are still sitting where you left them, quietly calibrated to a version of your store that no longer exists.

Nothing breaks, exactly. The sorting still runs. But it’s running on stale calibration, and the further your data drifts from those original numbers, the less your scores mean.

The fix used to be manual: go back into each attribute, look at the current recommendation, and copy the new numbers into the fields. Almost nobody did this regularly, because it’s the kind of maintenance task that’s easy to forget and hard to prioritize.

Check a box, and it’s handled

Now there’s a simpler option. On any numeric attribute, you’ll find a new checkbox labeled “Auto-update from recommendations,” with help text that reads “Refresh minimum and maximum from data each day.”

Check it and save. Two things happen.

First, Dynasort immediately recomputes that attribute’s min and max from your current store data and applies them. Second, from that point forward, a nightly process keeps them in sync automatically. You don’t approve each update — opting in is the approval. The values simply stay current.

The recommendation logic is the same one Dynasort has always used for its on-screen suggestion: the floor is set at the 5th percentile of your product distribution, and the ceiling at the 90th percentile. This trims outliers on both ends so a single extreme product doesn’t distort the whole range. For traffic-derived attributes like conversions, sales, and cart adds, the distribution comes from your recent data window. For static catalog attributes like inventory, margin, and product age, it comes from your product data directly.

Built to be conservative

This feature changes values automatically, so we designed it to be cautious by default.

It only touches attributes you explicitly check. Every other attribute stays exactly as you set it. It only changes min and max — never your weights, your attribute status, or any other setting. There are guardrails on every update: if a recommendation would produce an inverted range (min greater than max) or an invalid value, the write is skipped. And when there isn’t a usable recommendation for one side of the range, your existing value on that side is preserved rather than blanked out.

Everything is computed from data already inside Dynasort. There are no external API calls, and nothing is pushed to Shopify as part of this feature. It’s purely an internal recalibration of the numbers your sorting already depends on.

What it covers

Auto-update works on 20 numeric attribute types. That includes traffic and event-derived metrics — cart adds, cart rate, bounces, bounce rate, conversions, conversion rate, exits, exit rate, product views, revenue, sales, and sell-through rate — as well as static catalog values like inventory quantity, per-location inventory, product margin, discount amount, discount percent, age of newest variant, days since created, and days since published.

Attributes that aren’t numeric ranges — booleans, metafields, product tags, options, and similar — don’t have min/max values, so the checkbox doesn’t appear for them.

You can see the status of every attribute at a glance on the attributes index, where a new “Auto” column shows a green On badge for enabled attributes, a grey Off badge for eligible ones you haven’t enabled, and nothing for attribute types that don’t support it.

Available now, every plan

This is live today on every Dynasort plan, from Demo to Enterprise. There’s no upgrade required and no add-on. Open any numeric attribute and you’ll find the toggle directly below the min and max fields.

Set it once, and stop thinking about it. Which, for a maintenance task, is exactly the point.

Questions or feedback: hello@dynasort.io or in-app chat.