Orders by Channel.
At a glance
A breakdown of order count by Square channel, in-store (Square POS), web (Square Online Store), and invoiced (Square Invoices), over the last 30 days. Unlike the revenue split, this card counts orders, not money, so it shows where your transaction volume lives rather than where your value lives. The two often look very different: a Square merchant typically does most of its order count at the till and a smaller share online, while online and invoice orders carry far higher baskets.
| What it counts | Order count bucketed by Square Orders source.name (Square Online Store, Square POS, Square Invoices, and any third-party source writing to the Orders API). Every order in the window is counted once in its channel. |
| Channel / source treatment | The channel split is the entire point. Orders are grouped by source.name. This is native to Square because POS, web, and invoices all flow through one Orders API on a single merchant of record. |
| Currency / unit | Count of orders per channel (whole numbers), rendered as a donut so the share of each channel is visible at a glance. |
| Time window | 30D (rolling last 30 days) |
| Alert trigger | none. This is a composition card, not a threshold alarm. For sharp shifts in the mix, see Channel Mix Shift (vs prior). |
| Roles | owner, operations |
| Count vs value | This card counts orders. Revenue by Channel splits the money. The gap between the two is the per-channel basket size story. |
| Why POS usually dominates | In-store transactions are frequent and low-value, so POS almost always wins on count even when web or invoices win on revenue. |
Calculation
Calculated automatically from your Square Online 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 specialty grocer on Square. One busy retail store doing high-frequency small baskets, a Square Online storefront for pantry boxes and gift hampers, and Square Invoices for wholesale accounts. The window is the 30 days to 12 Apr 26.| Channel | source.name | Orders | Share of orders | Avg basket |
|---|---|---|---|---|
| Square POS (in store) | Square POS | 9,840 | 91.2% | $19 |
| Square Online Store (web) | Square Online Store | 870 | 8.1% | $64 |
| Square Invoices (wholesale) | Square Invoices | 76 | 0.7% | $580 |
| Orders by Channel (this card) | 10,786 | 100% |
- POS dominates the count but not the value. Nine in ten orders happen at the till, yet at a $19 basket they are not nine in ten of the revenue. Reading this card next to Revenue by Channel shows the inversion: web and invoices punch far above their order share on revenue.
- A tiny channel can carry outsized revenue. Just 76 wholesale invoices, less than 1% of orders, at a $580 basket can rival the entire web channel’s revenue. Order count alone would tell you to ignore invoices; the value lens corrects that. This is why both cards belong on the same dashboard.
- This card has no alert by design. The mix is a stable characteristic of the business, not an event. To catch a genuine swing, for example POS orders collapsing during a store closure, use Channel Mix Shift (vs prior), which is built to alert on sharp pp moves.
Sibling cards merchants should reference together
| Card | Why pair it with Orders by Channel |
|---|---|
| Revenue by Channel (POS / Online / Invoices) | The value mirror. Orders by Channel shows count; that card shows money. The gap between them is per-channel basket size. |
| Channel Mix Shift (vs prior) | The alerting version. This card is a static snapshot; that one fires when the mix moves sharply versus the prior period. |
| Total Orders | The denominator. Orders by Channel is just Total Orders split by source.name; the two should always sum consistently. |
| Average Order Value | Explains why a small channel by count can be large by revenue. Per-channel basket size is the bridge between the two. |
| Revenue by Location (in-store) | A complementary cut. Channel splits by source; location splits by store. Together they describe where volume and value originate. |
| Customer Capture Source (POS vs Online) | The customer-acquisition mirror of order channel mix. Where orders happen often predicts where customers are first captured. |
Reconciling against Square
Where to look in the Square Dashboard: Square Dashboard, Reports, Sales summary. Group the report by source or channel for the same 30-day window and read the order count (transaction count) per channel. The per-channel counts should match this card closely. Note that Square’s sales reports often lead with sales value, so make sure you are reading the count column, not the revenue column. Other Square Dashboard views that look like the same thing but aren’t:- Sales summary, grouped by source, transaction count column: this is the right reconciliation for order count.
- Sales summary, grouped by source, sales value column: this is the revenue split, reconcile that against Revenue by Channel, not this card.
- Reports, Payments: counts payment events, not orders. One order with a split tender can show as two payments and overcount.
- Sales by location: the location split, a related but different axis from channel.
| Reason | Direction of divergence |
|---|---|
Source attribution. How each order’s source.name maps to a channel must be consistent. A third-party integration writing to the Orders API can land in an unexpected bucket. | Small count differences if a source is bucketed differently |
| Order vs payment counting. This card counts orders; a payment-based dashboard view counts tenders. Split-tender orders inflate a payment count. | Dashboard higher if it counts payments |
| Time-zone. Square reports run on the location’s local time zone; Vortex IQ runs on UTC by default. Orders near the window boundary fall on different sides. | Boundary days off by a few orders |
| Sync lag. The most recent orders may take a short cycle to reach our index. | Self-resolves within minutes |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
| Total Orders | Channel counts should sum to total orders | Both read the same Orders API. Any gap means an order’s source did not map to a known channel bucket. |
google_analytics.total-orders | GA4 only sees the web channel | Square POS and invoice orders never reach GA4, so GA4’s order count should approximate only the Square Online Store slice of this card, minus the usual tracking gap. Treat Square as the source of truth. |
Known limitations / merchant FAQs
Why does POS have so many more orders than online? Because in-store transactions are frequent and small, a coffee, a sandwich, a single item, while web and invoice orders are fewer but larger. High order count at the till is normal and healthy. To see where the value lives rather than the volume, read Revenue by Channel. How are channels determined? From the Square Orderssource.name, which distinguishes Square Online Store (web), Square POS (in store), and Square Invoices. Because all three share one merchant of record, the split is native to Square’s Orders API rather than stitched together from separate systems.
Why is there no alert on this card?
Because the channel mix is a stable property of the business, not an event. A grocer will always do most of its orders at the till. The card that alerts on a genuine swing in the mix is Channel Mix Shift (vs prior); this one is for understanding the steady-state shape.
Should the channel counts add up to Total Orders?
Yes. Every order belongs to exactly one channel, so the channel counts should sum to Total Orders for the same window. If they do not, an order’s source did not map to a recognised channel bucket, usually a third-party integration writing an unusual source.name.
A small channel looks unimportant here. Should I ignore it?
Not necessarily. A channel that is tiny by order count can be large by revenue, wholesale invoices are the classic case. Always read this card next to the revenue split before deciding a channel does not matter.
Why count orders instead of just looking at revenue?
Because count and value tell different operational stories. Order count drives staffing, packing capacity, and till throughput, regardless of basket size. A spike in web order count is a fulfilment workload signal even if the revenue is modest.
Can I see this split per location as well as per channel?
Channel and location are separate axes. This card splits by source.name; for the per-store view use Revenue by Location (in-store). A multi-location merchant often wants both: which channel and which store.