Sales Data Analysis: Product Trends, Metrics, and Example

One product gets more views this week but fewer orders. Another brings in more revenue from the same number of orders. Those observations call for different checks. A store-wide sales total won’t tell you which product needs attention, and a rising line alone won’t tell you what to change.

Sales data analysis means organizing recorded sales information to answer a business question. For an online store, start with a product, a fixed period, and separate measures for attention, purchases, and money. Compare them before proposing a price, stock, or storefront change.

This guide focuses on product-level interpretation. Use our ecommerce report template for the broader operating report, or the store analytics guide for funnels and customer cohorts.

Start with the counting rules

Before comparing products, ask what one row represents. An order export usually has different counting rules from an event stream or a daily product report.

Product views. Are these events, sessions, or distinct visitors? A repeat view may not represent another shopper.
Orders containing a product. Does an order count once per product? Three units in one order are not three orders.
Units sold. Check quantities across the included order lines. Order count alone cannot tell you how many units need replenishing.
Product revenue. Check included lines, price basis, currency, and adjustments. Don’t assume it means net sales or profit.
Reporting day. Confirm the timezone and whether the day is complete. Today’s partial result is not comparable with yesterday’s full day.

Sales analysis guides often cover sales representatives, deal pipelines, and forecasting. Salesforce’s sales data guide separates customer information from internal sales performance data. Pipefy’s guide distinguishes product analysis from pipeline and trend analysis. For a merchant deciding which product page to inspect, the narrower product-day view is a useful starting point.

Our recommendation is to keep views, orders, and revenue separate until their definitions are clear. If your question is inventory replenishment, add units and available stock. If it’s profitability, add the relevant costs and adjustments. Neither question can be answered by revenue alone.

A product sales example with two different explanations

The following numbers are illustrative, not customer results or a benchmark. Both periods contain seven complete days, use the same timezone, and report revenue in USD under the same definition.

Ceramic mug

Earlier week: 400 product view events, 20 orders containing the product, and $600 in product line revenue.
Later week: 800 product view events, 20 orders containing the product, and $600 in product line revenue.

Loose-leaf tea

Earlier week: 200 product view events, 10 orders containing the product, and $150 in product line revenue.
Later week: 200 product view events, 10 orders containing the product, and $300 in product line revenue.

The mug received twice as many recorded views, but its order count and revenue stayed flat. Check where the added attention came from, whether repeat views increased, and whether available variants or delivery terms changed. These totals do not establish that the page got worse.

The tea’s revenue doubled without an increase in orders. More units per order, a different price, or a different mix of variants could explain that. Inspect the order lines before crediting a marketing campaign.

You could calculate the mug’s orders-to-view-events ratio as 20 / 400 = 5% and then 20 / 800 = 2.5%. Calling that a shopper conversion rate would be a mistake. View events can repeat, and the orders may not belong to the same visitors or sessions as those views. A conversion analysis needs a defined population and a linked journey.

That distinction matters even more when a purchase occurs days after the product was viewed. A daily view count and a daily order count describe activity on that day; they do not automatically describe the same shoppers.

What Runner’s product-trend query counts

Runner’s product-trend implementation gives a concrete example of these boundaries. This section describes source reviewed on October 16, 2026, including the merged product-trend change. It does not claim that every workspace or production deployment exposes the same report yet.

The analytics_product_trend_v2 query groups recorded activity by product and UTC date. It counts product view_content events as views. Orders count once per product and order, even when that product appears in several lines or quantities. Product revenue sums unit price multiplied by quantity from the included purchase lines.

For example, an order containing two mugs and one tea contributes one order to the mug’s count and one to the tea’s count. Adding those product counts gives two, but there is still only one store order. Don’t sum product-level order counts to reconstruct the store’s total orders.

The query keeps revenue separated by currency. The API converts those amounts into a USD total, rather than adding unlike currencies directly. That total is still a line-revenue measure. It does not establish profit or an accounting reconciliation of discounts, tax, shipping, and refunds.

