What Training Data Does E-Commerce AI Actually Need?

Why e-commerce AI can't run on generic web data

"E-commerce AI" is not one model. It is at least seven distinct systems running inside a retailer's stack at once: search and discovery ranking (what shows up first when a shopper types or speaks a query), recommendation systems (what shows up next to it), generative product content (descriptions, titles, alt text), visual search (find this couch from a photo), dynamic pricing (what the item costs right now), fraud and return-abuse detection, and increasingly conversational shopping agents that browse and buy on a shopper's behalf. Each system solves a different problem, and each is trained on a different mix of the same underlying data.

None of it can be trained well on generic public text. A large language model pretrained on Common Crawl knows what a blender is in the abstract. It has no idea which of your 40 blender SKUs converts, which product photos actually match the listed dimensions, which support tickets end in a refund, or which sessions are a bot scraping prices rather than a shopper deciding whether to buy. That signal exists only inside a retailer's own logs, catalog, and support queue. Grand View Research estimates the global AI-in-retail market at roughly $14.5 billion in 2025, growing to $40.7 billion by 2030 at a 23.0% compound annual growth rate ^[2], and every dollar of that growth depends on someone supplying the domain-specific data those seven systems actually run on.

The stakes for getting product data right just went up again. AI assistants are now a live shopping channel, not a future one: Adobe Analytics data reported by Digital Commerce 360 shows AI-referred traffic to U.S. e-commerce sites grew 138% year over year in May 2026 and converts 54% better than traffic from non-AI sources ^[2]. Stripe and OpenAI's Agentic Commerce Protocol now lets ChatGPT complete a purchase directly against a merchant's catalog through a scoped, single-use payment token ^[4], and Gartner predicts 60% of brands will use agentic AI to deliver one-to-one interactions by 2028 ^[6]. An AI agent shopping on a customer's behalf reads structured product data the same way a ranking model does: it needs attributes, availability, and pricing to be complete, current, and machine-parseable, or it skips the listing entirely.

The 7 data types that actually power e-commerce AI

• Clickstream and behavioral events. Page views, search queries, filters applied, add-to-cart and remove-from-cart events, dwell time, scroll depth, and session sequencing. This is the raw material for ranking and real-time recommenders, and it is the highest-volume, fastest-decaying data type on the list.
• Product catalog with structured attributes. Titles, descriptions, category taxonomy, brand, size, color, material, price history, and inventory status, ideally normalized to a consistent schema rather than free-text scraped from a page.
• Purchase and order history. What was actually bought, in what basket, at what price, how often, and whether it was returned. This is the ground truth that clickstream data only hints at.
• Reviews and Q&A text. Verified-purchase review text, star ratings, helpfulness votes, and buyer questions with seller or community answers. This is the largest source of authentic, product-linked natural language most retailers hold.
• Returns and fraud signals. Return reason codes, refund outcomes, chargeback flags, and confirmed fraud or return-abuse labels. Small in volume relative to clickstream, but the labels are what make a fraud model trainable at all.
• Customer support transcripts. Chat and ticket logs with resolution status, increasingly the training data for conversational shopping agents and post-purchase support automation.
• Product imagery and video. Multiple angles, lifestyle shots, and increasingly video, paired with the SKU and its attributes. This is what trains visual search and virtual try-on.

Two of these categories are growing faster than the rest. Product imagery now feeds visual search at genuine consumer scale: Google reports that Lens alone handles nearly 20 billion visual searches a month ^[2], which is the demand side of why image-to-SKU matching has become a mainstream buyer requirement rather than a novelty feature. And generative product content is where the near-term commercial upside concentrates: McKinsey estimates generative AI could unlock $240 billion to $390 billion in economic value for retail, a 1.2-to-1.9-percentage-point margin uplift, concentrated in product content, marketing, and customer interactions ^[4], which is exactly the catalog and review text described above. Returns and fraud signals are the smallest category by volume, but they carry outsized weight: the National Retail Federation estimates 9% of 2025 U.S. retail returns, roughly $76 billion, were fraudulent ^[6], and every one of those confirmed cases is a labeled example a fraud model can actually learn from.

Realistic volumes and freshness requirements by system

Buyers evaluate an e-commerce dataset against what a comparable production system actually needs, and that bar differs wildly by system. A search-ranking model retrains or updates features continuously because shopper intent and inventory shift by the hour. A generative product-description model can run comfortably off a monthly catalog export, because a product's material and dimensions rarely change. Confusing the two is the single most common mismatch between what sellers offer and what buyers actually want.

