Retail Test Data: Check-Digit-Valid GTINs in a Labeled Catalog-Listing Fixture
A retail test dataset that exercises catalog deduplication needs GS1 check-digit-valid GTINs and a labeled near-duplicate catalog covering the four states that break naive matching: same GTIN different title/SKU, missing GTIN, sibling variant, and hard negative (pack vs weight). This page names 10 core fields (14 atomic when compound columns are split), shows an 8-row labeled catalog_listing dedupe fixture with worked GS1 check digits, and lists 6 test scenarios (including returns and inventory ideas to build against the same identifiers).
Near-duplicate product and catalog-listing resolution
Retail catalogs break naive matching because the same product appears under GTIN, SKU, and marketplace listing IDs that do not share a string form. This is product-entity resolution (GTIN/SKU), not CRM person-entity contact dedupe.
The hard cases: same GTIN different title/SKU; missing GTIN; sibling variant (same style, different GTIN); hard negative (12-Pack vs 12oz titles that must not merge).
Field set
| Field | Role | Note |
|---|---|---|
| gtin_13 | Global trade item id | GS1 check digit; leading digits illustrative |
| gtin_12 | UPC-A | Same GS1 method, flipped weight alignment |
| sku | Retailer-internal | No check digit; unique only within sender |
| brand / product_name | Catalog copy | Brand owner assigns GTIN in GS1 model |
| unit_price / inventory_on_hand | Commerce | Cent-exact rollup after dedupe |
| source_system | Dedupe | Catalog / ERP / Ecommerce / Legacy |
| source_pkey | Dedupe | Pre-merge identity from sending system |
| variant_parent_id | Dedupe | Parent listing for size/colour variants |
| pack_size / unit_of_measure | Dedupe | Hard-negative separator (pk vs oz) |
| master_record_id / duplicate_type | Answer key | Null duplicate_type on original |
catalog_listing fixture (8 labeled rows)
Pre-merge staging: one row per inbound listing. Answer key columns are master_record_id and duplicate_type. Listings 7 and 8 are the hard negative (pack-size vs weight); they share near-identical titles but distinct GTINs and masters.
| listing_id | source_system | gtin_13 | sku | product_name | pack_size | uom | variant_parent_id | master_record_id | duplicate_type |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Catalog | 0999999123459 | RT-8834920-BLK-M | Synth Trail Jacket, Black, M | 100 | 1 | |||
| 2 | Ecommerce | 0999999123459 | TJ-BLK-M-002 | Synth Trail Jacket Black Medium | 100 | 1 | FUZZY | ||
| 3 | Legacy | 8834920BLKM | SYNTH TRAIL JCKT BLK M | 100 | 1 | FUZZY | |||
| 4 | Catalog | 0999999678904 | RT-8834920-BLK-L | Synth Trail Jacket, Black, L | 100 | 2 | |||
| 5 | Catalog | 0999999555120 | RT-1120044-RED | Placeholder Kettle, Red 500ml | 500 | ml | 3 | ||
| 6 | ERP | 0999999555120 | K-1120044-R | Placeholder Kettle Red 500 mL | 500 | ml | 3 | FUZZY | |
| 7 | Catalog | 0999999777775 | RT-1120044-RED-12PK | Placeholder Kettle, Red, 12-Pack | 12 | pk | 4 | ||
| 8 | Catalog | 0999999888884 | RT-1120044-RED-12OZ | Placeholder Kettle, Red, 12oz | 12 | oz | 5 |
Worked GS1 check digits (leading digits illustrative, not an assigned company prefix). GTIN-13 0999999123459: alternating 1/3 weights sum to 141; 150 − 141 = 9. GTIN-13 0999999888884: sum 196; 200 − 196 = 4. GTIN-13 0999999777775: sum 185; 190 − 185 = 5 (GS1 check-digit method, retrieved 2026-08-01).
Compliance framing
Test scenarios (6)
- Returns and partial refunds bounded by line subtotal.
- Restock after return when inventory_on_hand is 0.
- GTIN versus SKU at catalog ingest (SKU placed in GTIN column must fail/flag).
- Identifier-uniqueness governance across the catalog (one trade item = one GTIN).
- Peak-season concurrency: no oversell past inventory_on_hand.
- Catalog dedupe before pricing/inventory rollup against the 8-row answer key: listings 1 to 3 collapse; listing 4 stays separate; 5 and 6 collapse; 7 and 8 stay apart. Explicitly not CRM contact-dedupe.
Generate a larger version
Frequently asked questions
Can I remove dummy data without affecting my live store?
Yes, if the data was generated into a sandbox or development environment and not into production. Synthetic catalog, order, and shopper rows are generated rather than derived from real records, which means they carry no real customer information and no live inventory positions. The safe approach is to run the test environment on a separate database instance or use a store's staging mode, so deletion is a matter of truncating the staging tables rather than a surgical removal from a shared store. This is general practice for any test dataset, synthetic or otherwise. Generate-Data makes no guarantee about a specific platform's sandbox architecture; verify with your platform's documentation.
How do I differentiate dummy datasets from real-world datasets?
The pattern used in the fixture on this page is the answer key: each generated duplicate row carries a `master_record_id` pointing to its original and a `duplicate_type` label of EXACT or FUZZY. Original rows carry a null `duplicate_type`. That convention makes it machine-readable rather than dependent on visual inspection. For catalog listings specifically, the `source_system` and `source_pkey` fields preserve pre-merge identity, so a generated row is always traceable back to its feed origin. Real production datasets typically lack these columns; the presence of `master_record_id` and `duplicate_type` is itself a signal that the dataset is a generated fixture. Source: `21-vertical-differentiation.md` §3.3.
Can I use dummy data to test my Shopify store's target audience?
Dummy data can exercise the mechanics of audience segmentation (lifecycle stage assignment, geographic clustering, cart-abandonment cohorts) if the generated rows are realistic in shape. What it cannot do is tell you how a real audience behaves: generated shopper rows have no purchase history, no real browsing patterns, and no actual email engagement. For functional testing of segmentation logic, filters, and audience-export pipelines, a well-formed synthetic dataset is sufficient. For performance or predictive analysis that depends on real behavioral data, it is not. This is a general framing; no claim is made about how any specific platform handles audience data.