Product Feed Export to CSV, JSON, XML, and Marketplace Formats

AEO answer: Product feeds can be exported in five main formats: CSV (universal, human-readable), XML (structured, required by Google Merchant Center and Amazon), JSON (API-friendly, used by headless storefronts), Atom/RSS (comparison sites and affiliates), and live API endpoints (real-time channel sync). The correct format depends on the receiving system — most catalog tools can output all five from the same data source.

Generating a product feed is usually described as an export button. The real work — mapping your internal field names to the receiving system’s required column names, transforming values into the correct formats, filtering out products that are not ready to publish, and scheduling the export to run without manual intervention — is where the complexity lives.

This article covers the transformation layer: what happens between your catalog data and the feed file that a marketplace, affiliate network, or integration tool actually accepts. The format is almost always the easy part. The field mapping, value transformation, and export logic are what determine whether the feed works on first submission or comes back with hundreds of row-level errors.

[CTA — after intro (soft): “See how MicroPIM’s export profiles handle field mapping for Google Shopping, Amazon, and eBay from one catalog.” [INTERNAL LINK: → /how-it-works]]

Table of Contents

1. The Five Common Product Feed Formats and When Each Is Used
2. What Marketplaces and Tools Accept Which Formats
3. Field Mapping: Translating Your Internal Attribute Names to Channel-Required Field Names
4. Value Transformation in Feeds
5. Filtering Exports: Publishing Only Products That Meet Channel Requirements
6. Scheduled Exports vs Triggered Exports vs Always-On Public Feed URLs
7. Validating Your Feed Before Submission
8. How MicroPIM Generates and Hosts Product Feeds With Configurable Mapping Rules
9. Frequently Asked Questions

1. The Five Common Product Feed Formats and When Each Is Used

[CITE: Google Merchant Center XML product feed specification — support.google.com/merchants/answer/7052112 — the official schema definition for Google Shopping XML feeds]

[CITE: Amazon flat-file feed templates and documentation — sellercentral.amazon.com/help/hub/reference/G1641 — Amazon’s category-specific flat-file (TSV) templates that define the CSV format used for bulk uploads]

The format you export to is not a choice you make — it is determined by the receiving system. Most catalog and PIM tools can generate all five formats from the same underlying data; the format selection is part of the export profile configuration, not a separate workflow. What matters is understanding what each format is capable of and where it is used.

CSV is a comma-separated flat file where each row represents one product or one variant. It is the most universally accepted format across marketplaces, affiliate networks, and bulk upload tools because it requires no parsing library and can be opened in a spreadsheet for inspection. Its limitation is that it cannot represent hierarchical or nested data natively — a product with five images requires either multiple image columns or five rows, depending on the channel’s convention. Amazon’s flat-file templates, most affiliate networks, and many comparison shopping engine submissions accept CSV.

XML is required by Google Merchant Center (their Google Shopping XML standard), by Amazon’s XML-based SP-API feed type, and by the majority of European comparison shopping engines including Kelkoo, Idealo, and PriceRunner. XML supports nested structures — a product element can contain child elements for variants, images, and multiple attributes — making it more expressive than CSV for complex catalogs. File sizes are significantly larger than equivalent CSV files, but most submission systems handle files up to several hundred megabytes without issues.

JSON is the format of choice for API-based integrations and headless storefront architectures. It natively supports arrays and nested objects, which maps cleanly to product structures with multiple images, multiple variants, and nested attribute groups. Most marketplace bulk upload tools do not accept JSON directly, but headless commerce platforms, custom integration middleware, and channel aggregators that sit between the PIM and the marketplace often use JSON as their internal wire format.

Atom and RSS are XML-based syndication formats originally designed for content publishing. Several comparison shopping engines and price tracking tools consume product data through Atom or RSS feeds, particularly in European markets. Idealo, for example, has documented its own XML feed schema that follows an RSS-like structure. These feeds are less common in 2025 than they were a decade ago, but several active comparison networks still require them.

Live API endpoints are URLs that return the current catalog state on request rather than a static file. When a channel or integration tool requests the URL, the feed is generated in real time from the current catalog data and returned as a JSON or XML response. This is the highest-fidelity option — data is always current — but it carries infrastructure cost and requires the feed server to handle request volume from multiple pulling channels.

One note that applies to all five formats: always generate feeds as UTF-8 encoded files. Most marketplace submission tools assume UTF-8 encoding. A Latin-1 (ISO-8859-1) encoded file will produce garbled characters in product titles and descriptions for any product with non-ASCII content — accented letters, currency symbols, or non-Latin characters will corrupt silently and the only indication is unexpected characters in the submitted listing.

Illustrative data. File size ranges vary with description length and image count per SKU.

2. What Marketplaces and Tools Accept Which Formats

