.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiThis page is going away in its current form. Content that used to live here, on items per customer as a standalone definition, now lives inside our broader data dictionary and BI reporting resources.
The reasoning is pretty simple. A single-metric glossary page like [PAGE] /resources/data-dictionary/items-per-customer makes sense in isolation, but ecommerce metrics don't work in isolation. Items per customer only means something next to AOV, repeat purchase rate, and LTV. Splitting them into dozens of thin pages made it harder, not easier, to see how they connect.
If you bookmarked this URL, you'll get redirected to the consolidated resource. Nothing is lost. It's just organized the way people actually use it.
Items per customer is total units sold divided by total unique customers in a given period. That's it. No adjustments, no weighting.
Say you sold 4,200 units to 1,800 unique customers in a month. That's 2.33 items per customer. Simple division, but the number tells you something real about basket depth across your customer base, not just within a single transaction.
Here's where most dashboards trip people up: items per order and items per customer get used interchangeably, and they're not the same thing. Items per order measures basket size on a single transaction. Items per customer measures total units across potentially multiple orders in the period. A customer who orders twice in a month with 2 items each time contributes 4 to your items-per-customer number, but only 2 to items-per-order. If your tooltip doesn't specify which one you're looking at, you're probably misreading your own dashboard.
On its own, items per customer is close to a vanity metric. It only gets useful once you pair it with AOV and gross margin per unit.
Here's a scenario that comes up constantly: items per customer climbs while AOV falls. Looks like a win on the surface, more units moving per customer. But paired with AOV, it usually means you're running discount-driven bundling, not genuine demand growth. Customers are buying more units because you made the unit price cheaper, not because they suddenly love the product more. Margin per unit tells you whether that trade was worth making.
This is exactly why Trivas doesn't treat items per customer as a metric worth its own glossary entry. It's one input inside a cohort or customer-value dashboard, sitting next to AOV, repeat purchase rate, and margin, where it actually tells you something actionable. Pulled out on its own, you're just staring at a number with no context for whether it's good or bad.
The current, maintained version of this definition (and related ones) lives in the main data dictionary. AOV, repeat purchase rate, customer lifetime value, all grouped together there instead of scattered across dozens of thin standalone pages that each need separate upkeep.
That grouping matters more than it sounds. When you're trying to figure out if a shift in items per customer is good or bad, you want AOV and margin right there next to it, not three browser tabs away.
The dictionary also gets updated as we add new reporting fields to the platform. A standalone page for items per customer would have gone stale the first time we shipped a new cohort view or changed how a field gets calculated. Keeping definitions centralized means they actually stay current instead of becoming an orphaned page nobody maintains.
If you're still calculating items per customer in a spreadsheet, pulling order exports and running a pivot table every month, that's exactly the workflow we built Trivas to kill.
The BI reporting layer pulls items-per-customer calculations automatically from Shopify and Amazon order data sitting in Redshift. No manual exports, no pivot tables, no reconciling two different order systems by hand. The number updates as new orders come in.
The AI Wingman layer goes a step further. Instead of you manually checking month over month whether items per customer moved, Wingman can flag it when the number drifts from its trailing 90-day average. You find out when something's actually off, not because you happened to run a check that week.
Honestly, this is the part that makes a standalone glossary page feel pointless. Items per customer isn't a concept people need explained in depth, it's a number data analysts and growth leads glance at weekly inside a live dashboard. It doesn't need a landing page to be useful. It needs to show up correctly, in context, next to the other numbers that make it meaningful.
If you came here looking for items per customer, AOV, repeat purchase rate, or LTV definitions, head to the data dictionary for the current, maintained versions.
If you want to see how these metrics actually show up in a working dashboard instead of a glossary entry, the BI reporting product page walks through that.
And if you're a data analyst evaluating how Trivas handles customer-value reporting end to end, from Redshift pull to dashboard to automated flagging, this page is built for exactly that question.
Want more of this kind of breakdown as we keep building out the dictionary and reporting tools? Subscribe to our updates and we'll let you know when new resources go live.
explore more insights
3 min read
3 min read
3 min read