Product Data for Curtains and Drapes: Dimensions and Hanging

A curtain looks like a simple product until you try to put it in a shop. Then it turns out that a single article is really a bundle of measurements and hanging decisions: how tall, how wide, how it hangs, how much light it lets through, what fabric it's made of, and whether you buy it as a fixed size or by the running metre. Get one of those attributes wrong or missing, and the customer can't configure the product — so they don't buy it.

Product data for curtains and drapes is a measurement-and-hanging problem: height, width, heading type, transparency and fabric decide whether the product is even configurable. This is a sub-topic of the broader home-textiles product-data challenge, where the same tension — soft, dimension-driven articles versus a shop that needs controlled values — shows up across bedding, towels and rugs too.

What makes curtain product data so difficult?

The core issue is that a curtain is defined by a group of attributes, and every supplier records that group differently:

• Dimension order: one supplier lists width x height, the next height x width. Get the axes crossed and a 140x245 curtain becomes a 245x140 — a different product entirely.
• Fabric width vs. finished width: the width before pleating is not the width the customer sees on the rail. Some feeds give one, some the other, some both without labelling which.
• Heading type as free text: eyelet, pencil pleat, tape, hook — controlled values that should drive a filter, but usually arrive as prose in the title or a notes field.
• Transparency: sheer, semi-transparent, blackout — a decisive buying criterion, almost never a clean, standardised field.
• Fixed size vs. by the metre: ready-made drapes and running-metre fabric are two different pricing and attribute logics, often mixed in the same supplier Excel.

Feed those raw fields straight into a shop and the customer can neither filter nor configure. The fix is the same as everywhere in multi-supplier retail: consolidate, normalize, enrich and publish — but here the hard part is the dimension-and-hanging layer specifically.

Which standards apply to curtains — and where do they stop?

Curtains sit inside home textiles, so the usual identifiers and classifications apply at the top level — and then thin out fast where the real attributes live:

So the standards identify and roughly classify a curtain, but the layer that actually decides whether the product is buyable — the measurement and hanging attributes — is almost always yours to build by hand.

How does Productbay help with curtain product data?

The throughline is a three-step job, and the trick for curtains is modelling the measurement and hanging attributes as proper attribute groups — that's exactly what Productbay is built for:

• Consolidate: import every source once — supplier Excel, CSV, PDF datasheet, feed URL, FTP, API — and match by SKU or GTIN/EAN so existing products update and new ones are created. Fixed-size drapes and by-the-metre fabric land in one catalog.
• Enrich: AI parses width, height and heading type out of titles and datasheets, normalises transparency into controlled values, writes descriptions, assigns categories and translates via DeepL — always with a review queue before anything publishes. Attribute groups make width x height, heading type and transparency consistent across suppliers.
• Publish: two-way sync to Shopify and Shopware, ERP connections (Xentral, weclapp), and feed exports for Amazon, OTTO and Kaufland — each with per-channel transformations, so a configurable curtain stays configurable in every channel.

Productbay is built for specialist retailers running multi-supplier, multi-channel catalogs. For the full picture across bedding, towels and rugs, see the home-textiles overview, and for the mechanics of turning messy supplier files into clean data, the guide on enriching and normalizing multi-supplier data.

Frequently Asked Questions