Tracking Appliance and Electronics Listings: Turning Specifications Into Structured Data

Introduction

A pricing analyst at an appliance brand builds a competitive report. It shows the company's induction cooktop priced above three competitors. The category head glances at it and points out that two of those competitors are 1,200 W units and the company's is 2,000 W.

The report was not wrong about the prices. It was wrong about what a competitor is.

This is the defining characteristic of appliance and electronics data work. In grocery, a product is identified well enough by brand, name and pack size. In appliances, a product is identified by a specification vector, and two listings that look similar in a title can be in entirely different competitive sets. Price tracking in this category is a specification-matching problem that happens to output prices.

Why unnormalised price comparison fails

Consider what changes a washing machine's competitive position: load capacity in kilograms, front-load versus top-load, inverter versus conventional motor, energy rating, drum material, and whether it has a heater. Two 7 kg machines with different motor types and energy ratings are near-substitutes. A 7 kg and a 10 kg machine are not.

The consequences of skipping normalisation:

• Price index against the wrong set. Your index tracks a mix of products a buyer would never consider alongside yours.
• Invisible undercutting. A competitor drops price on the comparable configuration while raising it on a premium one. Blended, nothing moved.
• False whitespace. A configuration appears absent when it exists under specification language your matcher did not recognise.
• Meaningless elasticity. Any relationship you fit between price and availability is fitted across non-comparable products.

The fix is a per-category attribute schema, populated for every listing, used to define comparable sets before any price is compared.

Extracting specifications from unstructured listings

Specifications on retail listings live in four places, each with different reliability.

The extraction pipeline should read them in that priority order and record which source produced each attribute value. When sources conflict, take the highest-priority source and log the conflict. Conflict rate per retailer is a useful reliability metric — some retailers' spec tables are genuinely unreliable and you need to know which.

Key mapping is most of the work. The same attribute appears as "Power Consumption," "Wattage," "Power (W)," "Motor Power," and "Rated Power." Maintain an alias dictionary mapping observed keys to canonical attribute names, per category. This dictionary grows continuously; treat it as a maintained asset with a review process, not a one-time build.

Value parsing needs its own care. "1200 W", "1.2 kW", "1200W", "1200 watt" are one value. Store the canonical numeric value and unit, and keep value_raw so any parse can be audited. Ranges ("1000-1200 W") need a documented convention — store min and max, do not pick one silently.

Per-category attribute schema

There is no universal appliance schema. Each category needs its own, with a shared core.

Shared core fields, every category:

Category-specific extensions, for example:

Refrigerators: capacity_litres, door_config (single/double/side_by_side/french), cooling_type (direct_cool/frost_free), compressor_type (inverter/conventional), shelf_material, convertible_modes.

Washing machines: load_capacity_kg, load_type (front/top/semi_auto), motor_type, rpm_spin, inbuilt_heater, wash_programmes_count.

Air conditioners: capacity_tons, type (split/window/portable), inverter, isee_rating, copper_condenser, wifi_enabled.

Induction cooktops: power_watts, burner_count, preset_count, panel_type, touch_control.

Televisions: screen_size_inches, panel_resolution, panel_type, refresh_rate_hz, hdmi_ports, smart_platform, hdr_formats.

Define a comparable_set_key per category as a deterministic function of a named subset of these attributes. For refrigerators that might be capacity band plus door configuration plus cooling type. Document the function. Every price index is then computed within a comparable set key, and the function itself becomes reviewable.

Model-number matching and its limits

Model number is the strongest matching signal in this category. When two listings carry the same manufacturer model number, they are the same product, and no other field comes close to that certainty.

Normalisation is required before matching. Model numbers appear with and without hyphens, with region suffixes, with colour codes appended, in different cases, and with retailer prefixes bolted on. Build a normaliser that strips punctuation, uppercases, and separates a recognised base from known suffix patterns — then keep both base and full form, because sometimes the suffix is the whole distinction.

Where it breaks down:

Retailer-exclusive SKUs. Large retailers commission model variants sold nowhere else. The model number has no counterpart. These are real competitors and they will never match. Flag them as exclusive_sku and handle them through spec-based matching alone.

