Alternative Data for eCommerce, The Signals That Move Before Earnings Do

A retailer’s 10-Q lands 45 days after the quarter closes. By then, the trade is priced in. Every SKU on that site already shows price, stock, and rank, live. Most analysts still wait for the filing. This post shows what eCommerce alternative data actually looks like. It includes a working extraction pattern and sample output.

Why a Quarterly Filing Is Already Late

eCommerce companies report earnings once a quarter. Their websites report constantly. Price changes, stock-outs, new listings, and review counts update by the hour. Sometimes by the minute. None of it needs a filing to become visible.

That gap is what alternative data closes. The term covers any dataset collected outside standard financial disclosures: credit card panels, satellite imagery, web-scraped listings, among others. The global alternative data market reached $18.8 billion in 2025, according to Grand View Research. Hedge fund operators accounted for 67.66% of that spend, the largest single share by end use.

Web-scraped retail data sits near the center of that spend. Web crawling and scraping delivered 30.55% of the alternative data market’s 2025 revenue, per Mordor Intelligence. No other collection method comes close. It needs no survey panel, no card-network partnership, no mobile SDK. The signal is already published, on the product page, the moment it changes.

A stock-out is a good example of how much sits in plain sight. It isn’t just a missed sale. It costs the average eCommerce brand an estimated 4-8% of annual revenue, according to Forrester. That number sits in the availability field, well before it ever shows up in a margin line.

For eCommerce specifically, the pages already carry the signal. The job is extracting it cleanly, repeatedly, at a scale a spreadsheet can’t hold.

How eCommerce Web Data Compares to Other Alternative Data

Not all alternative data behaves the same way. eCommerce web data sits in a specific spot on a latency-versus-granularity map. Knowing where it sits helps decide when to reach for it, instead of another category.

Web-scraped data wins on latency and SKU-level detail. It loses on population coverage. A card panel infers behavior across millions of shoppers. A scrape only sees what’s on the page. The two are complements more often than substitutes. A pricing signal built from scraped SKU data answers one half of a question. A demand signal built from a card panel answers the other half.

Coverage breadth changes which category is more reliable for a given question too. A single retailer’s stock-out pattern is a fact, directly observed, no sampling involved. A market-share estimate across a category is different. It leans on how many retailers sit inside the coverage set. A coverage gap reads the same as a demand gap. The two need separating deliberately, or the estimate is wrong.

What Counts as an eCommerce Signal

“Alternative data” is a wide label. For eCommerce, it narrows to a short list of fields. All of them are native to the product page.

Best-seller rank is the most cited field on this list. It’s also the most misunderstood. Amazon calculates it from sales, both recent and historical, weighted toward recent activity. It isn’t influenced by page views or reviews, per Amazon’s own seller documentation. But it’s relative, not absolute. Rank 500 in furniture and rank 500 in phone cases mean different unit volumes entirely. Turning rank into a usable number takes a baseline. That baseline is category-specific, built from historical rank-to-sales pairs. It needs enough weeks of history to cover a normal demand cycle. Once it exists, a new rank reading maps to an estimated unit range. It stops being a bare ordinal number. The rank alone isn’t the signal. The trend against that baseline is.

Review velocity works differently. It’s easy to underweight. A sudden drop in new-review rate often precedes a rank decline, sometimes by days. It’s one of the few fields that flags a quality or fulfillment problem early. That’s often before it shows up anywhere else on the page.

Seller count tells a margin story rank can’t. A listing with one seller holds pricing power. The same listing with fifteen third-party sellers is already commoditized. Pricing power has shifted from the brand to the marketplace. That’s true no matter what the brand’s own site still says.

New SKU and delisting rate move slower. They say more about strategy. A retailer quietly delisting a category over several months is retreating from it. That retreat shows up on the page first. A press release, if one ever comes, arrives later.

A Working Extraction Pattern

Most product pages, including Amazon and Best Buy listings, embed a Product block in JSON-LD. That block already carries price, availability, and rating fields in a structured shape. No CSS-selector guessing required.

# Extract price, availability, and rating signals from a product page's JSON-LD block
import json
import httpx
from bs4 import BeautifulSoup