Recency compounds. A clickstream export from three years ago reflects a catalog, a UI, and shopper behavior that no longer exist, and its training value drops accordingly. A buyer evaluating a dataset will ask for the date range up front, and a 12-to-24-month window is the realistic floor for anything a ranking or recommendation team will take seriously.

Where e-commerce training data legitimately comes from

There are three real sources, and they are not interchangeable.

• First-party platform data. Checkout logs, session events, your own catalog, verified-purchase reviews collected on your own site, and support tickets your team resolved. This is the scarce, defensible category: it cannot be recreated by a competitor scraping the public web, because it was produced inside your platform.
• Scraped or third-party web data. Competitor catalogs, aggregated review sites, and public listing pages. This is abundant but legally fragile: most platforms' terms of service prohibit bulk scraping and redistribution, review text on a third-party site (like Amazon or Yelp) is generally that platform's to license, not the scraper's, and the resulting data is thinner and noisier than what a retailer holds on its own SKUs.
• Synthetic data. Simulated shopper sessions, generated product descriptions for cold-start SKUs, and synthetic fraud patterns to cover rare attack types real data hasn't seen yet. Useful for filling specific gaps, particularly in fraud detection where genuine positive labels are scarce by design, but it cannot substitute for real behavioral signal at the core of a ranking or recommendation model, since synthetic sessions are generated from a model's existing assumptions about shopper behavior rather than new ground truth.

The academic literature illustrates the scale and structure of the legitimate, licensed-for-research middle ground. The UC San Diego Amazon Review Data corpus links 233.1 million reviews collected between May 1996 and October 2018 to product metadata, images, and co-purchase graphs ^[2], which is exactly the SKU-linked, multimodal structure a real buyer wants, at a scale most individual retailers will never match on their own. It is also a useful benchmark for what "reviews and Q&A text" looks like when it is done right: verified, attributed to a specific product, and enriched with metadata rather than a flat text dump.

The compliance constraints: CCPA, GDPR, and why clickstream is personal data

The instinct to treat clickstream and behavioral data as harmless, since it looks like anonymous traffic logs rather than a name and address, is exactly backwards, and it is the compliance mistake that kills the most e-commerce data deals. Under the CCPA as amended by the CPRA, California Civil Code Section 1798.140(v)(1)(F) defines personal information to include "internet or other electronic network activity information, including, but not limited to, browsing history, search history, and information regarding a consumer's interaction with an internet website, application, or advertisement." ^[2] That is clickstream data, named explicitly.

GDPR reaches the same conclusion from a different angle. Recital 30 addresses exactly the identifiers that populate a clickstream export.

The practical consequence is that a session ID, a device fingerprint, or a hashed cookie value is not automatically "anonymous" just because it isn't a name. If it can reasonably be linked back to a person, alone or combined with other fields in the export, it is personal data under GDPR and personal information under CCPA/CPRA, and its sale or transfer is governed accordingly. For sellers, this means three things have to be true before a clickstream or behavioral dataset is transferable: the platform's privacy notice and cookie consent covered the relevant collection and sharing at the time the data was collected, direct identifiers (name, email, exact address, payment tokens) are stripped or irreversibly hashed, and, for CCPA/CPRA specifically, the sale or sharing of that data was disclosed and consumers were given the required opt-out.

Reviews, support transcripts, and returns data carry their own narrower issues. Review and Q&A text written by customers on your own platform is generally yours to license, but text scraped from a third-party review site is not, and redistributing it can trigger both copyright and platform terms-of-service claims. Support transcripts and returns data often contain payment details, addresses, or health and body-size information embedded in free text, all of which need targeted redaction beyond a simple name-and-email scrub. None of this makes e-commerce data unsellable. It makes provenance and de-identification documentation the first thing a real buyer's legal team checks, exactly as with any other vertical.

How a buyer should evaluate and price an e-commerce dataset

The valuation drivers that apply across every data vertical, volume, quality, domain scarcity, metadata richness, recency, licensing terms, and legal cleanliness, all apply here. A few checks are specific to e-commerce data and worth running before a price is ever discussed.

