QA processes for product data
Phase 2's audits find problems; QA prevents them from arriving. The distinction matters at scale because a 5,000-product catalog audited quarterly can accumulate a quarter's worth of new errors between passes - QA is moving the checks upstream, to where data enters and changes. Three layers: gates, rules, and sampling.
Entry gates: quality at the door
Most bad data arrives with new products - supplier imports, seasonal launches, rushed uploads (Phase 2's observation, now with a process answer). The gate: a definition of done per product category - the required attributes from your data model, image standards, description standards, category/collection assignment - enforced as workflow, not memory. Practical enforcements, in ascending rigor: a launch checklist in your PM tool (works at small team scale, decays with pressure); a draft-until-complete convention - products stay unpublished until they pass, with completeness checked before the publish step; and automated gating - a scheduled job (Matrixify export + rules, a Flow automation, or your enrichment platform's checks) that flags or holds products failing their category's requirements. Supplier data gets its own gate: an intake transformation (staging sheet or import recipe per supplier) that maps their columns to your model and rejects rows failing basics - because fixing supplier data before import is an operation; after import it's a cleanup, scattered across your live catalog. Phase 11's multibrand headache lives entirely in this paragraph.
Validation rules: encoding your model
Your data model (Phase 2) is a set of claims - "every garment has a material from this list," "every product has ≥3 images," "sale prices are lower than compare-at prices." Validation is those claims, run as checks. The mechanics are less important than the coverage: closed-list conformance (values outside the allowed list - the consistency doctrine, automated), completeness per category, format checks (GTIN checksums, handle conventions, title length bounds), and cross-field logic (published products in ≥1 collection; items marked "linen" whose composition field lacks linen - cheap contradictions to catch mechanically). Where to run them: enrichment platforms and PIMs have validation built in; the lightweight version is a weekly scheduled export against a rules sheet. Output discipline matters more than tooling: a short exception report, routed to an owner, drained to zero weekly - a 400-row report nobody clears is a dashboard, not a process.
Sampling: the human layer
Rules catch what you predicted; sampling catches what you didn't. The routine, borrowed from every mature quality discipline: weekly, one person spends twenty minutes on a rendered sample - five new products, five recently edited, five random - viewed as customers see them (product page, collection context, one downstream surface like the feed preview or a market translation). They're looking for what rules can't express: a description that's technically complete and reads wrong, images inconsistent with the set, a translation that's fine per-field and clumsy per-page. Findings feed two loops: fix the instance, and - the actual point - ask whether a rule or gate should have caught it. QA maturity is exactly that migration: surprises becoming rules, rules becoming gates, and the sampling hour staying interesting because it only ever catches new ways to be wrong.