Returns quietly eat ecommerce margin, and a slice of them are fraud. Here's how to analyze returns by SKU, reason, and cost, and how to spot wardrobing, serial returners, and refund-not-returned abuse, without hiring a data team.
Kateryna Kozachenko
Marketing & Growth
TL;DR: returns are one of the largest and least-analyzed costs in ecommerce, and a meaningful slice of them are fraud (wardrobing, serial returners, refund-not-returned, empty-box). The hard part isn't the analysis, it's that the data lives in four places (Shopify, your 3PL or warehouse, your payment processor, and support tickets) that were never joined. Once they're joined, the useful work is straightforward: return rate by SKU and reason, true cost per return, and a set of fraud signals you can run on a schedule. You do not need a data team to do this. You need your sources connected and a way to ask questions across them. That's the case an AI data analyst like Bruin is built for.
Every ecommerce operator knows returns are expensive. Very few can tell you how expensive, which products drive it, or how much of it is fraud, because answering those questions means joining data that lives in systems that don't talk to each other.
Returns in apparel routinely run 20 to 30 percent. Even outside apparel, the reverse-logistics cost (return shipping, inspection, restocking or write-off, refund processing) can erase the margin on the sale entirely. And on top of the honest returns sits a layer of abuse that the retail industry now estimates in the tens of billions of dollars a year. Most of it is invisible until you go looking.
Here's how to go looking, without hiring anyone.
The problem is not the math. It's the plumbing. A single return touches at least four systems:
None of these systems shares a common key out of the box. Shopify's reason codes are a dropdown the customer chose, not the truth. Your WMS keyed everything on its own SKU scheme. Your processor knows a refund happened but not why. To analyze returns properly you have to stitch these together, and that stitching is exactly the job people assume requires a data team.
It doesn't anymore. But you do have to connect the sources once.
Once orders, refunds, warehouse receipts, and payments sit in one place, here are the analyses that pay for themselves. None of them is exotic. They're just usually impossible because the data was never joined.
Return rate by SKU and variant. Not store-wide, per variant. A single size or color is often responsible for a wildly disproportionate share of returns. Find it and you can fix the sizing description, the photography, or drop the variant.
Return reason, weighted by cost. "Wrong size" and "damaged" are very different problems: one is a merchandising fix, the other is a packaging or supplier fix. Weight each reason by what it actually costs you, not by count. Ten cheap "changed my mind" returns can matter less than two high-value "damaged in transit" returns.
True cost per return. Add it up honestly: outbound shipping you already ate, return shipping, inspection labor, restocking or write-off, refunded payment fees that don't always come back, and the discount if the item can only be resold as open-box. This number shocks people. It's often 20 to 60 percent of the item price.
Time-to-return distribution. When do returns happen relative to delivery? A spike right before the return window closes is a classic wardrobing signal (buy, use once, return). A cluster right after delivery usually means a real product or sizing problem.
Repeat-return behavior. What share of returns comes from customers who return on most of their orders? These customers frequently have negative lifetime value once returns are counted, and you may be actively acquiring more of them.
Return fraud isn't one thing. It's a family of behaviors, and each leaves a different fingerprint in the joined data:
The pattern across all of these: no single system can see the fraud. Shopify sees a refund. The warehouse sees (or doesn't see) a package. The processor sees a dispute. The fraud only becomes visible when you put the refund next to the receipt next to the payment. That join is the whole game.
Historically, this kind of cross-system analysis was a data-engineering project: build pipelines from Shopify, the WMS, and Stripe into a warehouse, model the joins, then have an analyst write the queries. Months, and a headcount.
The reason it's now doable without that team is that two things got cheap. Connecting the sources got cheap, and asking questions across them in plain English got cheap.
An AI data analyst is a good fit here specifically because returns questions are endless and ad-hoc. You'll never build a dashboard for every one of "which SKUs drive damaged-in-transit returns from the East Coast 3PL", "which customers were refunded but never sent the item back last quarter", and "did our new packaging reduce damage returns". You just want to ask, get an answer with the query behind it, and move on.
The two properties that matter for returns work:
We built Bruin as one platform that connects your sources, joins them, and answers questions on top, which lines up with exactly what returns analysis needs.
You connect Shopify, your 3PL or WMS, and your payment processor once, through direct integrations plus thousands more sources via APIs, webhooks, and scraping. From then on you can ask, in Slack or wherever your team works, "which customers were refunded last quarter with no matching warehouse scan?", and get the list with the query that produced it. Because Bruin ingested and joined the data, the refund-not-returned check is just a question, not a project.
And because the same platform can run things on a schedule, the high-value fraud checks (refund-not-returned, serial returners, chargeback-plus-delivered) can run weekly and post the flagged cases straight into the channel your team already uses: Slack, Microsoft Teams, Google Chat, WhatsApp, Discord, Telegram, email, or the browser. Fraud detection becomes something that watches your back, instead of something you have to remember to look for.
Once your order, refund, warehouse, and payment data are connected, these are worth running immediately:
Each of these is a number you can act on: a SKU to fix, a customer to flag, a policy to tighten, a packaging supplier to call.
Industry estimates put return fraud and abuse at a meaningful percentage of total returns, and total returns are large, so the dollar figure runs into the tens of billions annually across US retail. For an individual store the rate varies by category and price point, but almost every operator who runs the refund-not-returned check for the first time finds cases they didn't know about.
Refund-not-returned: refunds that were issued with no matching warehouse receipt after a reasonable window. It's high-value, unambiguous, and only possible once refund data and warehouse-receipt data are joined. Start there.
Partially. Shopify alone gives you return rates and reasons, which is useful. But the fraud layer and the true-cost analysis need your warehouse and payment data too, because Shopify can't tell you whether the item physically came back or what the reverse logistics cost. The value is in the join.
No. This is about connecting the systems you already run (Shopify, your 3PL, your processor) so their data can be analyzed together. An AI data analyst reads from those sources; it doesn't replace your storefront or your warehouse.
By showing its work. A good tool returns the query and the underlying rows for every flag, so a flagged case is a list of specific orders you can inspect, not a black-box verdict. You review before you act. The tool surfaces candidates; a human confirms.
Bruin can run analyses on a schedule and post results into the channel your team already uses. So the refund-not-returned and serial-returner checks run automatically and flag cases as they appear, rather than depending on someone remembering to look. You can read more or get started at github.com/bruin-data.
How Bruin CLI, Bruin MCP, Bruin Cloud, and agent skills can build and maintain a Salesforce to Snowflake ELT pipeline across bronze, silver, and gold layers.
Most AI data analysts live in Slack or a browser. Bruin runs in WhatsApp too. Here is why field, sales, and ops teams prefer asking their data questions there, what it takes to make it actually work, and how to roll it out safely.
Can you just use ChatGPT, Claude, or a coding agent like Codex to analyze your company data? Here is the honest difference between a general AI model and a purpose-built AI data analyst, why a model alone is not enough, and what it takes to get trustworthy answers from live company data.
Practical updates on open-source data pipelines, AI analysts, governance, and what we are shipping at Bruin.