Shopify Analytics With AI: From Orders to Decisions

Shopify analytics is excellent at telling you what happened and mostly silent on what to do about it. Sessions, conversion rate, sales by product, sales by channel: it is all there, refreshed daily, and it is honest about the data Shopify actually owns. The trouble is that almost every decision a store operator makes depends on data Shopify does not own. Ad spend sits in Meta and Google. Payment fees sit in Stripe or in payout statements. Landed cost sits in a spreadsheet or an ERP. Return reasons and product complaints sit in the helpdesk. So the operator becomes the join: export, paste, rebuild, repeat.

This article covers the four store questions worth systematizing, the arithmetic behind each one, and how to get answers without maintaining a reporting stack you do not have time to maintain.

Where Shopify analytics stops being enough

Shopify's built-in reports are a genuinely good first layer. They are fast, they reconcile with your orders, and they cover the questions a store asks in its first year. Three structural limits show up as you grow.

Report depth is tiered. Shopify gates some report categories by plan level, and the exact list changes over time. Check what your current plan includes before assuming a report is missing rather than locked.

The analysis stops at the store boundary. Shopify knows an order came from a session tagged with a Meta UTM. It does not know what that click cost, whether the same customer also clicked a Google Shopping ad two days earlier, or that this SKU generates three times the support tickets of anything else in the catalogue.

Margin depends on a field most stores half-fill. Shopify has a cost per item field on each variant, and profit reporting leans on it entirely. If that field is empty, stale, or excludes freight and duties, your profit report is a revenue report wearing a costume. This is the highest-leverage data hygiene task in most stores.

None of that makes Shopify analytics wrong. It makes it incomplete for the specific decisions below.

Question one: repeat rate, measured by cohort

Repeat rate is the number that quietly sets your acquisition budget. If a customer buys twice in their first year, you can pay far more for the first order than a store where they buy once and vanish.

Most stores measure it wrong, in the same two ways.

The denominator problem

"Percentage of customers who ordered more than once" computed over all time is a vanity number, because it includes customers who bought yesterday and have had no chance to return. Every time you scale acquisition, this metric falls, and it looks like a retention problem when it is arithmetic.

Measure by cohort instead. Group customers by the month of their first order, then ask what share placed a second order within a fixed window: 30, 60, 90, and 180 days. Compare January's 90-day figure to February's 90-day figure. Those are comparable. "All customers ever" is not.

Suppose January had 1,000 first-time buyers and 180 of them ordered again within 90 days. That cohort's 90-day repeat rate is 18 percent. If the March cohort lands at 12 percent on the same window, something changed: discount-led acquisition, a product mix shift toward one-off gifting, or a fulfilment experience that got worse. The cohort view tells you when it changed, which is usually enough to find the cause.

Second-order timing, not just second-order rate

The other half of the picture is latency. Take the customers who did repeat and look at the median days between first and second order. That number tells you when your winback email should send and whether a subscription offer is worth showing. A consumable with a 34-day median reorder gap needs a day 28 nudge. A durable with a 140-day gap does not.

Segment repeat rate by first product purchased. Almost always, one or two entry products produce dramatically better second orders. That is your acquisition hero SKU, and it is frequently not your top revenue SKU.

Question two: product margin, not product revenue

Ranking products by revenue is the most common reporting mistake in ecommerce, because revenue ignores everything that happens after the customer clicks buy.

Contribution margin per order is closer to the truth:

Contribution margin =
  gross revenue
  - discounts
  - cost of goods (landed: unit cost + freight + duties)
  - payment processing fees
  - pick, pack, and outbound shipping cost
  - expected return cost (return rate x (refunded revenue + reverse logistics))

Every one of those lines comes from a different system. Discounts and revenue are in Shopify. Landed cost belongs in the cost per item field but usually is not fully loaded there. Processing fees are in your payment provider's payouts, and reading them properly is a discipline of its own, covered in Stripe Revenue Analytics. Fulfilment cost is in a 3PL invoice. Return cost is a blend of Shopify refunds and helpdesk data.

Two patterns show up almost every time a store does this exercise for the first time:

• A high-revenue product with heavy discount dependence contributes less absolute margin than a mid-volume product that never goes on sale.
• A bulky, low-price item is margin negative once shipping and returns are loaded in, and has been for a year.

You do not need this analysis weekly. You need it monthly, and you need it to survive contact with the actual numbers rather than living in someone's head.

