At a glance
Catalogue product count grouped by type (BC’s product-type field: physical, digital, gift_certificate, bundled, configurable, etc.). Tells you the structural composition of the catalogue, which is critical for fulfilment planning, tax handling, and channel routing.
| What it counts | GROUP BY type over every product in the catalogue. The type field is BC’s structural classification, distinct from category (which is merchandising) and from tags (which is marketing). |
| VAT / tax treatment | n/a, catalogue metadata. The type itself influences tax handling (digital products have different VAT rules in the EU; gift certificates are not taxed at issue). |
| Shipping | The type determines shipping logic. physical ships; digital doesn’t; gift_certificate doesn’t; bundled ships if any constituent is physical. |
| Discounts | n/a. |
| Refunds | n/a. |
| Cancelled / voided orders | n/a. |
| Currency | n/a. |
| Channels / sources | Catalogue-wide. Channel-specific behaviour: digital products typically don’t ship to POS or Amazon FBA; gift certificates often don’t sync to marketplace channels at all (BC blocks them). |
| The BC product type vocabulary | physical (the default, ships): ~85-95% of typical catalogues. digital (downloadable, no shipping): software, music, ebooks, design assets. gift_certificate (no shipping, no inventory): gift cards. bundled (multiple SKUs sold as one unit): multi-piece sets. configurable (variant-driven, multiple SKUs under one product): apparel sizing, colour variants. |
| Type vs Category vs Tags | Type is the structural layer (how the system handles it). Category is the navigation layer (how customers find it). Tags are the marketing layer (filters, rules, automation). The three are orthogonal, a digital ebook can be in the “Cookbooks” category and tagged bestseller; type=digital is system-level metadata that drives behaviour. |
| Why type matters operationally | Tax engines (Avalara, TaxJar) read type to determine VAT / sales-tax rules. Shipping engines (ShipStation) read type to determine whether to create a label. Channel feeds (Amazon, Google Shopping) filter by type to exclude incompatible products. A misclassified product (digital saved as physical) breaks the entire downstream chain. |
| B2B Edition | B2B catalogues often use bundled types for kit-pack SKUs (5-piece sets ordered as one). Acceptable pattern; ensures customer sees bundled pricing while warehouse picks individual SKUs. |
| Time window | RT (real-time, refreshed each catalogue sync) |
| Alert trigger | None at this card. |
| Roles | owner, operations |
Calculation
Worked example
A US homewares brand on BigCommerce Pro with 6,565 catalogue products, snapshot at 12 Apr 26.| Type | Product count | Share | Notes |
|---|---|---|---|
physical | 6,180 | 94.1% | The bulk of catalogue, ships normally |
bundled | 240 | 3.7% | Multi-piece sets (4-piece bedding, towel sets) |
configurable | 95 | 1.4% | Variant-driven (size / colour) |
digital | 38 | 0.6% | Brand-extension digital downloads (recipe ebooks) |
gift_certificate | 12 | 0.2% | Gift cards |
- 94.1% physical is healthy for homewares. Mature D2C catalogues skew 85-98% physical; specialised digital-heavy stores (software, content) skew the other way. Healthcare and medical-device stores often have 70-85% physical because of consumables-vs-prescription splits.
- 3.7% bundled is sophisticated. Most BC stores under-use bundled; they sell each SKU separately and let customers add to cart manually. Bundled products (priced as a unit) typically lift AOV 8-15% vs separate-line equivalents because the “set” framing creates perceived value. This store is doing it right.
- 0.6% digital is a brand-extension play. A homewares store selling recipe ebooks is monetising adjacent customer interest without inventory. Digital revenue at 0.6% of products often translates to 1-3% of revenue (lower AOV) but at near-100% margin, attractive economics.
- 12 gift certificates is normal for a 6.5K-product catalogue. Gift cards typically have 1-3 SKUs per denomination; this store has 12 (probably 50 / 250 cards × physical + digital variants, roughly). Important: gift cards must be
type = gift_certificate, notphysical, otherwise tax engine and shipping engine will treat them wrongly. - Misclassification risk is invisible from this card alone. If a digital ebook is mistakenly saved as
physical, it appears in the physical bucket. The only diagnosis: cross-reference orders for these SKUs, do they have shipping costs? If yes, classification is correct; if zero shipping despite physical type, misclassification.
- Verify gift-certificate type. Spot-check by SKU: every gift card should be
type = gift_certificate. Anything else means the tax / shipping engine treats it wrongly. Worth a 5-minute audit. - Verify digital products don’t have shipping costs configured. A digital ebook with shipping rules attached creates customer-facing confusion (checkout shows shipping that doesn’t apply).
- For bundled products, audit constituent stock. A bundled SKU is “in stock” only if all constituents are. BC’s stock logic handles this if configured; misconfiguration sells unfulfillable bundles.
- Cross-reference channel feeds. Marketplace feeds (Amazon, eBay) filter by type. Verify which types are feeding to which channels; misconfigurations either omit revenue or expose unsuitable products.
- Audit configurable products’ variants. A configurable product with empty variants behaves oddly (shows in storefront but can’t be ordered). Configurable count should match the number of products that genuinely need size/colour variants.
Sibling cards merchants should reference together
| Card | Why pair it with Products by Type |
|---|---|
| Product Status | Status × type combinations show whether digital products are live, whether bundled products are configured correctly. |
| Products by Vendor | Vendor decomposition; some vendors specialise in bundled or configurable. |
| Top Product Tags | Tag × type overlap; tags often correlate with type structure. |
| Top Products | Type breakdown of top revenue. Bundled and configurable products often dominate top revenue lists. |
| Free vs Paid Shipping | Digital products contribute to free-shipping share regardless of threshold. |
| Total Tax | Tax behaviour varies by type (digital VAT, gift-card tax exemption). |
| BC Channel OOS per Channel | Channel listing depends on type; type misclassification breaks channel feeds. |
| Inventory Alerts | Bundled products’ stock = MIN(constituent stock); type drives inventory rules. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Catalogue → Products supports a Type filter. Bulk-export to CSV with the Type column to count by type manually. For tax-engine validation, Settings → Tax shows which types are taxed and how; cross-reference that all expected types are present. For shipping-engine validation, Settings → Shipping shows which types are shippable; digital and gift-certificate types should be excluded. Why our number may legitimately differ from BC catalogue view:| Reason | Direction |
|---|---|
Type field nulls. Older imported products may have type = null; we treat null as “physical” (the BC default); BC’s filter may show them under “all”. | Same direction with semantics |
| Disabled products. We include them; BC’s filter may default to visible. | Vortex IQ HIGHER |
| Sync lag. Recent type changes propagate within 5-30 minutes. | Vortex IQ slightly LAGS |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
avalara.av_taxable_products | Avalara’s count of products mapped to a tax category | Mapping is configured per type; misconfigured types skip the tax engine. |
shipstation.ss_shippable_products | ShipStation’s shippable-product count | Should equal physical + portion of bundled; digital and gift_certificate excluded. |
shopify.products_by_type(planned)adobe_commerce.products_by_type(planned)
Known limitations / merchant FAQs
My gift cards are showing asphysical, is that a problem?
Yes. Gift cards classified as physical trigger shipping-engine charges (creating customer-facing confusion: “why is there shipping on a digital gift card?”) and may be taxed at the wrong rate. Update gift-card products to type = gift_certificate immediately.
Should every multi-piece set be bundled?
Depends on inventory model. If you stock the set as a single SKU pre-assembled, use physical. If you assemble from constituent SKUs at pick time, use bundled. The bundled type lets you maintain individual constituent stock; physical treats the set as one inventoried unit. Most homewares stores use physical for low-volume sets, bundled for high-volume sets where individual constituents are also sold separately.
My catalogue has 200 configurable products, why doesn’t BC show them?
Configurable is the parent product; the storefront actually sells the variants underneath. The 200 configurable parents represent ~600-2,000 sellable variants depending on size/colour matrix. The catalogue view shows parents; the order view shows variants. Both are right, just different layers.
Do digital products show up in marketplace feeds?
Channel-dependent. Amazon Channel Manager generally excludes digital products (Amazon has its own digital-content channels). Google Shopping accepts digital products. Audit each channel’s product-eligibility settings.
My type field is empty for older products, what should I do?
BC defaults to physical when type is null at runtime, so the storefront behaviour is usually correct. For data hygiene, run a bulk update: any product with null type and no shipping costs configured = digital; with shipping costs = physical. A 1-2 hour cleanup that prevents future confusion.
Why does my B2B kit-pack SKU not appear as bundled?
Two possibilities. (1) It was created as physical with no underlying constituent SKUs; the kit is stocked as a single unit. (2) The bundled configuration wasn’t completed. Check the product detail in BC admin; if it has child SKUs configured, it should be bundled.
Does this card include disabled products?
Yes by default. To see only live catalogue type breakdown, filter availability = available.
My tax engine is wrong on digital products, what’s the diagnosis?
Two-step audit. (1) Confirm the products are type = digital here; if any are physical, fix that first. (2) Cross-check Avalara / TaxJar’s mapping; some tax engines need a separate digital-product flag beyond the BC type. Common configuration error: type is right but tax engine wasn’t told digital exists.
Can I create custom types?
No, BC’s type vocabulary is fixed: physical, digital, gift_certificate, bundled, configurable. Custom merchandising classifications belong in tags or categories, not types.
Why do my POS terminals not show digital products?
POS interfaces typically filter to type = physical because POS implies in-store handover. If you genuinely sell digital products via POS (e.g. ebook download codes printed on receipt), configure the POS interface to include digital types; otherwise the default exclusion is correct.