El Corte Inglés Data Scraping Services

VAT varies by category, so the rate band belongs on every row

Spain applies different VAT rates depending on the nature of the product. Staple foods, certain books and some other goods attract reduced rates, while general merchandise attracts the standard rate.

• A category-level index can move because the mix of rate bands in the basket moved, with no underlying price change at all.
• A cross-department comparison compares gross figures carrying different tax, which is not a comparison of commercial decisions.
• The band is a property of the product, not of the retailer, so it has to be recorded per row rather than applied as a site-wide constant.

We record vat_rate_band per product as indicated, and retain gross prices exactly as displayed. We do not compute a net figure ourselves — band assignment for edge-case products is a tax determination rather than an observation, and asserting one would be inventing precision. Where a client holds the classification rules, the band and the gross price together let them normalise and check it.

A department store where each department needs different fields

The catalogue spans food, fashion, beauty, electronics, home and travel services. These share a domain and almost nothing else.

Food needs unit pricing and rate bands. Fashion needs size-level availability. Electronics needs model number and energy labelling. Beauty needs shade-level availability. Applying one field set produces a schema adequate for none of them.

Collection is scoped per category tree with department-specific extensions over a common core, so departments remain comparable on price, lifecycle and availability without being forced into an identical shape. This is the same approach used on our John Lewis page, and the field names align so the two can be compared.

Marketplace sellers alongside own stock, with unknown recorded

The platform hosts marketplace sellers as well as selling its own stock, and the two mean different things commercially.

The retailer's own price is a buying and trading decision, and it is what a supplier negotiates against. A marketplace seller's price is an independent third party's, and for a brand it is a channel question.

We capture seller_type and the seller name where displayed, and record unknown where the page gives no indication rather than assuming the retailer. Assuming is how a third party's pricing quietly enters a retailer benchmark, and it is very hard to detect afterwards.

Store collection is a real part of the proposition

The store estate is central to how this retailer competes, and collection availability varies by store independently of whether an item can be shipped.

We capture store_collect_available and the stated collection window per store across a panel, kept separate from delivery availability. An item deliverable next week but collectable today is a different proposition, and a single in-stock flag makes them identical.

For fashion and electronics in particular, collection availability frequently explains a conversion difference that price data cannot.

Spanish-language product data and Spanish sale periods

Titles, attributes and category paths are in Spanish, and the promotional calendar follows Spanish conventions — the statutory sale periods and regional events rather than a Black Friday-centred schedule, although that now features too.

We retain published titles and category paths with translation supplied as separate fields, never replacing the original. Raised-cadence windows are set against the actual Spanish calendar for the year in question.

A collection plan built on a US or UK promotional calendar will sample lightly through the periods where this market's pricing genuinely moves, and heavily through periods where it does not.