Catalog and product data

Most catalog questions are one of two things: a product the buyer cannot see, or an import that did not do what you expected. Both have a short list of causes, and both lists are ordered by how often each cause is the answer.

Why can a buyer not see a product that exists in the Cockpit?

Six causes, in the order to check them: the product is not enabled; it is in no category, so it cannot be browsed to although search may find it; it is below 100 % completeness for that channel and your storefront publishes only complete products; the search index has not caught up after a large import; it is restricted to a segment or assortment this customer is not in; or there is no price that resolves for this customer, and priceless products are commonly hidden rather than shown. See Why a product is not showing up.

What is the difference between complete and enabled?

Completeness says ready: how much of the required data for a channel and a language is filled. Enabled says published. They are independent, so a product can be 100 % complete and deliberately switched off, or enabled and still invisible because it is incomplete for the channel you are looking at. See Create a product.

My import created new products instead of updating the existing ones.

The SKU column did not match. Almost always a leading zero, a prefix or a case difference between the file and the catalog, so every row looked new. Stop the run if it is still going, because duplicates are cheap to fix in the first hour and expensive after a week, once some of them carry prices and order lines. Normalise the identifier in the mapping, then merge or remove the duplicates. See Import products in bulk.

The import failed with "Unknown attribute" or "Invalid option".

The column header is an attribute label rather than its code, or a select value is a label rather than an option code. Fix the source file, not the exported error file, and re-run; matched SKUs update rather than duplicate. "Unknown record" means a reference value such as a manufacturer does not exist yet, and "Missing required" means a required attribute is empty. See Import products in bulk.

In which order do I import a catalog from scratch?

A product cannot reference a record that does not exist yet, so load in this order: attribute options, reference entity records (manufacturers, materials), assets, categories, product models, variant products, then category assignments if they are not in the product file. See Import products in bulk.

The product is in the Cockpit and visible in its category, but search cannot find it.

That is the index. Search runs off an index updated from catalog events, not off the product table, and after a bulk import tens of thousands of changes drain over several minutes. New products appearing gradually is normal. Some appearing and some not an hour later is not: check the search service's failed-update list before assuming the data is wrong. See Common search problems.

Should I trigger a full index rebuild after an import?

Not as a reflex. A rebuild that succeeds tells you nothing about why the incremental updates failed, and it hides the actual fault. Look at the failed-update list first; a single malformed value on one product can be the whole explanation. A rebuild is the right tool after a structural change such as adding a facet field. See Common search problems.

Can I change an attribute's type once products have data in it?

No. Attribute types cannot be changed once data exists, and fixing a wrong model later means merging products that already have order history. This is why the data model is designed on paper before anything is created, and why the first product is created by hand to test the family. See Plan your data model.

One article comes in twelve lengths. Variants, or twelve products?

Variants. A family variant defines the axes the article varies along, such as length or colour, the product becomes a model, and each length is a variant under it. Twelve unrelated products fill the search results with the same screw twelve times and cannot share the data they have in common. See Variants.

The nightly ERP import overwrites the descriptions we enriched.

Nobody decided which system owns that field, so the ERP's 40-character short text wins every night. For every field exactly one system must own it and the other must not overwrite it. Usually the ERP owns the article number, weight and tax class, and the platform owns everything a buyer reads. Write that down and map the import accordingly. See Deciding your system of record.

Umlauts are garbled after an import.

An encoding mismatch, usually a file in ISO-8859-1 read as UTF-8. Set the encoding on the connection or in the mapping and re-run. Do not correct the text by hand; it will be garbled again on the next run. See Common sync errors.

The Cockpit says 412 products in a category, the storefront facet says 380.

Not a bug. The facet counts only what this buyer, in this channel, may see, so disabled, unassigned and out-of-assortment products are excluded. Counts that change between two identical requests are a different matter and mean an index mid-rebuild. See Common search problems.

Where do product images belong: PIM › Assets or Experience Studio › Media?

If the file belongs to an article, it is a catalog asset and lives with the product: the datasheet for 4711-A, the product photo. If it belongs to the site, it is media: the header image, the company brochure, the terms as a PDF. The product's image attribute points at an asset, and that asset becomes the thumbnail in lists and search. See Assets.