Complaint volume is concentrated
Ranked complaint counts and shares by issue type
Post-market surveillance
Two persistent signals merit focused investigation
Firmware v2.0.1 and the Line A × Supplier Beta combination show the clearest differences in the complaint data.
10,000 complaint records
20 catalog products · 2025-01-01 to 2025-12-31
20 catalog products · 2025-01-01 to 2025-12-31
Complaint records
10,000
One row per customer complaint
Top-four issue share
61.5%
Complaint volume is concentrated
Firmware signal
2.64×
v2.0.1 Software Freeze concentration vs earlier versions
Process signal
6.49×
Line A × Supplier Beta Stitching Fray concentration vs elsewhere
⚠
Data-quality warning: 50.33% of complaint records require crosswalk review: electronics products are paired with clothing issues, while men's clothing products are paired with electronics issues. Product-level conclusions remain provisional.
Where is the burden?
Software Freeze is elevated in v2.0.1
Share of complaints classified as Software Freeze
The firmware gap persists across the year
Monthly Software Freeze share for known firmware versions
Stitching Fray clusters at one intersection
Share by manufacturing-line and supplier combination
Recommended priorities
Confirm severity and record accuracy before formal CAPA escalation. Run the two operational investigations in parallel.
01 · ENGINEERINGReview firmware v2.0.1Compare release changes, validation evidence and affected complaint records.
02 · QUALITY + OPERATIONSInvestigate Line A × Supplier BetaReview material lots, process settings, inspections and rework history.
03 · DATA GOVERNANCEReconcile the product crosswalkConfirm Device ID-to-catalog mapping before product-level prioritization.
Interpretation: Complaint shares are shown because production, sales, shipment and test denominators were not provided. These associations identify investigation priorities; they do not establish causation or CAPA urgency.
2 min read
Executive summary
What leadership should know, what deserves follow-up and where the data still needs work.
The review covered 10,000 customer complaints recorded in 2025 and linked them to the supplied product catalog. Four issues made up 61.5% of the log: Zipper Jam, Hem Unraveling, Button Loss and Stitching Fray. These are complaint shares, not true failure rates, because the data does not include the number of units manufactured, shipped or sold.
Two patterns deserve follow-up. Software Freeze appeared in 58.2% of v2.0.1 complaints, versus 22.0% for the earlier firmware versions. That is a 2.64× concentration, and the gap stayed visible throughout the year. A change introduced in v2.0.1 or a deployment condition shared by those complaints could explain the pattern. Engineering should review release changes, validation evidence and the related complaint records before deciding whether the firmware requires correction.
Stitching Fray also stood out at one specific operating intersection. It represented 41.2% of complaints for Line A with Supplier Beta, compared with 6.3% everywhere else. The broader line and supplier averages were not unusual, which suggests the combination matters more than either factor alone. Possible explanations include material compatibility, a Supplier Beta lot difference or a Line A process setting. Quality and Operations should compare material lots, settings, inspection results and rework history for that pairing.
Finally, the catalog join passed its technical checks but not its business-meaning check. 50.33% of records showed electronics products paired with clothing issues or men's clothing products paired with electronics issues. I would confirm the Device ID crosswalk before using product-category results for CAPA decisions. In parallel, I would investigate the two operating signals and add severity, exposure and lot information before deciding urgency.
Analysis approach
Data quality & methodology
I first checked the source data and join, then screened the operational fields and tested the two strongest patterns.
Excel quality log
10,000 complaint rows
10,000 complaint rows
Product Catalog API
20 product rows
20 product rows
SQLite model
fact + dimension
fact + dimension
SQL aggregation
counts + shares
counts + shares
Python validation
statistics + visuals
statistics + visuals
10,000 / 10,000complaint rows retained after validation; no removal or imputation was necessary
0 unmatchedDevice IDs after the left join; structural matching passed
50.33% reviewcategory-to-issue relationships flagged by the separate semantic check
01Define the unit of analysis
QuestionWhat does one row represent, and which metrics are valid?
ResultOne row is one customer complaint, not one manufactured or failed unit.
DecisionReport complaint counts, shares and concentrations. Do not label them true failure rates without an exposure denominator.
02Profile the raw sources
ChecksTypes, nulls, blank strings, duplicate rows and IDs, category labels, date parsing and humidity range.
Result10,000 unique complaints, 20 unique products, no missing or duplicate records, valid 2025 dates and plausible numeric ranges.
DecisionPreserve every source row. Keep literal N/A firmware values because they mean not applicable, not automatically missing.
03Model and validate the join
ModelComplaint fact table at one row per complaint; product dimension at one row per catalog product.
CheckLeft join Device_ID to Product_ID, then compare joined rows, distinct Complaint IDs and null Product IDs.
Result10,000 joined rows, 10,000 distinct complaints and zero unmatched IDs. The join passed structurally.
04Check business meaning
CheckCross-tab product category against transparent issue families, then inspect individual Device IDs.
ResultElectronics IDs carried clothing issues while men's clothing IDs carried electronics issues; 5,033 records require review.
DecisionDo not rewrite the source. Treat product-category conclusions as provisional and continue with original operational fields.
05Screen the operational factors
MethodFor each categorical group, compare an issue's within-group share with its share across the complete complaint log.
ChangesDerive complaint month from Date_Logged, group earlier firmware versions for comparison and calculate counts, shares and concentration ratios.
OutputA concentration ratio for every firmware, line, supplier, shift, certification, shipping and test-rig group.
Resultv2.0.1 × Software Freeze and Line A / Supplier Beta × Stitching Fray were the strongest actionable candidates.
06Challenge the strongest signals
ChecksDirect comparator groups, monthly persistence, line-supplier interaction and like-for-like Device ID comparisons.
ResultBoth signals persisted across all 12 months. The process signal remained within the same Device IDs, reducing device-mix concern.
MeaningThe patterns are not explained by one temporary month or simply by which devices were present.
07Measure strength, not only significance
StatisticsChi-square tested categorical association; Cramér's V measured effect size; Kruskal-Wallis evaluated humidity across issue groups.
ResultFirmware V = 0.356 and process V = 0.304. Other categorical factors were weak or unsupported; humidity p = 0.162.
DecisionPrioritize large, repeatable differences rather than small differences that happen to produce low p-values in a large dataset.
08State what the data cannot answer
MissingProduction and sales exposure, complaint severity, affected lots, patient-safety impact and investigation outcomes.
Can sayThe data identifies focused investigation priorities and associations.
Cannot sayIt cannot prove causation, calculate true failure rates or determine final CAPA urgency.
Data integrity review
The product crosswalk needs validation
Every key matched, but the joined records did not always make sense in business terms. Use the views below to inspect the mismatch.
50.33%of records have a category-to-issue relationship that needs review
3,049electronics-product complaints paired with clothing-related issues
1,984men's-clothing complaints paired with electronics-related issues
Product category × issue family
A correct ID match can still produce an implausible business relationship
Issue detail
Complaint mix for the selected product category
Why it stood out
A technically successful key match can still be wrong in business terms. The complete category-level swap was too systematic to dismiss as isolated complaint noise.
How it was discovered
After confirming row counts, uniqueness and unmatched IDs, I cross-tabulated catalog category against analyst-defined issue family and reviewed the relationships for semantic plausibility.
Why it matters
An incorrect or incomplete crosswalk could send product-level resources toward the wrong category and distort CAPA prioritization, complaint trending and executive reporting.
Recommended validation
Confirm Device ID-to-product mapping with the data owner and trace a sample back to source complaint records. Preserve the raw data and treat product conclusions as provisional.