def extract_product_signal(url: str) -> dict:
    """Pull price, availability, and rating fields from schema.org Product JSON-LD.
    Illustrative only, production crawlers add retries, proxies, and header rotation."""
    response = httpx.get(url, timeout=20, follow_redirects=True)   # 1. fetch the page
    soup = BeautifulSoup(response.text, "html.parser")             # 2. parse HTML

    for tag in soup.find_all("script", type="application/ld+json"):
        try:
            data = json.loads(tag.string or "")
        except json.JSONDecodeError:
            continue
        if data.get("@type") == "Product":                         # 3. isolate the Product block
            offer = data.get("offers", {})
            return {
                "sku": data.get("sku"),
                "price": offer.get("price"),
                "availability": offer.get("availability", "").split("/")[-1],
                "rating": data.get("aggregateRating", {}).get("ratingValue"),
                "review_count": data.get("aggregateRating", {}).get("reviewCount"),
            }
    return {}

Sample input: a product page URL from the target catalog.

Sample output:

{
  "sku": "SKU-48213",
  "price": 24.99,
  "availability": "InStock",
  "rating": 4.6,
  "review_count": 1842
}

That single record is a fact, not a signal. Run the same extraction daily. Keep the schema constant. The diffs start to show a pattern.

Illustrative time series, not a real SKU or company.

Read across that table and the pattern reads itself. A price cut, a rank climb, then a stock-out right at the rank’s peak. That’s demand outrunning supply. It’s the kind of pattern worth flagging, weeks before a filing confirms it either way.

That pattern needs one honest caveat. A price cut during a planned promotional window isn’t the same signal as an unplanned discount. Black Friday and Prime Day both count as planned windows. Reading the two the same way turns a real signal into noise. A usable feed carries a promotional-calendar flag alongside the price field, not just the price alone.

A single day’s diff is useful. A rolling metric over several weeks is what actually feeds a model.

# Turn a stored daily record history into rolling signal metrics
from statistics import mean

def compute_rolling_signal(history: list[dict], window: int = 30) -> dict:
    """history is a list of daily records for one SKU, oldest first.
    Each record has 'price' and 'availability' keys, matching the output
    of extract_product_signal. Returns two rolling metrics over the window."""
    recent = history[-window:]                                    # 1. take the lookback window
    price_changes = sum(
        1 for i in range(1, len(recent))
        if recent[i]["price"] != recent[i - 1]["price"]
    )                                                              # 2. count price moves
    stockout_days = sum(
        1 for r in recent if r["availability"] == "OutOfStock"
    )                                                              # 3. count stockout days
    return {
        "price_change_count": price_changes,
        "stockout_rate": round(stockout_days / len(recent), 3),
        "avg_price": round(mean(r["price"] for r in recent), 2),
    }

Sample input: 30 daily records for one SKU, shaped like the extraction output above.

Sample output:

{
  "price_change_count": 2,
  "stockout_rate": 0.167,
  "avg_price": 21.66
}

A 16.7% stockout rate over 30 days, alongside two price cuts, is a specific, comparable number. It’s the kind of field a model can actually use. Not a wall of raw daily records nobody has time to read.

Not every page ships clean JSON-LD. Older CMS-driven catalogs bury price and availability inside rendered HTML. No structured block exists at all. Price strings arrive in a dozen inconsistent formats too: strikethrough sale prices, currency symbols, “as low as” ranges. A rigid selector-based scraper breaks on that inconsistency. AI-assisted extraction reads the unstructured DOM and fills the same schema anyway. The downstream signal doesn’t care which pages had JSON-LD and which didn’t. This is the extraction problem DataFlirt’s eCommerce data extraction work is built around.

From a Single SKU to a Pre-Earnings Signal

eCommerce alternative data already has a public track record. YipitData, a web-scraped and alternative-data provider, lists eBay among the 70-plus tickers it tracks. It uses listing and pricing data collected directly off the site itself. That’s according to its public data-provider profile on AlternativeData.org.

The mechanism generalizes past any single company. Rising discount frequency ahead of a quarter often signals margin pressure a company hasn’t guided to yet. A sustained rank climb paired with a stock-out usually means demand outran supply. Sometimes that’s a good problem. Sometimes it’s a lost sale a competitor caught instead.

A rank alone is a snapshot. A rank trend, sourced daily against a stable schema, is a signal.

Investment teams already running DataFlirt’s stock market data feeds often add eCommerce signals too. The two data types answer overlapping questions from different angles. One comes from filings and disclosures. The other comes from what the company actually published on its own site.

