Traffic falls, sales rise, and the weekly meeting reaches two different conclusions. Marketing sees a demand problem. Operations sees an improvement. Both are reading real numbers, but neither has yet explained what changed. The missing step is to separate visits, ordered units and realized sales per unit before deciding which team should act.
This guide to Amazon seller business report analysis is for operators reviewing their own sales and traffic, not estimating competitors' revenue. It provides a report-selection method, an original two-week example and a reusable review record. References were checked on September 10, 2026. Examples are fictional; use the report definitions and available views in your own marketplace when applying the method.
Quick answer: match the scope, explain the movement, assign the next check
Start Amazon business reports analysis with two comparable periods and a clearly defined product population. Examine sessions, ordered units and ordered product sales together. Identify the products contributing to the movement, distinguish observed changes from possible explanations, and assign a specific evidence check before editing listings, prices or advertising.
Five criteria make the analysis useful: matched scope, sufficiently complete inputs, a correct denominator, a traceable hypothesis and an accountable next step. A percentage without its numerator and denominator fails that test. So does a recommendation whose supporting export cannot be found.
For a small weekly review, an export and a checked spreadsheet may be enough. Add automation when the recurring work is stable; consider agent assistance when explaining exceptions and coordinating owners becomes the bottleneck. The objective is a decision someone can verify, not a longer AI-generated report.
Choose the report that answers the business question
Start with the change, then choose the level of detail
Write the question before downloading data: “Why did ordered sales decline for this product family over two comparable weeks?” is actionable. “Analyze the account” invites a summary of every column without a decision. A date-level view helps locate when a movement occurred; a product-level view helps locate where it occurred.
Amazon's official Sales and Traffic report schema distinguishes date aggregation from ASIN aggregation. It describes DAY, WEEK and MONTH date levels and PARENT, CHILD and SKU product levels. These are API report definitions, not a promise that every Seller Central screen presents identical controls. Amazon report schema.
Do not assume a product summary for a multi-day interval contains a daily series for each product. Inspect the export's actual keys. If the required product-by-day detail is absent, obtain an appropriate supported report or narrow the question rather than manufacturing daily rows from a period total.
Use parent context and child detail without adding both together
A parent-level view can be useful for a family question, while child-level detail can expose a change concentrated in one variation. A SKU-level operating question may require a separate mapping. Preserve the chosen level in the working file, and do not append parent totals to child records and sum the result.
Keep product mappings alongside the analysis. A renamed SKU or changed variation relationship can make a comparison appear to contain new demand when it actually contains a different grouping. If the mapping cannot be reconciled, flag the comparison as provisional.
Keep other reports available for questions this export cannot resolve
Sales and traffic can identify a symptom. Advertising reports, offer availability, price history and operational records may be needed to explain it. Profit requires a separate treatment of costs and adjustments. A sales export by itself should not become a payout forecast or a profit-and-loss statement.
Read the metrics without changing what they mean
The key distinctions below follow Amazon's field descriptions. Treat the meanings as a starting dictionary and confirm the exact fields in your export. Amazon sales and traffic field definitions.
Swipe horizontally to view all table columns.
| Metric | What to read | What not to conclude |
|---|---|---|
| Sessions | Visits grouped under the report's session definition | A sum across products is a deduplicated customer count |
| Page views | Page accesses, including repeat viewing | These are advertising impressions |
| Units ordered | Quantity ordered | This is the number of unique buyers |
| Total order items | Ordered line items, distinct from unit quantity | This is interchangeable with units or customer orders |
| Ordered product sales | Sales amount associated with ordered products | This is net profit or the next payout |
| Unit session percentage | Ordered units relative to sessions | This is precisely the percentage of people who purchased |
| B2B-specific columns | Measures scoped to Amazon Business customers | They should be added to an already inclusive total |
Calculate the unit-session ratio with the correct denominator
For the ordinary units-to-sessions calculation, divide units by sessions and multiply by 100. An illustrative 120 units against 100 sessions produces 120%. That arithmetic is possible because the numerator counts units, not unique purchasing people. It is not evidence that more than 100% of visitors became customers.
When the denominator is zero, display “not calculable” rather than a fabricated rate. When a field is absent, mark it unknown. Missing data and a recorded zero require different follow-up. A sudden extreme ratio should prompt inspection of the underlying values before interpretation.
Recompute combined rates instead of averaging percentages
Suppose two comparable, non-overlapping records contain 10 units from 100 sessions and 9 units from 900 sessions. Their row ratios are 10% and 1%. The unweighted average is 5.5%, but the combined numerator and denominator give 19 divided by 1,000, or 1.9%.
This calculation only makes sense when the records can legitimately be combined. It does not remove overlapping product populations, duplicate imports or differences in session scope. Label an aggregate as the ratio for the selected records, not automatically a unique-shopper conversion rate for the store.
Separate sales per unit from listed price and margin
Dividing sales by units creates a useful descriptive measure for a consistent population. Across several products, that measure can move because the product mix changed. It does not prove that the seller increased every price, and it says nothing by itself about unit costs.
Keep the wording precise in the summary: “Realized sales per ordered unit increased” is defensible from the calculation. “Our pricing strategy improved profit” needs additional evidence and a separate economic analysis.
Make the two periods comparable before looking for explanations
Fix the marketplace, population and calendar
Use the same marketplace and currency. Choose periods of equal length with a comparable weekday pattern, and record significant promotions or availability interruptions. A seven-day period and a partial current week are not equivalent simply because both are labeled “this week” somewhere in a dashboard.
For product analysis, make the population explicit: all current children of a family, a stable list of child ASINs, or another defined group. Where membership changed, show the stable-population comparison separately from the effect of additions or removals. Do not silently drop a missing product and describe the remainder as the same portfolio.
Record the export version and completeness
Save the report name, date range, filters, aggregation level and download timestamp. Preserve the original export separately from your working calculations. If a later export changes, compare versions instead of overwriting the only evidence supporting last week's conclusion.
Do not set one universal waiting period for every Amazon report. Check freshness and completeness for the specific source. Mark a recent interval provisional when required data is still developing; schedule a recheck rather than expressing false precision.
Prevent duplicate rows and segment double counting
Define a record key from the fields that actually identify a row, such as marketplace, reporting interval, product level and product identifier. Test for duplicates before joining another dataset. A many-to-many join can multiply sales even when every source file is correct.
For B2B analysis, verify which columns are segment-specific and which already contain all customers. Do not add a subset to its inclusive total. Keep specialized ratio definitions intact until their denominators have been confirmed; a familiar-looking column label is not sufficient evidence to rebuild its formula.
Worked example: traffic falls 20%, while sales rise 5.6%
Assume two complete seven-day periods for the same defined child-ASIN population in one US-marketplace export. All amounts below are USD. These invented figures demonstrate the reasoning; they are not an OpenMax customer result or an Amazon benchmark.
Swipe horizontally to view all table columns.
| Measure | Period A | Period B | Change |
|---|---|---|---|
| Sessions | 1,000 | 800 | −20% |
| Units ordered | 100 | 96 | −4% |
| Ordered product sales | $2,000 | $2,112 | +5.6% |
| Units ÷ sessions | 10% | 12% | +2 percentage points |
| Sales ÷ units | $20 | $22 | +10% |
State what the calculation establishes
The selected population recorded fewer sessions and fewer units, but more sales value. Units per session increased, and sales per unit increased. The ratio moved by two percentage points; its relative increase was 20%. Those are different descriptions, and neither should be shortened to an unexplained “conversion increased 2%.”
With aligned inputs and nonzero denominators, the arithmetic identity is sessions × units per session × sales per unit = sales. Here, 800 × 0.12 × $22 = $2,112. This is a way to check consistency, not a model proving which action caused the sales movement.
Identify the evidence that would distinguish explanations
Inspect whether lower-priced products lost a larger share of units, whether a promotion ended, or whether the same products changed realized price. Check availability over the period and whether the traffic decline was concentrated in particular children. Each possibility requires evidence outside the headline totals.
A useful follow-up is: “The offer owner will compare availability and price records for the affected children; the analyst will reconcile their contribution to the sales change.” An unjustified follow-up is: “Raise prices again because the report proves it worked.”
Write a summary that preserves uncertainty
The operating conclusion could read: “Sales increased 5.6% despite fewer sessions and units. Higher sales per unit offset the unit decline. We have not yet separated price effects from product mix. Review child-level contributions and the promotion calendar before changing spend.”
This summary is more useful than assigning a good or bad label to the whole account. It tells the next person what is known, what remains unresolved and what would change the decision.
Diagnose six patterns with evidence, not automatic fixes
Sessions decline: locate the affected products and dates
First establish whether the movement is broad or concentrated. Check completeness, availability and timing before deciding demand fell. Advertising delivery and other traffic evidence may help, but business-report sessions alone do not identify which acquisition source changed. Avoid equating every session loss with lost organic ranking.
The next check should name a population and interval: compare the affected children's availability and advertising delivery over the same dates, then record whether either explanation fits. If neither does, retain the unresolved finding instead of inventing a cause.
Sessions hold steady while the unit-session ratio declines
Confirm that the underlying unit count changed and that the traffic population is comparable. Then inspect offer conditions, variation availability and relevant detail-page changes. A different traffic mix can also change an aggregate ratio without any single page becoming worse.
Use the Amazon conversion-rate improvement guide for a focused follow-up. The business report identifies where to investigate; it does not establish which content edit will improve results.
Units decline but sales value rises
Separate a change in realized sales per unit from a change in product mix. Review child-level quantities and amounts rather than treating the family average as a universal price. Keep any margin conclusion outside this analysis until the necessary costs and adjustments are available.
If the team values unit availability or inventory movement as well as revenue, record that tradeoff explicitly. More sales value is not automatically success against every operating objective.
Availability or offer conditions changed during the period
Check the actual dates and affected products. A current screenshot cannot establish what shoppers could buy throughout last week. Compare the available historical evidence and mark gaps. Correlated timing can support a hypothesis, but it is still not a controlled causal test.
If the follow-up points toward detail-page readiness, use the Amazon listing audit checklist. Keep the observed reporting issue separate from any approved listing change.
One child changes while the parent appears stable
An aggregate can conceal offsetting movements. Show each child's absolute contribution to the change as well as its percentage movement. A large percentage on a tiny base may be less operationally important than a modest decline on a major product.
Do not automatically merge, remove or restructure variations because of this pattern. The immediate task is to verify the mapping and locate the movement, not make catalog-policy decisions from an aggregate report.
Data is missing, revised or incompatible
Pause the affected conclusion. Check export filters, row keys, period boundaries and whether a join changed the record count. Reconcile against an untouched source sample. If a required field remains unavailable, issue a partial review stating the missing evidence and next retrieval step.
An honest “not enough evidence to explain this change” is a valid outcome. A generated explanation built on mismatched records is not a substitute for the missing data.
Reconcile business reports with advertising and financial views
Advertising sales use attribution rules
Amazon explains that campaign conversions are reflected on the ad-interaction date and remain incomplete until the applicable lookback window ends. Product eligibility and interaction rules vary by campaign type. Consequently, two exports with identical visible dates can describe different populations of sales. Amazon Ads attribution guidance.
Before comparing, record each report's date basis, attribution maturity and product scope. Do not assume an advertised product and every attributed purchased product are identical. A mismatch is a reconciliation question, not immediate proof that one system is wrong.
Do not label a simple subtraction as organic sales
Subtracting ad-attributed sales from business-report sales can mix date bases and product populations. The residual is not automatically a measured organic-sales figure. If the required scopes cannot be aligned, show the two measures separately with their definitions.
For campaign-specific investigation, use the Amazon PPC audit checklist. This keeps advertising controls and targeting analysis in their appropriate workflow instead of hiding them inside a general sales review.
Keep ordered sales separate from settlement and profit
A payout or profitability question needs its own records and reconciliation. Fees, refunds, costs and posting timing cannot be inferred from a higher ordered-sales total. Route those questions to the finance owner with the reporting period and source evidence attached.
This boundary prevents an operational sales narrative from being reused as an accounting conclusion it was never designed to support.
Run a weekly review with a reusable evidence record
Use a sequence that another operator can repeat
- Define one question, marketplace, product population and comparable periods.
- Preserve the exports and record filters, aggregation and timestamps.
- Check missing fields, duplicate keys, currencies and joins before calculating rates.
- Compare absolute values, ratios and product contributions; identify the material movement.
- Separate the observation from hypotheses and specify the evidence needed to distinguish them.
- Assign a next check, owner and review date; record the result before approving a response.
“Material” should reflect the team's stated objective and actual scale, not a universal percentage copied from a checklist. Write down the review threshold if one is used, including how low-volume items and incomplete data are handled.
Copy this 12-field review record
Question: Why did sales rise while units fell?
Marketplace: US; defined seller account
Currency: USD
Periods: Two complete, comparable seven-day intervals
Report and grain: Named export; fixed child-ASIN population
Export timestamp: Record separately for each source version
Source locator: File, sheet and row identifiers
Observed change: Sales +5.6%; units -4%; sessions -20%
Calculation: $2,112 / $2,000 - 1; retain input cells
Hypothesis and missing evidence: Price versus mix; inspect child records
Owner and next check: Named analyst; reconcile contributions by review date
Outcome and review date: Confirmed, revised or unresolved; attach evidence
The figures belong to the fictional example, not default thresholds. Replace the record's scope with your actual comparison. Keep the underlying calculation visible; a polished narrative should not become the only surviving artifact.
Close or revise the finding
At the next review, record what the evidence established. If the original hypothesis was wrong, preserve the correction and explain why. If a change is approved, record its scope and decision owner separately from the analytical finding. A completed investigation and a successful business intervention are different outcomes.
Choose manual, native, scripted or agent-assisted analysis
Manual exports suit a narrow, occasional question
Use a spreadsheet when the population is small and one operator can verify the inputs. Keep the original file, label formulas and check a sample back to source. Stop when a required field or compatible comparison is unavailable. Manual work is a reasonable choice, not a failure to automate.
Native reporting keeps the first inspection close to the source
Use available report filters and product views to inspect the movement before building a separate pipeline. Record the chosen settings so another person can reproduce the view. Native reporting may not resolve cross-team context or combine the exact sources needed for an explanation; document those gaps rather than assuming a dashboard answers everything.
Scripted automation fits stable, defined transformations
Once the input structure is understood, automate duplicate checks, numeric parsing and repeatable calculations. Validate the output against a hand-checked sample. Reject unexpected currencies, missing identifiers and changed column structures; do not silently coerce them into zeros.
Keep acquisition and analysis separate. An existing export-processing script does not imply authorized API access. If the source changes, retain the last valid result with its date and flag the new run as incomplete instead of presenting stale data as fresh.
Agent assistance fits explanation and handoff, with verification
An agent can be considered for drafting an observation summary and proposing questions from approved inputs. Require each numerical statement to point to a source location or deterministic calculation. Have a person reject unsupported causes and check that the recommended next action matches the evidence.
Do not let the narrative stage recalculate critical totals by guesswork. Nor should it turn an analysis request into a price, campaign or inventory edit. For the broader operating pattern, see Amazon seller workflow automation.
Where OpenMax may fit the review workflow
Evaluate collaboration needs after the calculations are reliable
OpenMax positions its product around human–agent collaboration. For a team whose reporting problem is repeated handoff between analysts, offer owners and advertising operators, that positioning suggests a workflow worth evaluating: source-backed findings, assigned next checks and recorded decisions.
The proposed design here starts with an approved report summary and source references. An assistant drafts the observation and unresolved questions; the owner verifies the calculation and decides the next check. This is an editorial workflow proposal, not confirmation of a native Seller Central connector or a ready-made Amazon reporting application.
Validate the proposed setup before using business data
Ask the OpenMax team to demonstrate the required input handling, source references, access restrictions and review handoff for your setup. Use a minimized sample first. Keep credentials and unnecessary customer-level information out of the demonstration input, and have the relevant owner review data handling before a live rollout.
Assess whether the proposed workflow preserves evidence and corrections better than the current process. If it merely rewrites a spreadsheet into more paragraphs, it has not yet addressed the operational problem.
Keep the simpler method when it already works
One operator reviewing a few rows each week may not need a collaboration platform. A stable spreadsheet with clear ownership can be sufficient. A pilot becomes more relevant when unresolved findings cross teams or disappear between meetings, provided the actual product setup supports the required workflow.
FAQ: Amazon seller business report analysis
What should I check first in Amazon business reports?
Check the report scope and comparability before the performance numbers: marketplace, currency, period, product population and aggregation. Then compare sessions, ordered units and ordered sales together. This prevents an apparent performance change from being explained when the underlying comparison is actually different.
Are sessions the same as page views?
No. Sessions and repeated page viewing are different measures. Use the definitions attached to the selected report, and do not treat page views as advertising impressions or summed product sessions as a deduplicated count of store customers.
How do I calculate unit session percentage?
For the ordinary units-to-sessions measure, divide ordered units by sessions and multiply by 100. Keep both inputs in the review. A zero denominator is not calculable, and segment-specific measures require their own verified denominator rather than an assumed formula.
Can unit session percentage exceed 100%?
A units-to-sessions ratio can exceed 100% because units are not unique purchasers. The fictional calculation 120 units divided by 100 sessions gives 120%. Check unusual source values, but do not reject a ratio solely because it is above the limit that would apply to a probability.
Why are sales up when sessions are down?
Higher units per session or higher sales per unit can offset fewer sessions arithmetically. Determine whether product mix, realized price, availability or other factors changed before attributing the result to a specific action. Sales growth alone does not establish higher profit.
Why do business-report sales differ from advertising sales?
Advertising uses attribution rules, including an interaction-date basis and a lookback window, while the comparison report may have a different basis and scope. Check dates, maturity and eligible products before reconciling totals. Do not automatically call their difference organic sales.
Should I analyze parent ASINs or child ASINs?
Choose the level that matches the question: a family-level overview and a variation-level investigation serve different purposes. Preserve the mapping and avoid combining totals across hierarchy levels. Check the actual export rather than assuming every level contains the same time detail.
Can OpenMax automatically analyze my Amazon account?
This guide does not establish an automatic Amazon account connection. It describes a proposed review workflow that must be validated against available product capabilities, authorized inputs and team requirements. Start with a limited sample and verify source traceability and human handoff before considering a broader setup.
Next step: complete one review before expanding the workflow
Select one product population and two comparable periods. Fill in the evidence record, verify the arithmetic and assign one unresolved question to its owner. The initial success condition is a reproducible explanation or a clearly documented evidence gap—not an immediate sales increase.
If cross-team follow-through is the remaining difficulty, discuss the sample workflow with OpenMax. Bring the minimized input, expected output and review boundaries so the discussion can establish actual fit. Expand only after the team can reproduce the result and explain how corrections are handled.

