OpenSearch COUNT(_id) GROUP BY channel_id. Volume breakdown complementing the revenue mix, surfaces channels with high traffic but low AOV.
At a glance
Order count per channel_id over the trailing 30 days, the volume companion to BC Channel Revenue Mix (revenue) and BC Channel AOV (price). Reading order count alongside revenue surfaces the high-volume / low-AOV channels (typically Amazon, Facebook Shop) that look small on revenue but dominate transaction count, and the low-volume / high-AOV channels (B2B portal) that look small on count but carry the revenue.
| What it counts | COUNT(orders) GROUP BY channel_id over the trailing 30 days, excluding Cancelled (status_id = 5) and Incomplete (status_id = 0). Each channel shows order count and percentage of store total. |
| API endpoint | OpenSearch COUNT(_id) GROUP BY channel_id aggregating BC /v2/orders data. Channel display names from GET /v3/channels. |
| VAT / tax treatment | n/a, count metric. |
| Shipping | n/a. |
| Discounts | n/a. |
| Refunds | Included in count, refunded orders still occurred. |
| Cancelled orders | Excluded. |
Incomplete orders | Excluded. |
| Currency | n/a. |
| Channel coverage | All BC channels. B2B portal typically shows low order count (5-15% of total) despite carrying 30-60% of revenue (because of high AOV). Marketplaces typically show outsized order counts relative to their revenue share (high volume, low AOV). |
| B2B Edition behaviour | B2B portal contributes its order count normally. The B2B order-count-vs-revenue gap is the structural pattern: 10% of orders, 40% of revenue typical. |
| Multi-storefront | Per-storefront breakdown via the storefront filter. Each storefront aggregates its channels by default. |
| POS terminal aggregation | Each POS terminal is its own channel_id; aggregating is per-terminal by default. For “All POS” rollup configure under Settings → Channel grouping. |
| Time window | 30D rolling. |
| Alert trigger | None on this card; pairs with BC Alert Channel Revenue Drop for revenue-side alerting. |
| Roles | owner, marketing, operations |
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 apparel brand on BigCommerce Pro, multi-channel with B2B Edition. Snapshot for 1 Apr to 30 Apr 26.channel_id | Channel | Orders | % | Revenue (context) | AOV (context) |
|---|---|---|---|---|---|
1 | DTC web | 4,820 | 60.5% | $578,400 | $120 |
1019847 | Amazon Channel Manager | 1,140 | 14.3% | $159,600 | $140 |
1019850 | Facebook Shop | 380 | 4.8% | $19,760 | $52 |
1020111 | Walmart | 220 | 2.8% | $21,120 | $96 |
12000004 | B2B portal | 612 | 7.7% | $1,224,000 | $2,000 |
1020114 | POS Terminal A | 380 | 4.8% | $24,700 | $65 |
1020115 | POS Terminal B | 422 | 5.3% | $26,800 | $63 |
| Total | 7,974 | $2,054,380 | $258 (headline AOV) |
- B2B portal at 7.7% of orders contributes 60% of revenue. This is the structural B2B-vs-DTC pattern. The order count makes B2B look small; the revenue makes it look huge. Reading either alone misses the picture; reading both together is correct.
- Amazon at 14.3% of orders contributes 8% of revenue. Lower revenue share than order share because Amazon AOV (258, B2B-inflated). On a DTC-only basis (excluding B2B portal), Amazon would be 16% of orders and 19% of DTC revenue, more proportionate.
- Facebook Shop at 4.8% of orders contributes 1% of revenue. Volume contributor without revenue contribution. The strategic question: is Facebook Shop’s 380 orders/month at $52 AOV worth the operational complexity of running it? For most BC merchants, yes, the orders are incremental (would not have come through other channels) and absorb little operational cost. But the read is honest.
- POS terminals together = 802 orders, 10.1% share. A meaningful volume contributor on count terms; the two terminals’ combined revenue is $51,500 (2.5% of total). POS is a community / brand-presence channel as much as a revenue channel.
- The DTC web 60.5% order share is healthy. A web-dominant store with diversified marketplace and POS contribution is the BC ecosystem norm; aspirational target around 55-65% web. Above 80% web is over-concentrated; below 40% suggests the web channel is under-performing.
- Read alongside BC Channel Revenue Mix, count and revenue together is the right read.
- Compute order-share / revenue-share ratio per channel to spot mix inefficiencies.
- For low-AOV high-volume channels (Facebook), evaluate whether the order count justifies the operational burden.
- For high-AOV low-volume channels (B2B), evaluate whether the revenue concentration is healthy or fragile (one big customer leaving = revenue collapse).
- For multi-storefront stores, view per-storefront to spot storefront-specific channel patterns.
Sibling cards merchants should reference together
| Card | Why pair it with Orders by Channel |
|---|---|
| BC Channel Revenue Mix | Revenue side of the count / revenue dual read. |
| BC Channel AOV | The price side; AOV × count = revenue. |
| BC Channel Revenue Trend | Trend over time per channel. |
| BC Alert Channel Revenue Drop | Revenue-side alarm complementing the volume view. |
| Order Count | Headline rollup. |
| BC Channel Conversion Rate | Surfaces whether order volume reflects healthy funnel. |
| BC Guest vs Registered | Cohort context, B2B-heavy channels skew registered. |
| BC Orders by Device | Device decomposition for web-channel orders. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Analytics → Sales → “Sales by channel” view (Plus / Pro / Enterprise) shows per-channel order count alongside revenue. Channel Manager → individual channel shows per-channel order list with totals. For B2B Edition: Channel Manager → B2B Edition → Orders shows B2B portal orders separate from DTC. Why our count may differ from BC Sales by channel:| Reason | Direction |
|---|---|
| B2B Edition treatment. We include B2B; BC main analytics excludes by default. | Vortex IQ HIGHER total |
| Multi-storefront aggregation. We aggregate across storefronts; BC shows per-storefront. | Different denominators |
| POS terminal aggregation. BC may roll all terminals; we surface each. | Different granularity |
| Cancelled / Incomplete handling. We exclude both; BC’s Sales tile in some plan tiers includes Incompletes. | Vortex IQ LOWER count |
| Refund attribution. Refunded orders still count in our metric; BC’s varies. | Vortex IQ HIGHER if refund-counted |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
amazon_sp.amazon_order_count | Amazon SP-API order count matches Amazon channel slice within 1% | SP-API may include orders not yet synced to BC; sub-1% gap. |
facebook.fb_shop_orders | Facebook Shop order count matches Facebook channel slice | Meta’s reporting includes some pending orders; we count completed only. |
google_analytics.ga_purchase_events | GA4 purchase events should match web channel within 10-25% | GA4 misses orders due to consent-mode and ad-blockers. |
source_name) and Adobe Commerce (per store_id); merchant-facing semantics are equivalent.
Known limitations / merchant FAQs
My headline order count is 7,974 but BC reports 7,500. Why the gap? Likely B2B Edition inclusion. BC’s main analytics excludes B2B by default; we include. The B2B portal contributed 612 orders here, close to the 474-order gap (the rest is Incomplete handling differences). Filter to DTC-only in Vortex IQ to match BC. Why does my Facebook Shop have so few orders relative to web? Facebook Shop is a discoverability channel; most BC merchants see 1-5% of order count from it. Higher percentages (>10%) usually indicate a viral moment or a specific ad strategy. Lower (<1%) usually indicates Meta ad spend isn’t directing to the Facebook Shop properly. My B2B portal has only 612 orders but my B2B revenue is huge. Real? Yes, B2B order count is structurally low because each order is large. 612 wholesale orders at 1.22M revenue, that’s the B2B-vs-DTC math. Reading order count alone undersells B2B; always pair with revenue. Should I count Incomplete orders as orders? No. Incompletes are abandonments; they didn’t place a real order. Including them inflates count without reflecting business activity. We exclude by default. My Amazon channel order count dropped 30% MoM. Should I be alarmed? Yes, but check whether revenue dropped too. If revenue is flat with order count down 30%, your Amazon AOV grew (basket size up, fewer baskets, same dollars), often the result of curating to higher-AOV bundles. If revenue dropped proportionally, that’s a real channel issue. Cross-reference with BC Channel Revenue Trend. Multi-storefront stores: do counts aggregate or split? By default per-storefront. Each storefront has its own channels; aggregation produces meaningless rollups. Use the storefront filter to switch. My POS terminal A and B together = 802 orders. Should I see them as one POS row or two? Configurable. Default per-terminal (each terminal is its ownchannel_id). For aggregated POS, configure under Settings → Channel grouping → POS rollup. Multi-terminal stores often prefer aggregated for executive views and per-terminal for operational reads.
Why doesn’t this card alert?
Because count alone isn’t enough information for an alert; revenue impact varies by AOV. The corresponding alarm is BC Alert Channel Revenue Drop which incorporates revenue context. Configure custom count-based alerts under Settings → Custom alerts if needed.
My new channel launched 14 days ago and shows just 12 orders. Is something wrong?
Probably ramp-up. New channels typically show 0-50 orders in their first 30 days. Expect channel velocity to plateau by day 60-90; if a channel is still <100 orders/30days at day 90, the channel may not be working for your category.
Can I export the channel-count breakdown?
Yes, click the export button on the card. CSV / XLSX with per-channel count, revenue, and AOV columns.