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.
Calculation
Worked example
A US homewares brand on BigCommerce Pro with 6,565 catalogue products, snapshot at 12 Apr 26.
What’s interesting:
- 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
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:
Cross-connector reconciliation:
Same-metric documentation cross-reference:
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.