A note on the cost per item field

If you fix one thing after reading this, fix landed cost. Push freight and duty allocations into the cost per item value rather than tracking them in a separate sheet, and re-check the field after every supplier price change or shipping rate change. Shopify's profit reporting, and any AI layer reading it, can only be as accurate as that field.

Question three: inventory risk, expressed in days

Units on hand is not a risk signal. Days of cover is.

Average daily units = units sold in the last 28 days / 28
Days of cover      = units on hand / average daily units
Reorder point      = (average daily units x supplier lead time in days) + safety stock

The rule that matters: a variant is at risk when days of cover drops below lead time plus your safety buffer, not when it drops below some fixed unit count. A product with 40 units and a 60-day lead time from an overseas supplier is in more trouble than a product with 8 units and a domestic supplier who ships in three days.

Two refinements are worth adding.

Weight recent velocity. A flat 28-day average lags a product that is accelerating. Compare the last 7 days of daily velocity against the last 28. If the 7-day rate is meaningfully higher, use it for the risk calculation and expect to be surprised sooner.

Watch the variant, not the product. Stores stock out at the size and colour level long before the parent product looks thin. Any inventory alert that aggregates to the product level will miss the thing that actually costs you sales.

The mirror image matters too: slow movers. Anything with more than 180 days of cover is capital sitting in a warehouse and, if you pay storage fees, an expense that compounds. That list belongs in the same weekly check as the stockout list.

Question four: channel performance when the numbers disagree

Ask Meta, Google, and Shopify how much revenue each channel drove last month, and you will get three answers that sum to more than your actual revenue. This is not a bug in any of the systems. They are measuring different things.

Ad platforms attribute conversions using their own windows and rules, including view-through behaviour on some platforms, and only within their own account. Shopify attributes orders based on the session and referral data it can observe, which breaks when customers arrive through in-app browsers, click email links that strip parameters, or research on mobile and buy on desktop. Neither is lying. They cannot see the same event.

The practical response is to stop trying to reconcile them and instead run two layers.

Blended, for budget decisions. Marketing efficiency ratio is total store revenue divided by total ad spend across all platforms for the same period. It is crude, it needs no attribution model, and it cannot be gamed by a platform grading its own homework. Pair it with new customer acquisition cost: total ad spend divided by the count of first-time customers in Shopify for that period. Those two numbers, tracked weekly, are enough to decide whether to spend more or less.

Platform-reported, for relative decisions inside a channel. Meta's own numbers are fine for comparing creative A to creative B in the same account and window. They are not fine for deciding whether Meta beats Google.

What support and conversation data adds

Support data is the earliest quality signal a store has, and it is almost never in the analytics stack.

Normalise it: tickets per 100 orders, by SKU. A product at three times the catalogue average is telling you something specific, and the ticket text usually tells you exactly what. Sizing runs small. The instructions are unclear. The packaging fails in transit.

The sequence is consistent and worth watching for. Support contacts rise first. Review scores dip a few weeks later. Returns follow after that. Refunds hit the P&L last. If you only watch the refund line, you find out about a bad production batch a full quarter after the first customer told you.

Internal conversation carries signal too. What a team escalates and repeats in Slack often surfaces an operational problem before any dashboard does, which is the subject of Slack Analytics: What Team Conversation Reveals. If you run a wholesale or B2B arm alongside the store, the account-level view of that business lives in your CRM, and the same plain-English approach applies there: see HubSpot AI Analytics or, for larger orgs, Salesforce AI Assistant.

Running Shopify analytics questions in plain English

This is where an AI workspace earns its place. Skopx connects to Shopify alongside nearly 1,000 other business tools, and the point is not that it visualises anything. It does not. The point is that it can pull from several systems in one request, do the arithmetic, cite where each number came from, and hand you a written answer you can act on.

A real question looks like this:

For last month's Shopify orders, rank products by contribution margin after discounts and cost per item, then show how many support tickets each of the bottom five products generated and what the most common ticket reason was.

What comes back is a ranked table with the margin arithmetic shown per product, ticket counts joined by SKU, the dominant reason per product, and source citations on both sides of the join. It is the analysis you would have built in a spreadsheet over an afternoon, delivered as text you can paste into a supplier email.

Two honest caveats.

