Below is how mass generation of product cards is built: what must be in the table before the neural network is started, which fields can be generated and which cannot, what must be in the task for a series of hundreds of products, how the result is checked and loaded back into the catalog. At the end there is a checklist before upload.
First the main rule that everything else rests on: a neural network writes texts, but it does not invent data. Sizes, composition, weight and compatibility are taken only from the table. If they are not in the table, they must not be in the card either.
What must be in the table before generation
A neural network works with what it was given. If a product in the table has only a name and a price, a good description will not come out: the model will either write general words or start inventing characteristics.
The minimum worth collecting before generation:
- an SKU or another unique identifier by which the result returns to the right product;
- the category;
- the main characteristics in separate columns: material, size, color, weight, what is included — whatever matters in your category;
- the features that distinguish the product from its neighbors in the catalog;
- who the product is for and what it is for, if that is known.
How to prepare the product data itself for upload is a large topic of its own. Here one thing is enough: the table should not have empty cells where the neural network will look for facts.
Two more rules for the table that save time on checking. First: one value in one cell. If the “Size” column says “40×60, there is also 50×70”, the neural network may take either value or both at once. Second: the units of measure are the same throughout the column. Centimeters and millimeters mixed together are sometimes recalculated by the neural network and sometimes copied as they are, and the cards come out inconsistent.
Which fields can be generated
Not every field of a card is equally suitable for generation. It is convenient to mark them in the table in advance.
| Field | Source | Can it be generated |
|---|---|---|
| SKU, price, stock | The store’s data | No |
| Characteristics | The supplier’s or manufacturer’s table | No, only transferred |
| Name | Category plus key characteristics | Yes, from a template |
| Description | Characteristics plus features | Yes, with a fact check |
| The product’s Title and Description | Name plus the main difference | Yes, with a length check |
| Tags, collections | Category plus characteristics | Yes, from a given list |
Name
A product name is better generated from a template, not freely. For example: product type, brand or model, a key characteristic, color or size. The template sets the order, the neural network fills in the data and brings it to one form: the same abbreviations, units of measure and case.
Free generation of names gives inconsistency: one product is “White ceramic mug 350 ml”, the neighbor is “A white ceramic mug with a volume of 350 milliliters”. In the catalog that looks untidy and gets in the way of search.
Description
The description is the main field where a neural network saves time. It turns a list of characteristics into connected text: what the product is, how it is useful, how to use it. A good description answers the customer’s questions that the characteristics do not close.
The structure of the description is also better set in advance, otherwise each card will be built in its own way. For example: the first paragraph is what the product is and what it is for, the second is the features that distinguish it from its neighbors, the third is care or use, if that data is in the table. The same structure also makes checking simpler: the person checking knows where to look for each fact.
The risk is here too: in connected text, statements that are not in the data appear easily. “Suitable for a dishwasher”, “does not fade in the sun”, “hypoallergenic material” — a neural network may add this because that is how similar products are often described. For a particular product it may be untrue.
- Characteristics: only from the data.Characteristics are not generated. A neural network can bring them to one format: “35 cm” and “350 mm” in the same units, “100% cotton” and “cotton 100%” written the same way. But the value must be taken from the table. If a product has no weight stated, “about 500 g” must not appear in the card.
- The product’s Title and Description.Meta tags for product pages are a good task for generation: there are many of them, they are short and they follow clear rules. Title is usually built from the product name and the store name, Description from the product’s main difference and a reason to open the page.
A neural network does not always keep the length limits. It is simpler to check the length with a formula in the table than to read it by eye.
What must be in the task for a series
A task for a series differs from a task for one product: it must give the same result for hundreds of rows. It fixes which table fields to use, what exactly to write, of what length and in what tone, what is forbidden — promises of an effect, medical properties, comparisons with competitors, words the store does not use — and in what form to return the answer so that each row finds its product by SKU. The main rule in any such task is one: only facts from the data.
A sample works more strongly than any description of style: one card written the way all of them should look. If the catalog has several different categories, one task for all of them usually works worse than separate ones: for clothes, composition, the size chart and care matter, for tableware, volume, material and compatibility with appliances. Such a task almost never comes out right the first time: it is brought into shape on a trial sample, and experience is needed here — to understand why the model made a mistake and what to fix in the wording, and what in the data.
Batch generation
Hundreds of products should not be processed in one request. On a long list a neural network starts shortening, skipping rows or mixing up the data of neighboring products.
So generation goes in portions: first a trial sample of products of different types and edits to the task, then the rest, with the SKU kept in every answer and the number of rows checked after each portion. If there are many products and generation repeats regularly, it is automated: a script sends table rows to the neural network by API and writes the answers back. That is already a development task, and the logic of checking stays the same.
I keep the source data and the generated text in different columns. Then it is always possible to compare what was in the table and what the neural network wrote, and to regenerate individual cards without touching the rest.
The check before upload
The check is the most important part of the process. In its guidance on content created with generative AI, Google states directly that models can be wrong, and advises checking such content before publication, including metadata. It also says that mass creation of pages with no benefit for the reader can break the search rules on scaled content abuse. For Google Merchant Center, Google has separate requirements for product data created with AI.
What to check:
- the facts in the description match the characteristics in the table;
- there are no properties that are not in the data;
- the names are built from one template;
- the length of Title and Description is within the norm;
- there are no repeats: identical descriptions of different products look bad both for the customer and for search;
- there are no forbidden words or promises.
Part of the checks can be automated with formulas: length, forbidden words, matching SKUs, duplicates. Comparing facts can be given to a second pass of the neural network: it compares the source row with the finished description and looks for statements that are not in the data. But that does not replace a selective check by a person.
A practical order of checking looks like this. A person checks the first portion of products in full, row by row. If there are no errors, or they are single ones and the task has been corrected, a selective check is enough after that: several products from each portion, and of different types. If an error is found in the sample, the portion is checked in full.
Special attention goes to products with incomplete data. That is where a neural network most often invents: the material is not stated, and “natural wood” appears in the description. Such rows are convenient to mark in the table in advance and check all of them by hand.
Loading back into the catalog
When the texts are checked, they have to be returned to the catalog. How exactly depends on the platform.
In Tilda, catalog products are loaded from CSV or YML. On import the columns are matched to the catalog fields, and unused columns are ignored. For updating products that already exist there is a mode in which import only updates the data and does not create new products. If you run an online store on Tilda, this is the safest way to update the texts of a finished catalog.
Before upload I export the current catalog: if something goes wrong, there is something to return to. First several products are loaded and checked on the site, and only then the whole file.
If generating and loading cards is a regular task and there are not enough hands for it, it can be given to site content work.
A checklist before loading the cards
- Each product has a unique SKU, and it survived generation.
- Characteristics were transferred from the table, not generated.
- The descriptions have no properties that are not in the data.
- Names are built from one template.
- Title and Description were checked for length.
- There are no identical descriptions of different products.
- Source data and generated texts sit in different columns.
- The current catalog was exported before upload.
- A trial upload of several products went through without errors.
If you want to discuss generating cards for your catalog, take the quiz on mara-craft.com. I will look at the table and suggest where to start.