• 1Check the date range and seasonality mix. A clickstream or purchase-history export dominated by a single Q4 holiday spike will train a model that overfits to a shopping pattern that doesn't hold the rest of the year. Ask for a full 12-month cycle at minimum.
• 2Check category concentration. A catalog and event set drawn from one narrow category (say, one apparel line) trains a narrower model than the same volume spread across a diverse catalog. Neither is wrong, but the price and the buyer pool differ.
• 3Check for bot and crawler contamination. Raw clickstream logs are routinely polluted by scraper and bot traffic. A seller who can show bot-filtering methodology is offering a materially cleaner asset than one who hands over raw logs unfiltered.
• 4Check label quality on fraud and returns data. "Confirmed fraud" (chargeback upheld, manual review confirmed) is worth far more per row than "flagged as suspicious," because the former is a trainable ground-truth label and the latter is noisy.
• 5Check whether the data is SKU-linked across types. Catalog attributes, images, and reviews that all key off the same product ID are worth more together than the same three exports with no shared key, because joining them after the fact is expensive and error-prone for the buyer.
• 6Check licensing scope against the buyer's actual use. A buyer building a foundation-model-scale shopping agent wants very different rights than an internal analytics team; confirm whether the license permits model training and redistribution of derived embeddings, not just internal analytics use.

A worked example: pricing a DTC startup's e-commerce data

Consider a Series B direct-to-consumer beauty brand winding down after 6 years of operation. Its data assets: 18 months of clickstream at roughly 400 million events, a catalog of 12,000 SKUs with full structured attributes and 200,000 product images, 2.1 million verified-purchase reviews, 90,000 resolved support tickets, and 40,000 orders with confirmed return-fraud or return-abuse labels. Here is how a buyer-facing process would reason through it.

• 1Segment before pricing. Almost no buyer wants the whole thing. An AI lab building a shopping assistant wants the catalog, images, and reviews as a linked, multimodal bundle. A recommendation-systems buyer wants the clickstream and purchase history. A fraud-detection buyer wants only the labeled returns subset.
• 2Anchor the clickstream and purchase-history slice. At this volume and with a full seasonal cycle covered, this is a mid-sized behavioral dataset. It anchors toward the higher end of typical non-exclusive ranges for clickstream data of this scale, with an exclusive license commanding a multiple over that.
• 3Anchor the catalog + images + reviews bundle separately, and note the multimodal premium. Because every image and review is linked to the same 12,000 SKUs with full attributes, this bundle is worth more to a shopping-assistant or visual-search buyer than the catalog, images, and reviews would be worth sold as three disconnected exports, since the buyer would otherwise have to do that joining work themselves.
• 4Price the fraud-labeled subset on label quality, not row count. 40,000 confirmed-outcome cases is small next to 400 million clickstream events, but each row carries a rare, expensive-to-produce positive or negative fraud label. This subset prices closer to a specialized annotation product than to bulk behavioral data.
• 5Apply the same recency and licensing logic as any other vertical. All of this data is under 18 months old, which supports pricing at the top of its category. Exclusive, perpetual terms on any slice command the same 3–5x pattern buyers expect across the market for genuinely differentiated data.
• 6Confirm compliance posture before naming a number. Documented consent and disclosed data sharing under CCPA/CPRA, de-identified clickstream, and reviews limited to the brand's own verified-purchase text (not scraped from third-party marketplaces) all need to be true before a sophisticated buyer will engage at any price.

The buyer's due-diligence checklist before you sign

• Consent and notice. Did the privacy notice in effect at the time of collection disclose the sale or sharing of browsing and behavioral data, as CCPA/CPRA requires? ^[4]
• De-identification method. How were direct identifiers removed, and was the process documented well enough to survive a re-identification-risk review?
• Geographic scope. Does the dataset include EU/UK traffic, and if so, what GDPR lawful basis covered its collection and this transfer? ^[4]
• Bot filtering. What methodology, if any, was used to strip crawler and bot traffic from the clickstream logs?
• Review provenance. Is the review and Q&A text collected on the seller's own platform, or aggregated from third-party sites the seller doesn't control the rights to?
• Image rights. Are product photos owned by the seller outright, or licensed from vendors and manufacturers with restrictions on redistribution?
• Fraud label methodology. Are "fraud" labels confirmed outcomes (upheld chargebacks, manual review determinations) or unverified flags?
• Schema documentation. Is there a data dictionary mapping every field, or will the buyer have to reverse-engineer the schema after purchase?

The bottom line

E-commerce AI needs seven distinct kinds of data, not one generic "customer data" blob, and each of the seven systems built on top of them has its own volume and freshness bar. The data that actually moves these systems, session-level behavior, a structured catalog, verified purchase history, authentic reviews, confirmed fraud outcomes, and support resolutions, lives inside a retailer's own platform, not on the open web. As AI agents start browsing and buying directly against merchant catalogs ^[2], and as adoption keeps compounding toward the scale Grand View Research and Gartner both project ^[4][6], that first-party layer only gets scarcer and more valuable.

For a startup winding down or pivoting, that means the platform logs, catalog exports, and support archive sitting in a database aren't a cleanup task. Handled with the right provenance and compliance documentation, they're a sellable asset with real, specific buyers already looking for exactly this shape of data.