The share of orders placed by guests versus registered account holders.
At a glance
A donut split of orders over the rolling 30 days into guest checkout versus registered-account checkout. Ecwid permits guest checkout by default, which removes friction but also removes the email reach you would otherwise get for re-engagement. A high guest share means lower contactability: you are converting buyers but not capturing a relationship with them.
| What it counts | COUNT(orders placed as guest) versus COUNT(orders placed by a registered customer) over the rolling 30D window, expressed as a two-segment share. |
| API endpoint | GET /v3/{store-id}/orders (paged, max 100 per call, OAuth2 with read_orders scope); each order indicates whether it was tied to a registered customer or placed as a guest. Webhook updates fire on order.created. |
| What “guest” includes | Any order completed without the buyer being signed in to a store account. Ecwid allows guest checkout out of the box, so this is common for first-time buyers. |
| What “registered” includes | Any order where the buyer was signed in to, or created, a store account at checkout. |
| What it excludes | Cancelled-before-payment orders; staff test orders flagged as such. |
| Currency | Not applicable; this is an order-count share. |
| Time window | 30D vsP (rolling 30D vs prior 30D). |
| Alert trigger | None - informational. |
| Roles | owner, marketing. |
Calculation
Calculated automatically from your Ecwid 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 small UK coffee roaster running an Ecwid widget on a Webflow site, rolling 30D ending 18 May 26. The roaster sells whole-bean and ground coffee plus a few brewing accessories. Guest checkout is on because the merchant wanted the fastest possible path to a first order.| Segment | Orders (this 30D) | Share | Prior 30D share |
|---|---|---|---|
| Guest | 168 | 62% | 58% |
| Registered | 102 | 38% | 42% |
| Total | 270 | 100% | 100% |
Sibling cards merchants should reference together
| Card | Why it matters next to the guest/registered split | What the combination tells you |
|---|---|---|
| Total Customers | Your contactable base. | High guest share explains a customer count that lags order count. |
| New Customers | Account inflow. | Falling new customers + rising guest share = remarketing reach shrinking. |
| Repeat Customer Rate | The cost of low reach. | High guest share usually drags repeat rate down for consumables. |
| Repeat Purchase Rate | Order-level loyalty. | Confirms whether the unreachable guests come back anyway. |
| Total Orders | The denominator. | Order growth driven entirely by guests is fragile growth. |
| High-Value Customers Unengaged on Email | Who to recover. | Pinpoints valuable registered buyers you are still failing to reach. |
| Conversion Rate | The trade-off. | Guest checkout lifts conversion; this card shows the reachability you trade for it. |
Reconciling against Ecwid
Where to look in Ecwid’s own dashboard:
Ecwid Control Panel (my.ecwid.com) -> My Sales -> Orders
Filter the order list and inspect whether each order is tied to a registered customer; guest orders show no linked account.
For a quick sanity check, sample a page of recent orders and compare the guest-to-registered ratio against the card.
Why our number may differ from Ecwid’s Control Panel:
| Reason | Direction | Why |
|---|---|---|
| Account created at checkout | Either | If a buyer creates an account during a guest-style checkout, Ecwid may classify the order as registered; we follow the order’s final account linkage. |
| Time zone | Boundary days | Ecwid uses store-local; we use UTC. The boundary effect on a 30D window is small. |
| Cancelled orders | Theirs higher | Some Ecwid views include cancelled orders in the split; we exclude them. |
| Sync lag | Marginal | Webhook-driven; the most recent orders may not be in for a few minutes. |
| Merged customer records | Marginal | If a guest order is later linked to a merged account, our classification may shift on re-sync. |
guest_share = COUNT(guest orders) / COUNT(all paid orders) over the same window; registered_share = 1 - guest_share.