At a glance
Order count by device type (mobile, desktop, tablet) over the trailing 30 days. The mobile-vs-desktop split that determines whether the merchant’s checkout investments should be mobile-first. BigCommerce’s Stencil framework supports responsive themes natively, but theme implementation varies; this card surfaces whether the mobile experience is converting in line with desktop. Note: BC’s mobile checkout doesn’t have a native equivalent of Shopify’s Shop Pay, so mobile conversion is more theme-dependent.
| What it counts | COUNT(orders) GROUP BY device_type over the trailing 30 days. Device type derives from customer_user_agent parsed at order time, classified into mobile / desktop / tablet / unknown. Excludes Cancelled and Incomplete orders. |
| API endpoint | BC /v2/orders exposes customer_user_agent; we parse via UA-Parser library at index time. The OpenSearch index materialises per-device-per-day order counts. |
| VAT / tax treatment | n/a, count metric. |
| Shipping | n/a. |
| Discounts | n/a. |
| Refunds | Refunded orders still count by their original device. |
| Cancelled orders | Excluded. |
Incomplete orders | Excluded. |
| Currency | n/a. |
| Channel coverage | Web channel only by default. POS sales have no meaningful “device” (the POS terminal IS the device); marketplaces don’t expose device. Configure Settings → Channel filter to web-only for a clean read; default already does this. |
| B2B Edition behaviour | B2B portal access is typically desktop-heavy (60-80%) because wholesale buyers use office computers. A B2B portal mobile-share above 25% is unusual, usually means a procurement-app integration. |
| Tablet treatment | Tablets are often grouped with mobile in retail conventions (touch-first UX) but as desktop in some analytics conventions (larger screen). We surface as a separate row; configure under Settings → Device classification → Tablet-as-mobile if you prefer the merge. |
| Unknown / bot detection | UAs that don’t match common patterns are classified as “unknown”; bot UAs are excluded. The unknown bucket is typically <2%; higher unknown rate indicates UA-spoofing or bot traffic that survived filtering. |
| Time window | 30D rolling. |
| Alert trigger | None on this card; pairs with BC Channel Conversion Rate for device-specific funnel alerts. |
| Roles | owner, marketing |
Calculation
Calculated automatically from your BigCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US fashion brand on BigCommerce Pro, web-only view (DTCchannel_id = 1). Snapshot for 1 Apr to 30 Apr 26.
| Device | Orders | % | AOV (context) | Conversion (context) |
|---|---|---|---|---|
| Mobile | 2,820 | 58.5% | $98 | 2.1% |
| Desktop | 1,560 | 32.4% | $145 | 4.2% |
| Tablet | 380 | 7.9% | $128 | 3.6% |
| Unknown | 60 | 1.2% | $112 | n/a |
| Total | 4,820 | $120 (headline) | 2.7% (web headline) |
- Mobile dominates order count (58.5%) but desktop dominates AOV (98). This is the classic mobile-vs-desktop pattern: more mobile sessions and orders, smaller mobile baskets, larger desktop baskets. Mobile customers tend to be browse-and-buy in a single session; desktop customers tend to research, save-cart, return-and-buy with larger baskets.
- Conversion rate gap (2.1% mobile vs 4.2% desktop) is the bigger lever. Desktop converts at 2x mobile, even though mobile has more sessions. The biggest revenue-lift opportunity for this merchant: closing 30% of the mobile-desktop conversion gap (from 2.1% to 2.7%) would add $86k/month in revenue. The cause is usually checkout friction, slow page-loads, awkward form fields, no Apple Pay / Google Pay.
- Mobile 145 = a 32% gap. Mobile customers buy fewer items per cart. Bundle / upsell strategies that work on desktop (sticky sidebar, “complete the look” suggestions) often render poorly on mobile. The mobile bundle UX is the single highest-leverage AOV improvement opportunity.
- Tablet at 7.9% with desktop-like AOV ($128) and conversion (3.6%) confirms tablet behaves more like desktop than mobile for this merchant. The Stencil theme renders well on tablet; tablet customers behave like desktop customers, just on a smaller screen. For this merchant, tablet should be optimised alongside desktop.
- Unknown at 1.2% is acceptable. Above 5% would suggest UA-spoofing or bot traffic; 1.2% is normal hand-jamming and obscure-device noise.
- Audit mobile checkout flow. Mobile conversion below 2x desktop is the single highest-leverage improvement on most BC stores.
- Implement Apple Pay / Google Pay. BC supports both; many merchants haven’t enabled them. Adding adds 0.3-0.7pp to mobile conversion.
- Audit mobile bundle / upsell UX. Mobile AOV under 145 desktop AOV is a fixable gap.
- Audit page-load speed on mobile. Stencil theme JS-heaviness is the most common cause of mobile-conversion underperformance.
- Pair with BC Channel Conversion Rate to see device-specific funnel quality.
Sibling cards merchants should reference together
| Card | Why pair it with Orders by Device |
|---|---|
| BC Channel Conversion Rate | Device-specific conversion analysis. |
| BC Revenue by Device | Revenue side; device count × AOV. |
| BC Alert Abandoned Cart Spike | Mobile-specific abandonment is a common pattern. |
| Average Order Value | Headline AOV context. |
| BC Orders by Channel | Channel context; web channel breaks down by device. |
| BC Channel AOV | Per-channel AOV; web AOV is dragged down by mobile. |
| BC Top Coupons | Mobile-specific promo cycles. |
| Total Revenue | Revenue context for prioritisation. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: BigCommerce does not natively surface device-level order analytics. The closest views require GA4 connected: Analytics → In-store Conversion shows store-wide; for device split connect GA4 and view in GA4’s “Tech → Device category” report. Some BC apps (e.g. Yotpo, Klaviyo dashboards) surface device-level views, but they’re third-party. For order-level UA inspection: Orders → individual order shows the customer user-agent string in the order details. Why our device split may differ from GA4:| Reason | Direction |
|---|---|
| UA-Parser version. Different parsers classify edge-case UAs (older browsers, unusual devices) differently. | Sub-2% gap |
| Tablet classification. We surface tablet as separate; GA4 typically merges into mobile. Stores comparing should align convention. | Different rows |
| Bot filtering. We filter known bots; GA4 has its own bot exclusion. | Sub-1% gap |
| Order-time vs session-time UA. We use the UA at order-completion; GA4 uses session-start UA. For multi-device sessions, the two diverge. | Sub-3% gap |
| Webhook-vs-pageview. We detect at BC webhook receipt; GA4 detects at JS-tag fire. Different timing windows. | Cosmetic |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
google_analytics.ga_orders_by_device | Match within 5-10% | GA4 misses 10-25% of orders (consent / blockers); the gap is consistent across devices. |
klaviyo.kl_purchase_by_device | Klaviyo’s email-attributed purchases by device align with web-channel device split | Klaviyo subscribes a subset of customers; coverage differs. |
Browser/UserAgent parsing) and Adobe Commerce (per client_ip UA derivation); merchant-facing semantics are equivalent.
Known limitations / merchant FAQs
Why is my mobile share so high (60%) but my mobile revenue share only 45%? Because mobile AOV is lower. 60% of orders × (120 headline AOV) = ~50% revenue contribution. The gap reflects basket-size difference, not a metrics issue. Closing the mobile AOV gap (via mobile-friendly bundle UX) is the highest-leverage revenue lift. My mobile conversion rate is 1.4% but desktop is 3.8%. Is mobile broken? Probably. A 2.5x desktop-to-mobile conversion gap is bigger than the BC ecosystem norm (typically 1.5-2x). Audit (a) page-load speed (Stencil JS-heaviness is the #1 culprit), (b) checkout form friction (number of fields, autofill support), (c) Apple Pay / Google Pay enabled (BC supports both natively, but many merchants haven’t enabled them), (d) image-heavy mobile pages slowing down LCP. Should tablet be counted as mobile or desktop? Depends on your category. For touch-first UX (fashion, food), tablet behaves like mobile. For research-heavy categories (electronics, B2B), tablet behaves like desktop. We surface separately by default; configure under Settings → Device classification → Tablet-as-mobile if you prefer the merge. My BC dashboard doesn’t show device breakdown. Is this card BC-native? No, BC’s main analytics doesn’t natively surface device-level orders. We compute via UA parsing on the order’scustomer_user_agent. The card adds visibility BC’s stock dashboard lacks, which is one of the reasons it’s a high-value card for BC merchants who haven’t connected GA4.
Why is my unknown bucket 8%?
Above 5% suggests either (a) bot traffic surviving filters, (b) UA-spoofing customers (some privacy-focused users), (c) older browsers we don’t recognise. Audit the UA strings in the unknown bucket; if patterns emerge, we can add classifications. Configure under Settings → Device classification → Custom rules.
My B2B portal shows 80% desktop. Real?
Yes, that’s normal. Wholesale buyers use office computers; mobile B2B portal access is rare. A B2B portal mobile-share above 30% is unusual and usually means a procurement-app integration (the customer’s procurement system makes the order via a mobile-tagged UA).
Does this card include marketplace orders?
No, marketplaces don’t expose device. Default scope is web-only (channel_id = 1). Marketplace orders are device-blind and excluded.
Why is the alert trigger missing?
Because device shifts are slow and structural, not anomaly-driven. The right alarm is conversion-rate-per-device-drop, which lives on BC Channel Conversion Rate with device decomposition. Configure custom device-conversion alerts under Settings → Custom alerts.
My multi-storefront BC instance has different theme variants per storefront. Does this card aggregate?
By default per-storefront. Each storefront’s theme has its own mobile UX; aggregating produces meaningless rollups. Use the storefront filter to compare device performance across storefronts.
Should I implement Apple Pay even if my mobile already converts well?
Generally yes. Apple Pay adds 0.3-0.7pp to mobile conversion across BC stores; the implementation cost is one settings toggle. Even mobile-strong stores benefit. Google Pay similar effect for Android-heavy traffic.