How to Generate Product Descriptions From a CSV File
Key Takeaways
- You generate product descriptions from a CSV by exporting the catalog, mapping each CSV column to a prompt variable, running one reusable pipeline across every row, checking the flagged exceptions, then importing the approved descriptions back.
- Start with a filtered, SKU-keyed export that contains the factual attributes needed to describe each product.
- Validate every description for unsupported claims, duplicates, formatting errors, and missing requirements before import.
- Test the complete workflow on 20 to 50 representative products before processing the full catalog.
What you need first
Start with a CSV export from your shop, product information management system, or ERP. Each row should represent one product, while a stable identifier such as the SKU connects generated descriptions to the correct catalog records.
Your file should include the attribute columns that contain product truth. Typical inputs include product name, category, material, dimensions, color, compatibility, and other category-specific features. Add an empty output column such as generated_description so the workflow has a defined place to write results.
You also need a stable set of writing rules. Define the required tone, length, format, terminology, and restrictions on factual claims before generation begins.
Input quality sets the limit. A generator cannot reliably resolve blank, outdated, or contradictory attributes. Fix those rows or mark them as exceptions before running the batch.
Step 1: Export your catalog
Export only the records that need new descriptions. For a first run, that could mean products where the description field is empty, records from one category, or a controlled selection of active SKUs.
A filtered export is safer than starting with the entire catalog. It reduces the number of fields that could be changed accidentally and makes the first review queue manageable. Keep the SKU in every row, even if it will not appear in the final copy.
Shop systems commonly represent product attributes as CSV columns and products as rows. The Adobe Commerce product data attributes reference, for example, documents this structure and identifies SKU as the required product identifier.
Check that your export contains one clear header row and consistent columns. Remove unrelated operational fields when they are not needed for generation, but retain any field required for a safe re-import. For more detail on export and import controls, see Bulk Product Editor + CSV: The Automation Combo.
Step 2: Map prompt variables
Column mapping connects each field in the CSV to a variable in the reusable prompt. Static instructions remain the same for every product, while variables supply the values from the current row.
| CSV column | Prompt variable | Purpose |
|---|---|---|
| sku | {{ sku }} |
Tracks the output and supports the later import |
| product_name | {{ product_name }} |
Identifies the product in the description |
| category | {{ category }} |
Provides category context and writing rules |
| material | {{ material }} |
Supplies a factual product attribute |
| key_attributes | {{ key_attributes }} |
Provides the features that may be described |
A simple prompt might combine those variables with a fixed instruction:
Write a concise product description for {{ product_name }}.
Category: {{ category }}
Material: {{ material }}
Product attributes: {{ key_attributes }}
Use only the supplied facts.
Do not add certifications, performance claims, or specifications.
Return the description only.The prompt is written once and applied to each row. The variable values change, but the rules stay consistent. If you need a definition-level explanation of this pattern, read how to generate thousands of product descriptions from a spreadsheet.
A human should review the mapping before the batch runs. This review determines what the model is allowed to know about each product. It also catches dangerous mappings, such as connecting an internal note or supplier comment to a customer-facing description.
Step 3: Generate descriptions from CSV
Run one workflow across the selected rows instead of generating each product description manually. Every input row should produce an output in the same row, with the original SKU preserved. Row alignment prevents a correct description from being assigned to the wrong product.
Do not sort or restructure one side of the file after processing unless the complete table moves together. If outputs are stored separately, merge them back using the SKU rather than relying on row numbers alone.
Batch size involves a practical trade-off. Larger batches reduce repeated setup work, but they can create a larger exception queue and delay review. Provider costs also depend on the selected model, prompt size, product data, and generated output length.
bulkbase.ai is designed to run reusable pipelines across CSV rows while keeping structured inputs and outputs available for review. Users bring their own API keys, so provider token costs are passed through without markup. For non-urgent work, Eco Mode uses the provider's batch processing option to reduce token costs in exchange for a wait of up to 24 hours.
If you are still deciding which operating model fits your catalog, compare the options in Bulk AI Content Generation: 5 Tool Types Compared. For a closer look at the file handoff itself, see Bulk Content Creation Workflow (CSV In, Workflow, CSV Out).
Step 4: Validate descriptions
Generated text is a draft until it passes validation. Automated checks can identify predictable errors, but an operator must still decide how flagged rows are handled.
Check every batch against the following rules:
- Length and format: The output stays within the required range and follows the expected paragraph, bullet, or HTML structure.
- Factual accuracy: The text contains no invented materials, dimensions, compatibility claims, certifications, or product benefits.
- Duplicate copy: Sibling SKUs do not receive identical descriptions when their attributes differ.
- Clean output: No placeholders, prompt variables, template tokens, or operator instructions remain in the text.
- Required content: Mandatory phrases, terminology, or category-specific details appear where relevant.
- Traceability: Every factual claim can be traced to an input column or an approved static instruction.
Treat the exception queue as a required workflow stage. Each flagged row should be corrected and rerun, assigned for human writing, or deliberately excluded. Do not import rows that have not passed review.
Step 5: Import approved copy
Create a clean import file containing the SKU and only the fields you intend to update. In many systems, this means importing sku and description rather than sending every column from the original export.
Test the import with a small subset first. Confirm that each description reaches the correct SKU, expected formatting survives the round trip, and unrelated fields remain unchanged. Check the result in the shop or PIM rather than trusting the import confirmation alone.
Keep the pre-import export so the update can be reversed. After the test succeeds, import the remaining approved rows and re-export a sample to verify the stored values.
A reusable CSV structure makes the next batch easier. Keep the same identifiers, input columns, output field, prompt mapping, and validation rules unless a category requires a controlled variation.
Check before catalog scale
Run a pilot of 20 to 50 representative products before expanding to the full catalog. Include simple and complex products, sibling variants, sparse records, and products from each category covered by the workflow.
Use the pilot as a decision gate:
- Measure the percentage of rows that fail validation or require manual changes.
- Record the review time per row, including correction and rerun time.
- Confirm that the prompt works across the selected product types.
- Verify that the import can be reversed using a saved export or version history.
- Confirm that the team has enough review capacity for the expected exception volume.
If one category produces frequent errors, split it into a separate pipeline with its own inputs and rules. Do not weaken the shared prompt with a long list of conditional instructions that are irrelevant to most rows.
Scaling before the pilot has been validated is the most common way these projects fail. It turns a correctable mapping or prompt issue into a large review and cleanup task.
Common CSV generation mistakes
- Processing incomplete rows: Blank or contradictory attributes lead to vague copy or unsupported assumptions.
- Using one generic prompt: Different categories often need different attributes, terminology, and output structures.
- Skipping duplicate checks: Closely related products can receive copy that hides meaningful differences between variants.
- Importing before review: A technically successful batch can still contain factual or formatting errors.
- Treating output as final copy: Generated descriptions need validation, exception handling, and approval before publication.
Run a controlled first batch
Start with a narrow export, one reusable prompt, and explicit validation rules. Preserve the SKU throughout the workflow, import only approved rows, and expand only after the pilot meets your quality and review targets.
If you want to test the setup with bulkbase.ai, sign up free and run the workflow with your catalog structure. It stays free forever at 100 rows per month, and you bring your own OpenAI API key, so you pay OpenAI at cost with no markup from us.
