Apparel, Accessories & Luxury Goods Data: Macro Series, ML Corpora and Live Commerce Intelligence · Head-to-head

Fashionpedia — Detection Datasets on Hugging Face vs H&M Personalized Fashion Recommendations Transactions

Which apparel, accessories & luxury goods data: macro series, ml corpora and live commerce intelligence data fits your job: Fashionpedia — Detection Datasets on Hugging Face, or H&M Personalized Fashion Recommendations Transactions. API, files, or your warehouse. Daily, weekly, or hourly.

Apparel, Accessories & Luxury Goods Data: Macro Series, ML Corpora and Live Commerce Intelligence None recorded - web-sourced photography from Flickr · Static corpus published at ECCV 2020

Fashionpedia — Detection Datasets on Hugging Face

Apparel, Accessories & Luxury Goods Data: Macro Series, ML Corpora and Live Commerce Intelligence H&M's global markets · Late 2018 through September 2020 (observed t_dat values include 2020-06-15)

H&M Personalized Fashion Recommendations Transactions

Coverage, side by side

Fashionpedia — Detection Datasets on Hugging Face H&M Personalized Fashion Recommendations Transactions
Geographic None recorded - web-sourced photography from Flickr, Unsplash, Burst by Shopify, Freestocks, Kaboompics and Pexels H&M's global markets, anonymised to hashed postal codes
Temporal Static corpus published at ECCV 2020; the Hub conversion is fixed Late 2018 through September 2020 (observed t_dat values include 2020-06-15)

What each contains

They tie on 1 attribute. Pick by fit, not by loyalty.

Fashionpedia — Detection Datasets on Hugging Face H&M Personalized Fashion Recommendations Transactions
Publisher Fashionpedia Consortium (Jia et al., ECCV 2020), packaged on the Hugging Face Hub by the detection-datasets organisation H&M Group, released for its Kaggle recommendation competition
Subject lens Fine-grained fashion understanding: instance-segmentation masks, bounding boxes and a 294-attribute garment ontology over everyday and celebrity-event photography Fast-fashion behaviour: 31.79 million purchase events joined to anonymised customer profiles and a 105,542-article merchandise dimension
Geographic coverage None recorded - web-sourced photography from Flickr, Unsplash, Burst by Shopify, Freestocks, Kaboompics and Pexels H&M's global markets, anonymised to hashed postal codes
Temporal coverage Static corpus published at ECCV 2020; the Hub conversion is fixed Late 2018 through September 2020 (observed t_dat values include 2020-06-15)
Detail level One row per image with a nested objects struct: bbox_id, category, bbox coordinates, mask area One row per purchase event, joined to one row per article and one per customer
Field dictionary 8 documented fields, verified during research 35 documented fields across four tables, verified during research
Datadory rubric 9/10 9/10

What each does better

Fashionpedia — Detection Datasets on Hugging Face

The pixel-level truth about clothes. Fashionpedia never merely asserts that a photograph contains a jacket - it draws you the jacket: instance segmentation masks with per-object attribute labels, 342,182 boxes over 46,781 images, geometry precise enough to train detectors that survive real storefronts. Sample rows show the density: image_id 26 packs fifteen labelled objects into a 1024x683 frame, while image_id 23 carries four in portrait.

An ontology, not a tag list. Beneath the 46 flat categories sit 27 main apparel categories, 19 garment parts and 294 fine-grained attributes - zipper, bead, sequin, tassel - the schema e-commerce teams would otherwise have to invent before auto-tagging a single product photo.

Decoded, model-ready rows. Every record arrives as a PIL image plus nested structs rather than COCO-style JSON awaiting rehydration, with observed image dimensions running from roughly 232x388 up to 1,024 pixels on the long side.

H&M Personalized Fashion Recommendations Transactions

Behaviour at the person level, at benchmark scale. 31,788,324 purchase events from 1,371,980 customers across 105,542 articles, each stamped with t_dat and a sales_channel_id splitting online from physical-store buying - the substrate sequential recommenders, repeat-purchase models and demand forecasts are actually tuned on. See retail transaction log for how these schemas get read.

Time is an axis, not a footnote. Purchases run late 2018 through September 2020, so cadence, seasonality and sequence are measurable.

Where they're equivalent

More than their shapes suggest. Both field dictionaries were verified during research, both score 9/10 on the rubric, and both are frozen research artifacts rather than living feeds - Fashionpedia is a fixed 2020 conversion, the H&M log closes in September 2020; see static snapshot for why that cuts both ways. Both are derived or anonymised rather than official statistics: photographer identities never enter the image corpus, and no H&M customer is re-identifiable from a hashed id. Both carry benchmark pedigree - the standard fine-grained fashion-understanding corpus in one lane, the most-cited apparel recommendation corpus in the other - and both document their schemas precisely enough to reproduce every count on this page. Neither, notably, can answer a 'where' question.

