E-commerce Data Extraction Guide
Reviewed September 2026. Collect only data you are authorized to use and review each source's current rules before adding it.
E-commerce extraction joins changing product pages to a stable business dataset. The difficult work is usually product identity, offer context, missing data, and parser change rather than downloading HTML. A useful pipeline preserves enough evidence to explain every normalized value.
Start with one decision
Pricing, assortment, availability, seller monitoring, and review analysis need different fields and schedules. Define the decision, approved sources, population, refresh target, and retention before choosing tools.
| Question | Core fields | Common trap |
|---|---|---|
| How does our offer compare? | Exact variant, seller, condition, landed price, availability | Comparing list price with a member or coupon price |
| Which products entered or left a category? | Category path, product identity, first and last seen | Treating pagination or temporary outage as removal |
| Where is an item available? | Location, fulfillment method, stock state, observed time | Mixing delivery, pickup, and marketplace availability |
| How does a catalog describe a feature? | Source text, attribute name, value, unit, locale | Normalizing away material differences |
| What themes appear in reviews? | Approved review text, product, date, rating, language | Profiling reviewers or treating reviews as representative |
Choose the supported source
Prefer an approved API, feed, affiliate interface, merchant export, or licensed dataset. These sources often have better identity and update semantics than a rendered page. Read the contract for storage, redistribution, display, deletion, and rate limits.
Use page collection only for permitted fields that the supported source does not provide. Respect robots guidance and explicit access decisions. A 403, 429, CAPTCHA, or policy page should stop or slow the source and open a review. Do not route around it.
Separate product, offer, and observation
A product is the underlying item. A variant is a sellable configuration such as size or color. An offer ties a seller and condition to that variant. An observation records the offer at a time and place. Keeping these separate prevents a new marketplace seller from looking like a new product.
product:
brand: Example
model: Kettle 2
variant:
color: black
voltage: 120V
identifiers:
gtin: "0000000000000"
offer:
seller: retailer-direct
condition: new
fulfillment: delivery
observation:
price: 49.99
currency: USD
shipping: 0
availability: in_stock
observed_at: 2026-09-21T20:00:00Z
Keep identifiers as strings. Preserve original units and text beside normalized values. Record locale, currency, tax treatment, shipping, subscription or membership conditions, coupon requirements, and stock state.
Build a staged extraction pipeline
- The scheduler creates an idempotent job for a source, URL or source identifier, and expected parser.
- The fetcher retrieves the approved representation with finite deadlines and per-origin limits.
- The parser extracts source-shaped fields without business normalization.
- The validator checks required fields, types, internal consistency, and structural signals.
- The normalizer converts units, currency metadata, categories, and enumerated states through versioned rules.
- The matcher links the item to a reviewed product and variant or sends it to an uncertain queue.
- The writer stores the observation idempotently and emits quality metrics.
Keep these stages separate so a parser fix does not require another request and a matching-rule change can be replayed against saved, authorized observations.
Extract from the simplest representation
Structured data
Many product pages include JSON-LD or another machine-readable block. It can supply names, identifiers, offers, currency, and availability. Validate it against visible page evidence because implementations can be incomplete, stale, or contain several products.
Static HTML
Use stable semantic attributes and scope selectors to the product or offer component. Do not depend on a long generated class chain. Save fixtures representing normal, out-of-stock, promotional, marketplace, and malformed pages.
Approved API or network response
Use a documented endpoint or one the owner explicitly permits. Browser developer tools can help understand your own application, but an undocumented private endpoint should not be assumed available for third-party collection.
Browser rendering
Reserve a browser for approved fields that require client execution. Wait for a business state, such as a product heading and offer container, instead of sleeping for an arbitrary interval. Block unnecessary media only if doing so does not change page behavior. Isolate sessions and cap memory, navigation time, and pages per browser.
Make parsing explicit
function parseMoney(text, expectedCurrency) {
const normalized = text.replace(/\s+/g, ' ').trim()
const match = normalized.match(/([0-9][0-9.,]*)/)
if (!match) return { state: 'missing', raw: text }
return {
state: 'parsed',
raw: text,
amount_text: match[1],
currency: expectedCurrency
}
}
This deliberately avoids guessing decimal conventions. A production parser needs locale-aware rules and tests. Keep the raw text, parsed components, and validation result so an ambiguous value does not silently become a price.
Match products with evidence
Start with strong identifiers such as GTIN, ISBN, or manufacturer part number, then verify brand, model, pack, size, color, and condition. Marketplace titles often combine accessories, bundles, and compatibility terms. A fuzzy title score should propose candidates, not force a match.
Maintain labeled exact, non-match, and ambiguous examples. Measure precision and recall by category. High-value or automated decisions may require reviewed matches only.
Validate data quality
- Required fields, types, supported currency, and valid timestamps.
- Plausible ranges and relationships, such as sale price versus list price.
- Duplicate offers and observations.
- Expected category, seller, product, and page coverage.
- Null rate and value distribution by parser version.
- Freshness, queue age, retry rate, and quarantine volume.
Compare a fixed validation sample after every source change. Also sample random ordinary records because parsers can remain correct on fixtures while drifting elsewhere.
Detect removals carefully
A missing record can mean delisting, temporary outage, failed pagination, location mismatch, or a parser failure. Require repeated successful collection around the missing item or an explicit source state before marking it removed. Keep first seen, last successfully seen, and last attempted as different times.
Report observations and limits
A displayed price does not reveal margin, acquisition cost, strategy, inventory depth, or promotion eligibility. A review sample does not represent all buyers. Reports should state the source set, exact period, matching policy, missingness, seller treatment, and uncertain records.
Protect credentials and people
Use workload-specific credentials from a secrets manager and redact cookies, authorization headers, and private account data from logs. Avoid customer identifiers and reviewer profiles unless the approved analysis requires them. Set retention for raw pages, screenshots, exports, and derived tables. Make deletion traceable through lineage.
Evaluate build versus buy
Pilot on a labeled product set that includes variants, bundles, sellers, currencies, promotions, and unavailable items. Compare coverage, match quality, raw evidence, freshness distribution, failure visibility, schema handling, replay, support, retention, deletion, and total cost per validated record.
For a managed option, compare those requirements with Litport's e-commerce scraping API. The useful output is a traceable dataset that supports a decision, not the largest count of downloaded pages.