Ecommerce
Orders, what was in them, and what the shop actually kept.
Until now an order was a few extra columns on a lead, which meant three things were impossible: telling a shipping change from a change in what people bought, seeing which products drove a day, and — the expensive one — recording money going back. Revenue could only ever rise.
Where orders come from
The WordPress plugin, and only the WordPress plugin. Orders are reported server-to-server using your site's secret API key.
There is deliberately no way for a browser to report an order. The script-only install authenticates by the page's origin, which is enough for error and analytics data but not for money: anyone able to read a public key out of a page could otherwise invent revenue in your dashboard.
So a site running the loader script alone — including a Shopify store — collects everything else and shows a sentence here instead of a row of zeros.
The four tabs
| Tab | What it answers |
|---|---|
| Overview | How the shop did: revenue, orders, average order value, cart abandonment, revenue over time, what sold, and the checkout journey. This is where the screen opens. |
| Orders | Every order, with the status your shop gives it. |
| Checkouts | People who reached the basket and did not buy — blocked by an error, or changed their mind. The ones who paid are orders, and they are on the Orders tab. |
| Products | Which products get looked at, which get bought, and which do neither. |
The date range at the top of the page applies to Overview, Checkouts and Products. Orders lists every order you have ever taken, so it takes no window — a list of money is one you scroll rather than one you narrow to the last thirty days without being asked.
The same customer, on the page you already opened
An order page and a checkout page both carry This customer — their other orders, their other checkouts, chats they started, recorded visits, and errors that fired in those visits.
There is no separate Customers screen, and that is deliberate: what is useful is the context beside the row you are looking at, not another list to search. Each group says what it found or, in words, that it found nothing — «no other orders from this customer» and «this row carries no email, visitor or session» are different facts, and an order reported by a Blocks checkout often is the second.
Nothing here claims two rows are the same human being. An email is shared in a household and a visitor id is a browser. It says these rows name the same customer as far as your shop can tell — the same standard the recovery list already works to.
Order states
StorePilot shows your shop's own word for a status. WooCommerce ships seven statuses and your shop may register more — "Pending approval", "Pick up", "Shipped" and anything a payment gateway adds are all real statuses that mean something specific to you. Your site publishes its list and this screen prints from it, so an order reads here exactly as it reads in WooCommerce.
Underneath, StorePilot tracks one thing about an order: whether the money arrived. That is all its revenue and conversion figures need, and it is why a status it has never seen before still counts correctly.
| Underlying state | Meaning |
|---|---|
| Awaiting payment | The order exists; the money has not arrived. Not a sale, and cart recovery still counts this shopper. |
| Paid | The money arrived. |
| Payment failed | The gateway declined. |
| Cancelled | The order was cancelled. |
| Refunded / Partly refunded | Paid, then some or all of it given back. |
:::note Orders from before the update Orders placed before you installed StorePilot are not imported. Reading a shop's back catalogue costs the shop, not us — on a real store it measured thousands of database queries a minute — so StorePilot does not do it. Every order from the update onwards is recorded as it happens, through WooCommerce's own hooks, and the numbers here grow from that day. :::
A refund does not reduce your order count. It moves the amount, not the conversion — the checkout did convert, and the shop later gave money back. Both numbers are shown, so neither hides the other: Total is what was charged, Refunded is what went back, and the money view shows what was kept.
Line items
Products, quantities and prices are visible to admins and owners only. A list of what somebody bought says more about them than a form submission does, and form submissions are already restricted the same way.
They are kept on the visit that produced the order rather than on the order itself, which has two consequences worth knowing. An order that could not be matched to a visit has no line items — nothing was lost, there was simply nowhere to keep them. And when somebody asks you to erase their data, what they bought goes with them while the order's money stays, anonymous: your revenue history is a fact about your business, not their personal data.
Orders that predate the plugin version which began collecting line items say so explicitly — that is not the same thing as an order with nothing in it.
Products
For each product: how many people viewed its page, how many orders contained it, and the conversion between the two. Search by name or SKU; twenty per page.
The finding worth opening this tab for is the one with no numbers. A product nobody viewed and nobody bought appears in no other report by design. Press No attention to see only those.
Your product list is not imported either — a product joins it the first time somebody opens its page, buys it, or you save it in WordPress. So the list of dead products fills in as traffic arrives, while the share of your catalogue that saw nothing works immediately: your shop reports how many products it publishes, and that costs it nothing to answer.
Two things this screen says out loud rather than leaving you to assume:
- Views are counted from the day your plugin learned to report them. Before that no page view recorded which product it was, so history begins at that date and the screen states it.
- Conversion is a floor, and the screen says by how much. A purchase is only counted per product when its order could be matched to a visit; views are counted for everybody. The share of paid orders that were matched is printed under the table, so you can see how much of the picture these rates cover.
- Conversion can exceed 100%. Somebody who buys from a category page never opens the product page, so their purchase is counted with no view behind it. That figure is not clamped, because hiding it would be worse than explaining it.
A product with views and no purchases shows a conversion of 0%. A product with no views at all shows a dash — nobody looked is a different fact from nobody bought.
Adding to the cart is deliberately not counted: it is a third number between the two that matter, and it would need a collection decision nobody has asked for.
Leads and Ecommerce
They used to be one list. They answer different questions now:
- Leads — people who told your shop something through a form.
- Ecommerce — money: orders, what was in them, checkouts, and products.
StorePilot decides which screen a capture belongs to once, when it arrives, and both screens read that one answer. Anything that touched a cart or carries an order number is a checkout, whatever the form it came through was called — so the two lists cannot show the same row and cannot both miss one.
An abandoned cart is a checkout with no paid order behind it. That is the same definition everywhere in StorePilot — the analytics screen, the funnel and the morning digest all read it from one place, so they cannot disagree about it.