The same pipeline serves a second, less glamorous persona too. The retail ops or pricing team, benchmarking its own competitor set, is that persona. A daily feed of a competitor’s price, stock, and promotion cadence answers one question fast: what should tomorrow’s price be. That use case doesn’t need a hedge fund’s full coverage universe. It needs the same seven fields from the table above. They run on the same schedule. They deliver into whatever system already runs the pricing engine. Structured delivery matters more here than raw access. A pricing engine can’t consume a folder of HTML files.

Review data earns its own mention here. A reviews and ratings feed tracks alongside price and stock. It turns a single bad batch into an early signal. Same for a shipping-partner problem. Both show up here days before either shows up as a rank decline.

MAP violation monitoring is the sharpest version of the competitive-intelligence case. A brand sets a minimum advertised price across a hundred retailers. Enforcing it manually means checking a hundred pages by hand, on some cadence nobody actually keeps up. A daily price feed across the same hundred retailers turns enforcement from a manual audit into an automatic alert. It’s flagged the same day a violation appears. Not weeks later, when a partner complains.

What Changes at Sector Scale

Tracking five SKUs by hand is a spreadsheet problem. Tracking a full retail sector isn’t.

At sector scale, most named platforms sit behind Akamai or PerimeterX-class bot defenses, Target among them. Anti-bot handling stops being a one-time fix. It becomes ongoing engineering, tuned per site as defenses change.

Schema drift is the second wall. One retailer renames “availability” mid-migration. Another nests price inside a different JSON path entirely. Schema drift detection catches that before it silently breaks a signal three sites deep into a coverage universe. Deduplication logic matters just as much. The same SKU often shows up across a marketplace listing and a brand’s own site. It gets counted twice unless something catches it.

Vocabulary drift is a quieter version of the same problem. One retailer’s page says "InStock". Another says "in_stock". A third just says "Yes" in a plain HTML span with no schema at all. None of that is a stockout rate a model can use, until it’s mapped to one consistent value. Normalization has to happen before delivery. It can’t be left for whoever receives the feed to sort out. Otherwise every downstream team ends up rebuilding the same mapping table independently.

Choosing between a one-time pull and a recurring feed is worth deciding deliberately. The infrastructure need differs for each. A sudden addition of thirty new tickers to a coverage universe doesn’t need to wait on a hiring cycle either. An elastic engineering bench flexes to match the job, instead of stalling on it. Output at this scale typically lands as a scheduled CSV or JSON drop, or a live API. It can also land directly in S3, MongoDB, or DynamoDB. Either way, it feeds whatever model already runs downstream.

Why Point-in-Time History Matters for a Signal

A signal is only as trustworthy as its history. A schema change can silently overwrite yesterday’s stored price with today’s. The record no longer reflects what the page actually said on that date. That’s a quiet bug with a large consequence. A backtest run against corrected, overwritten history looks far more accurate than the signal actually was in real time.

A backtest run against overwritten history isn’t a backtest. It’s a story the data was edited to tell.

The fix is boring but non-negotiable. Every extracted record needs its own timestamp, stored immutably, never edited in place. A price correction becomes a new row, not a rewrite of an old one. That discipline is what separates a research-grade eCommerce feed from a live dashboard. A dashboard only ever shows today’s snapshot.

The Pipeline, End to End

The path from a raw product page to a usable signal runs through five fixed stages. That’s true whether the coverage set is five SKUs or five hundred.

From raw product pages to a decision-ready signal: five fixed stages, one shared schema, delivered on whatever cadence the underlying decision actually requires.

Scraping publicly accessible eCommerce data is generally lawful. Specifics vary by jurisdiction and by site terms. See DataFlirt’s full breakdown of web crawling legality.

Next Steps

Choose DataFlirt if:

• The coverage set includes JavaScript-heavy or anti-bot-hardened retailers, Cloudflare, Akamai, or PerimeterX among them.
• The signal needs daily or hourly refresh, not a one-time pull.
• Structured CSV, JSON, or API delivery matters more than raw HTML access.
• There’s no in-house data engineering bench to build and maintain the pipeline.

Look elsewhere if: DataFlirt runs on cloud infrastructure and third-party proxy vendors rather than owning infrastructure in-house. That’s true of nearly every provider in this space, so it isn’t a differentiator against alternatives, but it’s worth knowing if in-house infra ownership is a hard requirement.

One-time eCommerce data pulls are typically scoped and delivered in 3-4 days. Start with a single sector or a defined competitor set. Review the sample output before committing to a recurring feed. Reach out through DataFlirt’s contact page to start.