The verdict

Verdict: sample both, pick by fit - they are different instruments pointed at the same wardrobe.

Take Fashionpedia if your question is about seeing garments. Detection and instance-segmentation models, automated tagging of product photos onto the 294-attribute ontology, visual search prototypes, teaching the ECCV 2020 benchmark - anything answered by drawing boxes around clothes.

Take H&M Personalized Fashion Recommendations Transactions if your question is about selling them. Sequential recommendation, repeat-purchase cadence, assortment-width effects, demand forecasting on a rare large-scale fast-fashion consumption panel - anything answered by watching 1.37 million customers buy. Accept its frame: no images, no geography beneath the hashed postcodes, and a world that ends in September 2020.

Sample both and the split usually announces itself: pipelines that consume tensors reach for one; pipelines that consume joins reach for the other. For the modelling angle, see how data scientists use the pair.

Sample both, pick by fit. See Fashionpedia — Detection Datasets on Hugging Face · See H&M Personalized Fashion Recommendations Transactions

Or take both in one feed

Yes - they occupy complementary layers of the same industry, and the classic workflow runs straight through both. Tag with Fashionpedia: a detector fine-tuned on its masks assigns the 46-category, 294-attribute vocabulary to your own product photos. Merchandise with H&M: its article table supplies the product-type and colour-group taxonomy that turns those tags into assortment and recommendation decisions - the same logic behind recommendation data. Or reverse the flow: learn which garment groups actually sell from the transaction log, then ask the image corpus what those groups look like at pixel level. Vision-first neighbours such as DeepFashion extend the image shelf, but Fashionpedia remains the one whose labels were built for commerce-grade granularity.

Three alignments decide whether the merge holds. First, identity: there is no article_id bridge between the two - Fashionpedia categories map onto H&M's product_type_name by hand-curated crosswalk, not by key. Second, grain: image-level rows must be exploded to per-object annotations before they can sit beside per-purchase rows. Third, time: neither side carries a usable calendar, so any trend claim needs outside context. Handled, the pair shows you what shoppers see and what shoppers do - delivered normalized to its documented field dictionary, daily, weekly, or hourly, your call.

API, files, or your warehouse. Daily, weekly, or hourly.

Fair questions

Is Fashionpedia — Detection Datasets on Hugging Face better than H&M Personalized Fashion Recommendations Transactions?

Better at different jobs. Fashionpedia owns the visual layer: 46,781 photographs carrying 342,182 segmentation masks and bounding boxes, a 46-category ClassLabel and a 294-attribute ontology spanning garments, accessories and trims down to zippers and sequins. The H&M release owns the behavioural layer: 31,788,324 purchases by 1,371,980 customers over 105,542 articles, with product types, colour groups and sales channels attached. Both score 9/10 on Datadory's rubric. Sample both, pick by fit.

Do the two datasets cover the same ground?

Only at the level of 'clothes'. The H&M log records what garments sold - dated purchase events joined to a 34-column article dimension - with no imagery and no usable geography beneath its hashed postal codes. One is a specimen drawer of annotated photographs; the other is a 21-month ledger of fast-fashion baskets.

Which dataset is bigger?

Depends on the unit. The H&M release wins raw volume: 31,788,324 transaction rows, 1,371,980 customer profiles and 105,542 articles. Fashionpedia wins annotation density: 46,781 images carrying 342,182 bounding boxes and masks, roughly seven labelled objects per image, in about 3.48 GB of decoded Parquet. Rows against labels - and both are frozen snapshots rather than growing series.

Which should a fashion recommender project sample first?

Start with H&M Personalized Fashion Recommendations Transactions: dated purchase events, anonymised customer profiles and a rich article dimension give collaborative and sequence models everything they need. Add Fashionpedia when the model needs to see - mapping product photos onto the 294-attribute ontology, or building visual features that cold-start articles with too few purchases. The two meet at the article level through a hand-curated category crosswalk.

Can Datadory deliver both datasets together?

Yes - alone or merged onto a hand-curated category crosswalk, delivered daily, weekly, or hourly, your call. Each arrives normalized to its documented field dictionary (eight fields on the Fashionpedia side, thirty-five across the H&M tables) with sample rows for inspection before anything ships - three annotated images on one side, raw purchase lines on the other. The joining work is exploding image rows to per-object annotations and aligning them to product types. Or take both in one feed.