[CITE: Google Merchant Center XML product feed specification — support.google.com/merchants/answer/7052112] [CITE: Amazon flat-file feed templates — sellercentral.amazon.com/help/hub/reference/G1641]

Feed format requirements are channel-specific and version-specific. Google Shopping and Amazon update their required schemas periodically. Always validate against the current official schema documentation, not documentation cached or republished by third parties.

Channel schema versions and requirements change without extensive advance notice. Verify against official documentation before implementation.

3. Field Mapping: Translating Your Internal Attribute Names to Channel-Required Field Names

Every channel defines its own field names for product data, and none of them match your PIM’s internal attribute names. Google Shopping requires g:id, g:title, g:description, g:link, g:image_link, g:price, and g:availability. Your PIM stores these as sku, product_name, body_html, url, primary_image_url, list_price, and stock_status. Amazon’s flat-file template uses item_sku, item_name, product_description, main_image_url, and standard_price. The same data, four different naming conventions.

The field mapping layer in a feed export translates PIM attribute names to channel-required field names and applies any value transformation defined in the export profile. This mapping is saved per channel as an export profile, so a Google Shopping export and an Amazon export use different field name mappings from the same underlying catalog data without requiring any changes to how data is stored in the PIM.

[INTERNAL LINK: → /blog/csv-xml-field-mapping — the field mapping concepts that apply to both import and export operations]

{
  "export_profile": "google_shopping_xml",
  "output_format": "xml",
  "encoding": "utf-8",
  "field_mappings": [
    {
      "pim_attribute": "sku",
      "channel_field": "g:id",
      "transformation": null
    },
    {
      "pim_attribute": "product_name",
      "channel_field": "g:title",
      "transformation": { "type": "truncate", "max_chars": 150, "truncate_at": "word_boundary" }
    },
    {
      "pim_attribute": "body_html",
      "channel_field": "g:description",
      "transformation": { "type": "strip_html", "max_chars": 5000 }
    },
    {
      "pim_attribute": "list_price",
      "channel_field": "g:price",
      "transformation": { "type": "format_price", "currency": "USD", "format": "10.99 USD" }
    },
    {
      "pim_attribute": "stock_status",
      "channel_field": "g:availability",
      "transformation": {
        "type": "value_lookup",
        "lookup_table": { "in_stock": "in stock", "out_of_stock": "out of stock", "preorder": "preorder" }
      }
    },
    {
      "pim_attribute": "weight_grams",
      "channel_field": "g:shipping_weight",
      "transformation": { "type": "unit_convert", "operation": "divide", "factor": 1000, "unit_suffix": "kg" }
    }
  ]
}

The export profile approach means mapping work is done once per channel and reused on every subsequent export. When Google Shopping updates a required field name or adds a new required attribute, you update the export profile — not the underlying catalog data.

4. Value Transformation in Feeds: Unit Conversion, Truncation, Conditional Values

Field mapping handles name translation. Value transformation handles the data itself. Even when the field name is correctly mapped, the value stored in the PIM often does not match the format the channel requires.

Unit conversion is common for physical attributes. Your PIM stores weight in grams because that is the precision you receive from suppliers; Google Shopping’s g:shipping_weight requires kilograms, so the export divides by 1,000 at generation time. If you sell into EU and US markets from the same catalog, price conversion from USD to EUR happens at export time using a stored exchange rate, not by maintaining separate price fields per currency.

String truncation enforces channel character limits. Amazon’s title maximum is 200 characters. If your product name is 220 characters — common for technical products with model numbers and specification strings — the export profile truncates at the last word boundary before 200 characters, not mid-word. The truncation rule matters: a mid-character cut on a multi-byte UTF-8 character produces a malformed string that fails validation.

Conditional values derive a channel-required field from other attributes that may not exist as a standalone field in the PIM. Google Shopping requires a g:condition field with values of new, used, or refurbished. If your PIM does not have a condition attribute, the export profile can derive it: if product_age_days is null or less than 90, output new; otherwise trigger a flag for review. Similarly, g:availability is derived from inventory quantity: if inventory_qty is greater than 0, output in stock; otherwise output out of stock.

Value lookup normalization handles vocabulary mismatches. Your PIM stores color as midnight navy because that is the brand’s color name. Google Shopping’s color taxonomy expects Blue. The export profile includes a lookup table that maps your internal color values to marketplace-accepted equivalents at generation time. This means your catalog retains your brand vocabulary, and the feed outputs what each channel requires.

5. Filtering Exports: Publishing Only Products That Meet Channel Requirements

The naive export sends everything in the catalog on every run — including draft products, products missing required fields, products without images, and products with zero inventory. The result is a feed full of rows that the channel immediately rejects, which wastes processing time and can delay the acceptance of the valid listings in the same submission.