Bundle variants. A model number with an included stabiliser, extended warranty or installation kit is not price-comparable with the bare unit. Detect bundle indicators in title and spec fields, set is_bundle, and exclude bundles from the primary index while tracking them separately.

Colourways. Same model, different colour, sometimes different price. Group under a parent product with colour as a variant dimension. Whether colour variants share an index cell is a documented choice — usually yes for appliances, sometimes no for premium electronics.

Generation ambiguity. A successor model can reuse most of a model string. Compare spec vectors, and where they differ materially, treat as separate products regardless of string similarity.

Missing model numbers. Marketplace third-party listings frequently omit them. These fall back to spec matching with a lower match_confidence, and should be visibly labelled as such in any output.

Always carry match_method and match_confidence. A pricing decision made on a model-number match and one made on a fuzzy spec match deserve different levels of trust, and the analyst needs to see which they have.

Effective price in India is not the listed price

This is where Indian appliance data diverges most from other markets. The listed price is one component of what a buyer pays.

Components sitting between listed price and effective price:

• Bank card offers. Instant discount on specified issuers' credit or debit cards, often with a cap and a minimum transaction value. Conditional, issuer-specific, and frequently the largest single component.
• Exchange value. Trade-in allowance for an old appliance, varying by the condition and model surrendered. Highly conditional.
• No-cost EMI. The interest is absorbed by the retailer or brand, which is a real price reduction whose value depends on tenure.
• Coupon codes. Stackable or not, with their own conditions.
• Cashback. Often deferred to a wallet or statement credit, which is not the same as a discount.
• Installation and stabiliser charges. Sometimes free, sometimes extra, and materially affect total cost.

Capture each as a structured offer record linked to the listing, never as a single "effective price" number.

The gap between listed and best-case price in a tracked appliance set can reach [DATA: observed maximum gap between listed and all-offers price, category and date stated], which is why a single number will not do.

Compute effective price scenarios instead. A price_listed, a price_with_unconditional_offers, and a price_best_case_all_offers — each labelled, each traceable to the offer records that produced it. Different stakeholders need different ones. A brand watching competitive positioning wants the first two; a trade team assessing what a shopper actually sees wants the third.

Cadence: the festive cycle sets the schedule

Indian appliance pricing is not smooth. Festive season sale events produce concentrated, short-lived price and offer changes, and a weekly collection schedule will miss most of what happens.

A workable cadence:

• Weekly baseline for the full tracked set, off-season.
• Daily from the start of the festive period through its end.
• Multiple times daily during flagship sale event windows, where prices and offers change within hours.
• Event-triggered collection on new-model launch detection.

Every record carries event_context so a price series can be read with sale windows visible rather than as unexplained volatility. Without it, a chart of appliance prices across October looks like an error.

Availability and delivery-pincode variation

Appliance availability is pincode-dependent in ways electronics accessories are not. Large appliances require serviceable delivery and installation, and retailers restrict them by pincode.

Collect availability against a fixed pincode sample stratified by city tier, and store delivery_pincode on every availability record. A product "in stock" nationally may be undeliverable across a large part of the country. Also capture delivery_promise_days and installation_offered where exposed — for a large appliance, a two-week delivery promise is close to being out of stock.

Actowiz Solutions collects appliance and electronics listings across Indian retailers with per-category attribute schemas, model-number and specification matching, and structured offer capture for effective-price scenarios. Collection cadence is tuned to the festive cycle with event-context tagging on every record.

Request a free sample dataset →

FAQ

Q: Why does appliance price comparison require specification normalisation?

A: Because titles do not define competitive sets. A 1,200 W and a 2,000 W cooktop, or a 7 kg and a 10 kg washing machine, are not substitutes. Comparable sets must be built from a per-category attribute schema first.

Q: Is model number enough to match appliance listings across retailers?

A: It is the strongest signal but not sufficient. Retailer-exclusive SKUs, bundle variants, colourways and omitted model numbers on third-party listings all require specification-based fallback matching with recorded confidence.

Q: Why is the listed price misleading in Indian appliance retail?

A: Bank card offers, exchange value, no-cost EMI, coupons and cashback all sit between listed and paid price. Each should be captured as a structured offer record so multiple labelled effective-price scenarios can be computed.

Conclusion

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!