A product can be correct in the source catalog and still arrive in a storefront with the wrong price, a missing image, an unavailable variant, or a broken category. The problem is rarely the final storefront alone. It is usually a data path that moved information without checking whether the information was complete, current, and usable at each step.
Product feeds deserve the same quality discipline as CRM imports, payment events, and analytics data. Before a catalog update reaches an ecommerce site, marketplace, advertising channel, or search index, the feed should be checked against explicit rules. That means verifying more than whether a file was generated or an API request returned a successful response.
This guide explains a practical product feed QA workflow that teams can use whether their catalog moves by CSV, XML, JSON, scheduled export, webhook, or API.
Start with the product identity
Every feed record needs an identifier that remains stable as the product moves between systems. A title is not an identifier. A SKU may be an identifier in one platform and a variant-level identifier in another. A vendor’s item number may also change when a catalog is reorganized.
Before validating the rest of the record, decide which field identifies:
- The parent product
- Each purchasable variant
- The source-system record
- The destination-system record, if it is different
Then document how those identifiers map. If a red shirt in three sizes becomes three destination records, the relationship between the parent product and its variants should be explicit. If a product is renamed, the identifier should not silently change just because the title changed.
Stable identity supports safe updates, deduplication, and reconciliation. Without it, a sync may create a second product instead of updating the existing one, or it may overwrite the wrong variant while still reporting success.
Check required fields before transformation
The source catalog and the destination feed do not always require the same fields. A source system might allow a product without a short description or image while a marketplace feed rejects it. A destination may require a currency, availability value, or brand even when the internal catalog treats those fields as optional.
Create a field-level contract for the feed. For each field, define:
- Whether it is required, optional, or conditionally required
- Its source field
- Its expected type and format
- Its allowed values
- Its fallback behavior
- What happens when validation fails
Typical checks include a non-empty identifier, a valid product URL, an approved currency code, a non-negative price, a supported availability value, an image URL that resolves, and a category that maps to an accepted destination value.
Conditional rules matter. A sale price may be optional, but when it exists it should be less than the regular price and have a valid start and end window. A variant may require a size or color only when the parent product is configured as variable. A digital item may not need shipping weight, while a physical item does.
The goal is not to make every system use identical fields. The goal is to make transformations predictable and visible.
Validate the values customers will see
A feed can be structurally valid and still be commercially wrong. A JSON document can parse correctly while a price is in cents instead of dollars, an inventory value is stale, or an image belongs to a different product.
Price and currency
Confirm the amount, decimal precision, currency, tax treatment, and sale-price logic. If one system stores integer cents and another expects a decimal amount, the transformation should be tested with known examples. Do not rely on a successful request to prove that the amount was interpreted correctly.
Availability and inventory
Define how source statuses map to destination values such as in stock, out of stock, preorder, or discontinued. Decide whether zero inventory removes a product, hides a variant, or leaves the record available for backorder. Test the boundary cases instead of only testing a normal in-stock product.
URLs and images
Check that URLs use the intended host, resolve over HTTPS, and point to the correct product. Image validation should include response status, content type, dimensions, and a reasonable file size. A URL can return a successful response and still serve an error page, a placeholder, or the wrong asset.
Categories and attributes
Map source categories and attributes to a controlled destination vocabulary. Log unmapped values rather than dropping them quietly. A missing category can affect navigation, filters, advertising eligibility, and reporting.
Test the transformation, not just the source
Most feed errors appear during transformation. Common examples include trimming a leading zero from an item code, converting a blank value into the string “null,” flattening variants into a parent product, or applying a default category to every unmatched record.
Use a small fixture set that deliberately includes:
- A normal product with one variant
- A product with multiple variants
- A product with missing optional data
- A product with a missing required field
- A product with a price change
- A product that is out of stock
- A discontinued product
- A product with an invalid image or URL
- A product with an unmapped category
- A record that already exists at the destination
For each fixture, compare the expected destination record with the generated output. These tests should run when mapping rules change, not only during a launch. A feed transformation is business logic, so it deserves repeatable tests and versioned documentation.
Separate rejected records from transport failures
A useful feed workflow distinguishes between different kinds of failure. A request can fail because the destination is unavailable. A record can be rejected because a required field is missing. A record can be accepted but later fail a downstream rule. Those cases need different actions.
At minimum, capture:
- Run ID and start/end time
- Source and destination
- Records read
- Records created, updated, skipped, and rejected
- Validation rule and field for each rejection
- Request or batch identifiers where available
- Retry count and final status
Do not place full customer data, private tokens, or sensitive internal notes into logs. A rejection log should help an operator fix the source or mapping without becoming an uncontrolled copy of the catalog.
Reconcile after the feed runs
The most important QA step happens after delivery. Compare what the source intended to send with what the destination actually stored or exposed.
Useful reconciliation checks include:
- Source record count versus destination create and update counts
- Expected identifiers versus destination identifiers
- Products that disappeared without an approved status change
- Prices or availability values that changed outside the expected window
- Variants with missing parent relationships
- Records rejected by the destination but marked successful by the integration
- Image and URL failures discovered after processing
Reconciliation does not mean the counts must always match. Filters, discontinued products, and destination-specific eligibility rules can explain differences. The important part is that differences are expected, documented, and reviewable rather than silently accepted.
A practical release checklist
- Can every destination record be traced back to a stable source identifier?
- Are required and conditional fields documented for each destination?
- Have price, currency, availability, image, URL, category, and variant rules been tested?
- Are invalid records rejected with a useful reason?
- Are retries safe, or could the same product be created twice?
- Can the team distinguish transport failure from record validation failure?
- Is there a report that compares source intent with destination results?
- Can someone review a sample of live or staged records before the feed is widely released?
If the answer to several of these questions is no, the feed is not ready for unattended operation. It may still be possible to run a controlled batch with human review, but that decision should be explicit.
Good feed QA protects more than product pages
Catalog data often feeds more than a storefront. The same product identity, price, availability, category, and image data may also reach advertising platforms, marketplaces, search tools, warehouse workflows, and analytics reports. An error introduced early can be repeated across every downstream channel.
That is why product feed QA belongs in the integration design, not as a last-minute inspection of the website. Define the data contract, test the transformation, log rejected records, and reconcile the result after every meaningful run. The workflow becomes easier to maintain because teams can see what moved, what did not, and why.
DigitalWerks helps organizations map data between platforms, validate business rules, and build monitoring around the integrations that support ecommerce and digital operations. If a catalog sync is producing hard-to-explain storefront or reporting issues, a focused feed review can show where the data path needs clearer rules.