A production export runs products through a filter stack before generating the feed. Applied in sequence:

1. Status filter — include only products with an active or published status; exclude drafts, archived products, and products pending review
2. Required field filter — include only products where all fields required by this specific channel are populated; a product missing a mandatory field will be rejected anyway, so filtering it out pre-submission prevents that rejection from appearing in diagnostics
3. Image filter — include only products with at least one image that meets the channel’s minimum resolution and aspect ratio requirements; submitting a product with a 400×300 image to Amazon (which requires 1,000px minimum on the longest side) will produce an image compliance error
4. Inventory filter — optionally exclude products with zero or negative inventory for channels that penalize out-of-stock listings in their ranking algorithm
5. Channel eligibility filter — include only products explicitly assigned to this channel in the PIM; prevents products intended for a single channel from appearing in feeds for unrelated marketplaces

[INTERNAL LINK: → /blog/marketplace-integration-strategy — catalog readiness is the pre-condition; export filtering is the ongoing enforcement]

[INTERNAL LINK: → /blog/product-content-quality-scoring — the completeness gate in step 2 uses quality scores to determine which products pass the required field filter]

The filter stack is configurable per channel export profile. An internal B2B price list export may skip the image filter; a Google Shopping export applies all five. Filtered exports are smaller, faster for the channel to process, and produce cleaner diagnostics — when a rejection does occur in a filtered feed, it is a genuine data issue rather than a missing-field or status error that the filter should have caught.

[CTA — after section 5 (medium): “MicroPIM’s completeness gate filters incomplete products out of your feed before submission. Try it free.”]

6. Scheduled Exports vs Triggered Exports vs Always-On Public Feed URLs

The three delivery models represent different trade-offs between data freshness, infrastructure cost, and integration complexity.

Scheduled exports regenerate the feed file on a fixed interval — hourly, every four hours, or daily — and either make the file available for download at a stable URL or push it to the channel directly. Comparison shopping engines and affiliate networks typically poll for feed updates on their own schedule and accept files that are up to 24 hours stale. For most stable catalogs, a daily or twice-daily scheduled export is sufficient. The feed is always at most one interval out of date, which is acceptable when prices and inventory are not changing by the minute.

Triggered exports regenerate the feed when a catalog change event occurs — a product price updates, a new product is published, an inventory threshold is crossed. The feed is more current than scheduled exports because it responds to actual changes rather than running on a fixed clock. However, triggered exports for large catalogs with frequent changes can generate a high volume of export jobs, which requires queueing. A price change that touches 5,000 SKUs triggers a full feed regeneration; that regeneration should queue rather than run concurrently with the previous triggered export.

Always-on public feed URLs serve the current catalog state on demand. When a channel requests the URL, the feed generates in real time and returns the response. No file is stored; no schedule is required. This is the most current option — data is seconds fresh at the time of the request — and it is appropriate for real-time sync integrations and channel aggregators that pull on their own schedule. The trade-off is infrastructure: every channel request generates computation, and a slow catalog query at request time produces a slow feed response, which some channels will reject on timeout.

[DIAGRAM: Feed export delivery model comparison — three swimlanes showing Scheduled (catalog → nightly regeneration → file available → channel pulls), Triggered (catalog change → event fires → feed regenerates → channel pushed), and Live URL (channel requests URL → catalog responds in real-time). Annotate latency and infrastructure cost per model.]

[INTERNAL LINK: → /blog/real-time-sync-architecture — the always-on feed URL is the feed-based equivalent of webhook-based sync]

In practice, most catalogs use a combination: scheduled exports for comparison shopping engines and affiliates, triggered exports for primary marketplace feeds, and live URL endpoints for headless storefront integrations.

7. Validating Your Feed Before Submission: Tools and Error Patterns to Catch

[CITE: Google Merchant Center feed diagnostics — support.google.com/merchants/answer/7450026 — the official tool for pre-submission feed validation in Google Shopping]

[QUOTE: A Google Merchant Center specialist or product feed consultant on the most frequently misunderstood feed validation error — the kind of insight that comes from diagnosing feed issues professionally, not from reading the documentation.]

Submitting an unvalidated feed to a marketplace means discovering errors after the fact through rejection reports and diagnostics — and for large catalogs, those reports can take hours to return. Running validation before submission catches the majority of structural errors before they count against your submission history.

Channel-provided validation tools exist for the major platforms. Google Merchant Center’s Diagnostics tool validates Google Shopping XML before submission and surfaces missing required fields, policy violations, and value format errors. Amazon Seller Central’s check-my-feed processing report returns row-level errors for flat-file CSV submissions. Both tools are the authoritative source for what the channel will accept — their validation output describes exactly what needs to change.