Volume has limits. Skopx reads Shopify through its API, which is rate limited like every commerce API. Ad hoc questions over a month or a quarter are comfortable. Multi-year cohort analysis across hundreds of thousands of orders is not an API-paging job. If you already replicate Shopify data into PostgreSQL, MySQL, or MongoDB, connect the database and ask the question there instead. Skopx queries those directly in chat, which is the right path for heavy historical work.

Skopx is not a BI tool. It does not build dashboards, charts, or drag-and-drop visualisations, and it will not pretend otherwise. If what you want is a wall-mounted revenue dashboard the whole team watches, use a dedicated BI product. Shopify's own reports, Looker Studio, or Metabase are all reasonable starting points, and pricing and feature tiers change, so check current details directly. Use Skopx for the layer BI is bad at: cross-tool questions, written analysis, and alerts that fire without anyone opening a tab.

Automating the recurring checks

The inventory and channel questions above are not one-time analyses. They are weekly obligations, which makes them the right shape for automation.

In Skopx you build a workflow by describing it in chat. There is no canvas to drag:

Every Monday at 8am, pull Shopify inventory levels and the last 28 days of orders, calculate days of cover for each variant, and post any variant under 21 days of cover to the #ops Slack channel with units on hand and weekly sell-through.

That becomes a scheduled workflow: a schedule trigger, Shopify integration actions to fetch inventory and orders, a transform step to compute days of cover per variant, a condition to filter the list, and a Slack action to post it. Every run is inspectable step by step, so when a Monday post looks wrong you can see exactly which step returned what.

The constraints are worth knowing before you plan around them. Workflows are acyclic and capped at 20 steps. Triggers are manual, scheduled with a 15 minute minimum interval, or webhook based. There are no human-approval steps and no custom code steps. AI steps run on your own provider key. If your automation needs a person to sign off mid-run, or needs a loop, model it as two workflows or keep it in chat. More detail is at skopx.com/workflows, and the Shopify connection sits alongside the rest of the catalogue at skopx.com/integrations.

Alongside scheduled workflows, the daily morning brief surfaces what changed and what is slipping across connected tools, which covers the "something moved and nobody noticed" category that no dashboard solves.

A sensible stack for store reporting

You do not need all of this. Match the surface to the question.

Frequently asked questions

Does Skopx replace Shopify analytics?

No. It sits on top. Shopify remains the source of truth for orders, sessions, and inventory, and its reports stay the fastest way to check yesterday's sales. Skopx is for the questions that need Shopify plus something else: ad spend, payment fees, helpdesk tickets, supplier lead times. If a question can be answered inside the Shopify admin, answer it there.

How accurate are AI answers about my store data?

The arithmetic runs on data pulled live from your connected tools, and every answer cites its source so you can verify a number against the underlying record. Accuracy is bounded by your data quality, which for Shopify analytics almost always means the cost per item field. Bad costs in, confident wrong margins out. Check the citations on any number that will drive a real decision.

Can it take actions in my store, not just read?

Yes, with your approval. Skopx acts only on confirmation, so it can update inventory, tag orders, or trigger downstream steps in a workflow once you have approved the action. Data is encrypted with AES-256 at rest and TLS 1.3 in transit, isolated per organisation at the row level, with SOC 2 controls in place. Your data is never used to train a model.

What does it cost, and is there a trial?

Skopx is a paid product with no free tier and no trial period. Solo is $5 per month, Team is $16 per seat per month with no seat cap, and Enterprise and White Label are $5,000 per month. Billing starts on day one. AI usage runs on your own provider key, from Anthropic, OpenAI, Google, or others, with zero markup from Skopx. Full detail at skopx.com/pricing.

Which single metric should a small store start with?

Cohorted 90-day repeat rate, split by first product purchased. It is computable from Shopify data alone, it needs no attribution model, and it changes two decisions at once: what you can afford to pay for a customer, and which product deserves your acquisition spend.

Can it reconcile Shopify revenue with my ad platform numbers?

It can put them side by side, explain where they diverge, and compute blended efficiency across both. It cannot make them agree, because they measure different events under different attribution rules. Any tool claiming perfect reconciliation is picking one model and hiding the choice. Track blended numbers for budget decisions and platform numbers for in-channel comparisons.

Skopx catches what falls between your tools, and in ecommerce that gap is wide: the margin the revenue report hides, the stockout the unit count misses, the product complaint that reaches the P&L a quarter after the first customer flagged it. Start with the four questions above, fix your cost data, and automate the two that repeat every week.