Apparel Retail Data: Clickstream Funnels, Invoice History and Official Statistics · Head-to-head
UCI Online Retail vs UCI Online Retail II
Which apparel retail data: clickstream funnels, invoice history and official statistics data fits your job: UCI Online Retail, or UCI Online Retail II. API, files, or your warehouse. Daily, weekly, or hourly.
UCI Online Retail
UCI Online Retail II
Where the fields line up
8 shared fields — join on these.
| Field | UCI Online Retail | UCI Online Retail II |
|---|---|---|
InvoiceNo | Invoice number: a six-digit integral number uniquely assigned to each transaction; a leading 'c' marks a cancellation. | Invoice number: a six-digit integral number uniquely assigned to each transaction; a leading 'c' marks a cancellation. |
StockCode | Product (item) code: a five-digit integral number uniquely assigned to each distinct product. | Product (item) code: a five-digit integral number uniquely assigned to each distinct product. |
Description | Product (item) name as the retailer wrote it on the invoice line. | Product (item) name. |
Quantity | Quantities of each product per transaction; negative quantities pair with cancellation invoices. | The quantities of each product (item) per transaction. |
InvoiceDate | Date and time the transaction was generated, down to the second - the field that makes intraday basket analysis possible. | Invoice date and time: the day and time when a transaction was generated. |
UnitPrice | Product price per unit in sterling, exactly as invoiced. | Unit price per item in sterling. |
CustomerID | Customer number: a five-digit integral number uniquely assigned to each customer; widely reported blank on many guest-checkout rows. | Customer number: a five-digit integral number uniquely assigned to each customer. |
Country | Name of the country where each customer resides - UK domestic alongside international wholesale buyers. | Name of the country where each customer resides - UK domestic shoppers beside international wholesale buyers. |
Coverage, side by side
| UCI Online Retail | UCI Online Retail II | |
|---|---|---|
| Geographic | Global customer base of one UK retailer - UK domestic plus international wholesale buyers | Global customer base of the same retailer - UK domestic plus international wholesale buyers |
| Temporal | 01/12/2010 to 09/12/2011 - about one trading year, final December truncated | 01/12/2009 to 09/12/2011 - roughly two trading years, containing the original's window whole |
What each contains
They tie on 5 attributes. Pick by fit, not by loyalty.
| UCI Online Retail | UCI Online Retail II | |
|---|---|---|
| Publisher | UCI Machine Learning Repository | UCI Machine Learning Repository |
| Subject lens | Transaction log of one UK online gift and apparel-accessories retailer | Extended transaction log of the same retailer |
| Field dictionary | 8 documented fields per line item, verified during research | 8 documented fields per line item, verified during research |
| Geographic coverage | Global customer base of one UK retailer - UK domestic plus international wholesale buyers | Global customer base of the same retailer - UK domestic plus international wholesale buyers |
| Temporal coverage | 01/12/2010 to 09/12/2011 - about one trading year, final December truncated | 01/12/2009 to 09/12/2011 - roughly two trading years, containing the original's window whole |
| Detail level | One row per invoice line item | One row per invoice line item; yearly sheets stacked before analysis |
| Currency | Pounds sterling throughout | Pounds sterling throughout |
| Cancellation marking | Leading c on InvoiceNo | Leading c on InvoiceNo |
| Missing values | Repository reports none; CustomerID blanks reported widely | Repository flags missing values; profile CustomerID before use |
| Best for | RFM teaching, benchmark reproduction, fast prototyping | Seasonality, cohort retention, forecasting, year-over-year comparison |
What each does better
UCI Online Retail II
Two annual cycles instead of one. This is the whole upgrade and it is larger than it sounds. With a single year you cannot tell a seasonal spike from a growth trend, because every month occurs once. With Dec 2009 through Dec 2011 you can compare like months across years, estimate December lift with a control, and validate a forecast on a year the model never saw.
Cohorts that survive their first birthday. Retention curves built on the original die at month twelve for customers acquired after January 2011. II tracks acquisition cohorts across a second cycle, which is what makes customer segmentation work defensible rather than illustrative.
Pre-2010 trading as a structural comparison. The extra year captures the retailer emerging from the financial-crisis trough into recovery, so questions about how a small cross-border wholesaler traded through that period have data here and nowhere else.
UCI Online Retail
It is the canonical benchmark. Five hundred thousand transactions, donated in 2015 beside the RFM segmentation paper that made them famous - this is the file behind a decade of market-basket tutorials, CLV walkthroughs and churn notebooks. Reproducing a published result or checking your segmentation code against known numbers is easier on the cut everyone used; see RFM analysis.
A self-contained cut for prototyping. One table, no assembly step: load it and every enrichment, basket or segmentation job has a complete annual cycle to run against. For teaching, smoke-testing a pipeline or timing an ETL stage before pointing it at something bigger, the smaller file is the faster instrument.
A cleaner missing-value claim. The repository records no missing values for the original, while II is flagged as containing them. In practice CustomerID runs blank for guest checkouts on both sides, but if your tooling wants the tidier label, the original carries it.
Where they're equivalent
Almost everywhere, because they are the same record in two lengths. Same retailer and catalogue: one UK-based non-store seller of unique all-occasion giftware and apparel accessories, wholesale customers included, with Country spanning UK domestic and international buyers. Same grain: one row per invoice line item, a product within an invoice, which is the grain retail transaction log work wants. Same currency, sterling throughout. Same cancellation convention, the leading c on InvoiceNo. Both dictionaries verified during research, both scored 8/10.
They even share their weaknesses symmetrically. Both are static cuts - the shop stopped being logged in December 2011, so neither answers anything about the retailer since. Both leave CustomerID blank on guest rows, thinning identity-keyed analysis equally. And both describe one retailer only, so neither supports market-level claims about UK online retail; that question needs an index rather than a ledger.
The verdict
Verdict: sample both, pick by fit - the schemas cannot decide it for you, so the calendar has to.
Take UCI Online Retail if your question fits inside one trading year. Teaching RFM segmentation, reproducing benchmark basket numbers, prototyping an invoice-level pipeline, testing whether transaction data suits your problem at all. Accept its frame: one annual cycle, December truncated.
Take UCI Online Retail II if your question involves time as a variable. Year-over-year seasonality, cohort retention past twelve months, SKU- or country-level demand forecasting with a held-out year, pre-versus-post-2010 trading comparisons. Accept its frame: flagged missing values, and yearly sheets to stack before analysis.
When in doubt, sample both and let the extra cycle decide: everything the original can answer, II answers too, plus what the second year buys.
Sample both, pick by fit. See UCI Online Retail · See UCI Online Retail II
Or take both in one feed
Identical dictionaries mean there is no field mapping, no unit reconciliation and no identifier translation: the union lines up column for column by construction.
Two decisions make the merge correct. First, containment: the original's window sits entirely inside II's, so binding both files double-counts December 2010 through early December 2011 unless you either take II alone or carry a source-cut flag and de-duplicate on InvoiceNo plus StockCode. Second, structure: stack any yearly sheets inside II into one table first, then confirm the combined row count reconciles to the published totals before analysis. We handle both steps in the merge, delivered daily, weekly, or hourly - your call. Or take both in one feed.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Is UCI Online Retail II better than UCI Online Retail?
For most questions, yes - it is a strict superset. Both carry the same eight fields per invoice line item, and the II window (December 2009 to December 2011) fully contains the original's (December 2010 to December 2011). The original keeps two uses: it is the smaller, faster pass for teaching RFM segmentation or testing a basket pipeline, and it matches the classic benchmark numbers published against the 541,909-row cut. Sample both, pick by fit.
Do the two datasets cover the same ground?
They are the same ground. Nothing differs except where the clock starts and stops.
Which dataset should I use for seasonality and forecasting?
Online Retail II. A single trading year cannot separate a seasonal pattern from a trend, because December appears once. Two full cycles let you compare December 2010 against December 2011, fit SKU- and country-level demand models on one year and test them on the next, and read cohort retention past the first anniversary. If your question lives inside one year, the original answers it just as well.
What about missing values in each dataset?
Profile CustomerID first on either side. Guest-checkout and some wholesale rows arrive without a customer ID, which thins any RFM, CLV or churn build keyed on the customer; the repository flags missing values on II explicitly while the original claims none, so treat the blank-ID share as the real gap rather than the label. Cancellation rows marked with a leading c on InvoiceNo also need a keep-or-drop decision before revenue totals mean anything.
Can Datadory deliver both datasets together?
Yes - as separate cuts or merged into one continuous 2009-to-2011 ledger, delivered daily, weekly, or hourly, your call. Because the schemas are identical, the merge is a column-aligned union plus a source-cut flag, not a mapping exercise; the only reconciliation is de-duplicating the overlap year if you want each line item counted once. Or take both in one feed.