Home / From a supplier page to a listing you would publish. / Product data
Product data
Checked, proposed, or left empty — never guessed.
An article number that fails its check is not an article number. Three kilograms for a keyring is not a weight. This step verifies what shipping depends on, and reports the rest.
Product data fails quietly. A wrong weight produces a wrong shipping cost, which produces a listing that loses money on every order — and the error is discovered a month later when somebody adds up the year. The fix is unglamorous: verify what can be verified, propose what is plausible, and refuse to fill in the rest.
What is checked, and how.
- Article numbers — The system verifies an article number before accepting it. A number that fails is not stored as fact — the field reports that it could not be confirmed.
- Weight — Plausible up to fifty kilograms. Above that the value is freight, not parcel — and the shipping model would be built on a misunderstanding.
- Dimensions — Plausible up to three metres on the longest side. Beyond that, the item belongs to a different kind of logistics.
- Retail packaging — A product in a retail box gets one padding rule — a centimetre and thirty grams. A bare product gets more — three centimetres and eighty grams, because it needs protecting.
Three states, and what each one means.
- 01. Confirmed — The value was found and verified — the check passed, or the source matched an established catalogue entry.
- 02. Proposed — A plausible value was found and is offered for adoption. You decide; the system never silently promotes a guess to a fact.
- 03. None — Nothing verified was found. The field stays empty and says so — a blank field can be filled, a wrong one has to be found first.
Why this step comes before pricing.
Every later calculation reads these fields. The price recommendation needs the cost; the shipping check needs the package; the listing needs the dimensions a buyer will ask about. Each is only as good as the number fed into it.
So the enrichment runs early, and its output is labelled by how much it can be trusted. A confirmed dimension and a proposed one look different in the interface — and the difference survives into everything built on top.
Questions, answered
Where does the article data come from?
From established product catalogues, matched on the article number. Where a candidate matches, it is offered for adoption rather than applied — a wrong match would attach the wrong specifications to your listing.
Why are the weight and dimension limits so specific?
Because they mark the boundary of parcel logistics. Above fifty kilograms or three metres, a shipping calculation built on those numbers would be wrong in a way that costs real money on every single order.
Do I have to adopt what is proposed?
No. A proposed value is a suggestion with its source attached. Nothing is applied until you adopt it, and confirmed values are labelled separately everywhere downstream.
How many products can be enriched at once?
A hundred per run. Larger catalogues run in batches, which keeps a bad batch limited in size.
Go deeper
- Product preparation — The full pass: images, data, and the listing draft.
- Import by URL or item ID — Where the raw product data comes from in the first place.
- Shipping costs — What the package data is used for once it is verified.
Back to product-preparation
Check one product you were unsure about.
The article number, the weight and the dimensions come back labelled by how much they can be trusted.
Get Started