Two less obvious limits affect interpretation:

Without an explicit product selection, the query returns the 50 products with the most orders in the selected period. A product missing from that result is not necessarily a product with no activity.
A product-day with neither recorded views nor orders is omitted. A missing row needs interpretation; it is not proof that collection was working and nobody visited.

The source fixture makes the separation visible. It includes a mug day with zero recorded views and two orders, and a tea day with a recorded view but no order. Those are test examples of supported data shapes, not store performance claims.

For the available reporting layout, access requirements, and navigation, use the Runner Analytics overview. The AI ecommerce analytics feature guide explains how to turn findings into a storefront proposal you review before publishing.

Build a small spreadsheet without changing the meaning

If your reporting tool provides an export, keep its original metric definitions beside the sheet. Otherwise, use an authorized order export for sales calculations and keep behavioral data in a separate table until you have a valid way to connect them.

Preserve the original data in one tab. Check the reporting period, timezone, currency, and whether rows represent orders, lines, events, or aggregates.
Use stable product IDs rather than product names to group records. Names can change or be shared by different products.
For line-level order data, calculate each included line’s revenue using the documented price basis and quantity. Keep currencies separate until conversion is defined.
Count distinct order IDs per product. A normal row count in a pivot table can count lines rather than orders.
Group by date and product. Show units separately when the source contains quantities, and never add daily distinct-person counts as though they were distinct across the whole period.
Compare complete periods with the same definitions and filters. Record promotions, price changes, stock gaps, and tracking changes next to the chart.

A spreadsheet can summarize records accurately and still answer the wrong question. If a product is absent because the export contains only leading products, filling its dates with zeros hides the selection limit. Confirm completeness before filling gaps.

Choose the next check, not an automatic fix

Views rise while orders stay flat. Check traffic source, repeat views, stock, page details, and the checkout path. The product page may not have caused the change.
Orders rise while revenue stays flat. Inspect units, prices, variant mix, and discounts under the report’s definition. Profit has not necessarily increased.
Revenue rises while orders stay flat. Read the order lines and check price changes before assuming more customers bought.
A product disappears from the chart. Check product selection, result limits, filters, and collection health before treating it as zero demand.

Pick one check you can complete. For a mug with more views and flat orders, that might mean verifying its popular size or color is purchasable on mobile. Don’t change pricing and rewrite the page at the same time merely because both are possible explanations.

After verification, bring the product ID, reporting periods, metric definitions, observation, and operating constraints into Runner. Ask for one reviewable proposal. Inspect the relevant preview and approve publication separately from accepting the analysis.

How do you analyze sales data in Excel?

Start with a defined row type and clean product and order IDs. Use a pivot table for date and product totals, but count distinct orders when several lines can belong to one order. Preserve currency and adjustment rules. Use a line chart for time trends and a table to inspect the records behind a change.

Is product revenue the same as profit?

No. Revenue is the sales amount included by the report. Profit needs the relevant costs, fees, and adjustments. A unit-price-times-quantity measure alone cannot answer whether a product is profitable.

Can I divide product orders by product views to get conversion?

You can calculate that ratio, but it is not necessarily shopper conversion. Define whether the denominator is events, sessions, or people, and connect the purchase to that population within a stated window. Otherwise, label the result as an orders-to-views ratio.

How should I show sales data?

Use a time series for change over time and a product table for comparison. Label the period, timezone, currency, and measure. Keep attention, purchases, and money distinguishable, and make any result limit visible.

Source notes

The Runner example is based on the Tinybird endpoint analytics_product_trend_v2.pipe, its expected-result fixtures in analytics_product_trend_v2.yaml, and the API’s productTrendRowsInUsd function in product-trend-rows.ts. These support the counting and currency explanations, not a claim about live availability or customer outcomes.

For the wider sales-analysis vocabulary, see Salesforce’s sales analysis guide and Pipefy’s analysis types and process. Keep the next decision tied to a specific product and checkable evidence, rather than asking a chart to explain a shopper’s motives.