How to Build a Feed QA Checklist Before You Push Live

Feed QA checklist: why testing before publish matters

A feed QA checklist is the last gate between your product data and the channel that will approve or reject it. Most ecommerce teams validate their catalog internally but skip structured testing of the actual feed output — the file or API payload that Google Merchant Center, Amazon, or Meta will ingest.

The gap is costly. A single transform bug can silently drop a required attribute across thousands of SKUs. A price formatting issue can trigger mass disapprovals overnight. A category mapping error can misclassify an entire product line, tanking relevance and wasting ad spend.

These problems share one trait: they are detectable before the feed leaves your system. You just need a repeatable QA process that covers four areas:

1. Unit tests for individual feed transform rules
2. Schema and file-level validation of the generated feed
3. Pre-launch sampling to catch what automation misses
4. Post-publish monitoring and alerting to limit blast radius

If you need broader catalog data quality rules (field completeness, data types, cross-field logic), start with our catalog validation framework. This article focuses on testing the feed output and the pipeline that produces it.

Unit testing feed transforms

Feed transforms are the rules that convert your internal product data into a channel-specific format. Title templates, price currency formatting, availability mapping, GTIN normalization, category taxonomy lookups — each one is a function that takes an input and produces an output. That makes them testable.

What to test

Write unit tests for every transform that modifies a field value:

• Title templates — verify that a product with brand "Acme", name "Widget Pro", and color "Red" produces Acme Widget Pro - Red (or whatever your channel template expects)
• Price formatting — confirm that an internal price of 29.9 becomes 29.90 USD for Google or 29,90 for a European marketplace
• Availability mapping — assert that your stock status values (in_stock, backorder, discontinued) map correctly to the channel's accepted enum
• Category mapping — test that your internal category tree maps to the correct Google Product Taxonomy ID or Amazon Browse Node
• GTIN/EAN validation — check that 13-digit EANs pass a check-digit calculation and malformed values are flagged rather than silently exported
• Image URL construction — ensure that relative paths resolve to absolute URLs with the correct CDN domain

How to structure the tests

Keep feed transform tests isolated from your database and API calls. Each test should:

1. Create a minimal product fixture with only the fields the transform needs
2. Run the transform function
3. Assert the output matches an expected value

If a transform depends on external data (a taxonomy lookup table, for example), mock it with a small in-memory fixture. The goal is fast, deterministic tests that run in seconds and tell you exactly which rule broke.

Run these tests on every code change that touches feed logic. Even a minor refactor can flip a default value or change a string concatenation order.

Validating the generated feed file

Unit tests confirm individual transforms work. The next layer checks the assembled feed — the complete XML, CSV, JSON, or TSV file your system produces.

Schema validation

Every major channel publishes a specification. Use it as a machine-readable schema:

• Google Merchant Center — validate against the product data specification. Required fields include id, title, description, link, image_link, availability, price, and brand (or gtin). Character limits, accepted values, and conditional requirements (e.g., color and size required for apparel) should all be encoded as validation rules.
• Meta Product Catalog — check for id, title, description, availability, condition, price, link, and image_link at minimum, plus category-specific attributes for dynamic ads.
• Amazon — validate against the category-specific flat file template or the SP-API schema for your product type.

If you are not sure which fields to prioritize, our product data quality checklist covers the 30 most important fields across channels.

File-level checks

Beyond individual field validation, test the feed as a whole:

• Row count — compare the number of rows to the previous successful feed. A drop of more than 5-10% usually signals a bug, not a legitimate product removal.
• Required field coverage — calculate the percentage of rows with non-empty values for each required field. If image_link coverage drops from 98% to 72%, something broke upstream.
• Duplicate IDs — ensure no two rows share the same product ID. Duplicates cause unpredictable overwrites.
• Encoding and format — confirm the file is valid XML or well-formed CSV. A single unescaped ampersand in XML can cause the entire feed to be rejected.
• File size — a feed that is unexpectedly small (or unexpectedly large) deserves investigation before it ships.

These checks are straightforward to automate and should run every time a feed is generated. If your team uses a product data platform like Lasso, many of these validations are handled automatically as part of the enrichment and export pipeline — but having an independent check layer is still good practice.

Pre-launch sampling: the human layer

Automated tests catch known failure patterns. Sampling catches the rest — the edge cases that nobody thought to write a rule for.

How to sample effectively

Before pushing a new feed or a major feed change to a channel, pull a stratified sample from the generated feed file:

• By category — select 10-20 products from each top-level category. Category-specific attribute requirements differ, and mapping bugs tend to cluster within a category.
• By price tier — include products at the low, mid, and high ends. Price formatting, tax, and shipping logic often behave differently at extremes.
• By variant type — if you sell products with size/color variants, include parent and child records. Variant feeds are the most common source of structural errors.
• By change type — prioritize recently added or recently modified products. New imports and bulk edits are higher risk than stable records.

For a catalog of 10,000+ SKUs, reviewing 50-100 records manually is usually enough to spot systematic issues. You are not trying to review every product — you are trying to find patterns.

What to check in each record

Open the sample records side by side with the channel specification and verify:

• Titles read naturally and follow the channel's recommended structure
• Images load correctly when you paste the URL into a browser
• Prices match your storefront and include the correct currency code
• Availability reflects current stock status
• GTINs/MPNs are present where expected and absent for custom goods
• Category is accurate, not just "close enough"

Document any issues you find. If one pattern appears in more than two sampled records, it likely affects hundreds more. Fix the root cause in the transform, add a unit test for it, and re-generate.

CI/CD gates for feed pipelines

If your feed generation runs as a scheduled job or a build step, treat it like production code. Add CI/CD gates that block a bad feed from being pushed to a channel.

Gate structure

A minimal pipeline looks like this:

1. Build — generate the feed file from your current product data
2. Test — run unit tests on transform logic
3. Validate — run schema and file-level checks on the generated feed
4. Compare — diff the new feed against the last known-good feed. Flag large deltas in row count, field coverage, or value distributions.
5. Gate — if any check fails, block the feed from being submitted. Notify the team.
6. Deploy — push the feed to the channel (upload to SFTP, submit via API, update the hosted feed URL)

Practical tips

• Version your feeds. Keep the last 3-5 feed files so you can diff, rollback, or investigate when a channel reports an issue days later.
• Separate channel deploys. Do not bundle Google, Amazon, and Meta into one deploy step. A Google-specific bug should not block your Meta feed.
• Use dry runs. Google Merchant Center supports test feeds via the Content API. Meta lets you test a feed URL before activating it. Use these to validate on the channel side before going live.
• Set deploy windows. Avoid pushing feed updates during peak traffic hours. If something goes wrong, you want time to investigate before it affects shoppers.

For teams scaling across multiple channels, our guide on product feed management covers the operating model that keeps multi-channel pipelines sustainable.

Post-launch monitoring and alerting

Even with strong pre-launch QA, things break in production. Channel requirements change without notice. Upstream data sources drift. A scheduled job fails silently. Post-launch monitoring is the safety net that limits damage.

Key metrics to track

Set up dashboards or automated reports for these feed health indicators:

• Disapproval rate — the percentage of submitted products that a channel rejected. Track this daily. A spike means something changed in your data or in the channel's validation rules.
• Impression share change — a sudden drop in impressions can indicate feed issues before disapprovals appear.
• Feed processing time — if your feed takes significantly longer to process than usual, the channel may be encountering parsing errors.
• Row count over time — track the number of active, approved products per channel. A downward trend signals either intentional changes or silent data loss.
• Error category distribution — Google Merchant Center groups errors by type. Track the distribution, not just the total.

Alerting thresholds

Define clear thresholds that trigger alerts:

• Disapproval rate exceeds 5% of submitted products (or rises by more than 2 percentage points day-over-day)
• Row count drops by more than 5% compared to the previous feed
• Feed has not been updated within your expected cadence (e.g., no new feed in 25 hours for a daily feed)
• Any account-level warning from a channel dashboard

Route alerts to the person who owns the feed pipeline, not a shared inbox. For more on preventing channel-level issues, see our guide on fixing Google Merchant Center errors.

Your compact feed QA checklist

Here is the checklist you can adapt for your team:

Before first launch:

• Unit tests exist for every feed transform rule
• Schema validation runs against the channel spec
• File-level checks cover row count, required fields, duplicates, and encoding
• A stratified sample of 50-100 records has been manually reviewed
• A dry-run or test feed has been submitted to the channel
• Feed versioning and rollback capability are in place

On every feed update:

• CI/CD pipeline runs unit tests, validation, and comparison checks
• Large deltas in row count or field coverage block the deploy
• Feeds are deployed per channel, not as a single bundle

After launch (ongoing):

• Disapproval rate, row count, and staleness are tracked daily
• Alerting thresholds are configured with clear ownership
• Error distribution is reviewed weekly to catch slow-building issues
• Channel specification changes are monitored and rules updated

If you want to reduce the manual QA burden and catch data issues earlier in the pipeline, explore how Lasso handles feed validation and enrichment or book a walkthrough with the team.