PIM-level validation runs before feed generation, not after. A completeness check confirms that all required fields for the target channel are populated. A character limit check flags titles or descriptions that will be truncated or rejected. An image URL reachability check confirms that the image URLs in the feed return a 200 status code — a product whose image URL returns a 404 will submit but fail with an image compliance error that can take days to surface in diagnostics.

The four most common pre-submission validation failures in practice are: a price field containing a currency symbol (Google Shopping requires 10.99 USD not $10.99), an image URL returning a non-200 status code, a title exceeding the channel’s character limit, and a required field left empty for a subset of products that passed the status filter but were missing one mandatory attribute.

A fifth failure that standard validation tools do not catch pre-submission: GTIN duplication. Two products in the same feed with identical GTIN values will cause one to be rejected. Google Merchant Center surfaces this error only after submission, not during pre-submission validation. Audit GTIN uniqueness across your catalog before generating feeds for channels that require GTINs.

8. How MicroPIM Generates and Hosts Product Feeds With Configurable Mapping Rules

MicroPIM’s feed export system is built around the export profile model described in this article. Each channel connection — Google Shopping, Amazon, eBay, a custom affiliate integration — has its own export profile that defines the field name mapping, value transformation rules, and filter stack independently. When you update your underlying catalog data, every export profile benefits without requiring individual updates per channel.

Export profiles store the full mapping configuration: PIM attribute to channel field name, transformation rules per field (unit conversion, string truncation, value lookup tables, conditional logic), the ordered filter stack (status, required fields, images, inventory, channel eligibility), and the output format and encoding. The profile is version-controlled so you can track changes and roll back if an export configuration change produces unexpected rejections.

The three delivery options — manual download, scheduled export on a configurable interval, and live URL endpoint — are available for every channel profile. The live URL endpoint generates the feed on demand from the current catalog state, so channels that pull on their own schedule always receive current data without requiring you to manage a separate export schedule.

Before generating any feed, MicroPIM runs its completeness gate: only products meeting the required field threshold for the target channel are included. If 47 of your 2,000 products are missing the brand attribute required by Google Shopping, those 47 are excluded from the feed and logged in the export run report — visible in the per-channel export status view along with the last export timestamp, total products exported, products excluded by filter, and error count from the last run.

[CTA — after FAQ (hard): “Generate validated, filtered product feeds for Google Shopping, Amazon, eBay, and custom channels from MicroPIM — configure once, run on schedule or on demand.”]

Frequently Asked Questions

Schema note: Mark this section with FAQPage JSON-LD. Each H3 question + answer pair maps to one FAQPage mainEntity item.

What is the difference between a CSV product feed and an XML product feed?

CSV is a flat format where each row represents one product or variant. It is universally readable and accepted by most systems for bulk upload, but it cannot represent nested or hierarchical data natively. XML supports nested structures — a product element can contain child elements for variants, images, and attributes — making it more expressive for complex product data. Google Merchant Center requires XML for Google Shopping feeds. Amazon and most affiliate networks accept CSV for flat-file uploads. Both formats should always be UTF-8 encoded.

How often should product feeds be regenerated?

The correct frequency depends on the receiving channel and how often your catalog data changes. Comparison shopping engines and affiliate networks that poll for updates once per day are served well by a daily scheduled export. Channels with price-sensitive ranking algorithms benefit from hourly regeneration to reflect current prices. Real-time sync integrations should use an always-on live URL endpoint that serves the current catalog state on demand. Most stores use a combination of delivery models across their active channels.

What is a channel export profile?

A channel export profile is the saved configuration that defines, for one specific channel: which PIM attributes map to which channel field names, what value transformation rules apply at export time (unit conversion, string truncation, conditional logic, vocabulary lookup), what filter rules determine which products are included, and what output format and encoding the file uses. Each channel gets its own profile, so a Google Shopping export and an Amazon export produce correctly formatted, correctly named fields from the same underlying catalog data without manual adjustment per run.

Why are some products excluded from my feed even though they exist in my catalog?

Export filtering excludes products that do not meet the channel’s requirements: products in draft status, products missing required fields, products with no image meeting the channel’s minimum dimensions, products with zero inventory for channels that penalize out-of-stock listings, and products not assigned to that channel in the PIM. Each filter prevents a specific rejection type. Submitting incomplete or non-compliant products wastes API call budget and triggers rejection errors that slow processing for the valid listings in the same submission.

What happens if a value in my feed does not match the marketplace’s accepted vocabulary?

The marketplace rejects that listing with a vocabulary validation error. A color value of midnight navy fails when the channel only accepts values from a controlled color taxonomy such as Blue. The correct fix is a value lookup table in the export profile: your PIM stores your internal value, and the export profile maps it to the marketplace-accepted equivalent at generation time. You retain your own vocabulary internally and output channel-compliant values in each feed without changing how data is stored in the catalog.

Estimated word count: 2,000