How to Analyse Customer Complaints by Product

To analyse complaints by product, establish which issue belongs to which item, choose a consistent counting unit, preserve uncertain matches, and compare like-for-like exposure where possible. Then review the underlying conversations before assigning a cause or choosing an action.

The output should distinguish reported customer experiences from confirmed defects. A complaint is valuable evidence, but it is not automatically proof of a manufacturing problem.

Set the investigation boundary

Choose a product family, period, issue definition, and source set. State whether you include open conversations, formal tickets, return reasons, or some combination. Do not silently mix them: the same experience may appear in several systems.

Decide whether the unit is a complaint case, affected order, customer, or product unit. Each can be useful. The report should state which one it counts and how duplicates are handled.

Match the product carefully

Use available authorised order context, a clear product link, a verified identifier, or sufficient conversation evidence. Images and informal names can help a reviewer, but they can also be ambiguous.

If a customer bought several items and says “one arrived damaged,” do not attribute the issue to every item. Preserve the case as unmatched until the relevant product is established. Keep a record of corrections so the reporting history can be explained.

Use this analysis table

Calculate a rate only when the populations match

Consider a fictional review with six matched complaint cases among 300 delivered orders containing one item. The case-to-delivered-order ratio is 2% under that matching rule. It is not necessarily a defect rate, because cases can concern expectations, handling, or another cause.

If some orders contain multiple units, order-based and unit-based rates differ. If a complaint arrives weeks after delivery, recent orders have had less time to produce feedback. Choose cohorts with a suitable observation window and disclose any lag.

Without a compatible denominator, publish counts and limitations. A precise-looking percentage does not repair missing exposure data.

Inspect the ranking before acting

Read examples from the highest-count issues, the highest-rate issues, and unmatched cases. Look for a shared batch, delivery service, unclear instruction, variant, or campaign promise. Record alternative explanations.

A useful cause statement is provisional: “The included cases cluster around the revised closure; quality operations will inspect the affected batch.” An unhelpful statement presents the supplier as responsible before checking evidence.

Customer feedback methods have a wider context in Shopify's voice-of-customer guide. The product matching, cohort, and denominator checks here are our recommended safeguards for this particular review.

Prioritise with more than frequency

Include severity, affected customers, exposure, confidence, and feasibility of action. A rare safety-related report may need immediate specialist handling under your existing policy even if it is not a top-volume theme. Do not wait for a weekly chart to address urgent harm.

For routine issues, select a small set of actions. Assign an owner and review date. Preserve the original customer remedy separately from the wider corrective action.

Recheck after the intervention

Use the same definitions and suitable cohorts. Confirm message collection is still working. Note changes in sales, channels, classifications, or product availability that could affect totals.

Record what improved, what did not, and what remains uncertain. The recurring complaint review procedure turns this analysis into a repeatable meeting rather than a one-off report.