ORDERS / DATED COUNTS
What the counts mean.
Buyer orders, anonymous unpaid orders and our own tests appear separately. Known operator addresses and test references are excluded from the real-buyer count.
Orders and refunds
| Figure | Real buyers | Anonymous, unpaid | Our own tests |
|---|---|---|---|
| Orders placed | 0 | 0 | 13 |
| Orders paid | 0 | — | — |
| Refunds issued | 0 | ||
“Orders placed” includes unpaid and abandoned orders. It is not a sales count. You can try the free paste screen without ordering a report.
Response time
No measured response-time figure is published here yet. Do not infer a reply-time target from the order counts.
How this log is produced, and what it cannot show
The page tries to fetch aggregate counts from the order store. If that fails, or returns no monthly rows, the dated saved table stays visible. Read its caption to distinguish a fresh read from the saved snapshot.
Order counts do not show whether buyers were satisfied or reports were accurate. Review the refund terms and the dated self-check example separately. Dated product changes are in the changelog.
How an order lands in each column
Two rules decide the column and both run on every row. The first is a machine flag written when an order is created, which marks anything we generate ourselves. The second is a naming rule for rows predating the flag or entered by hand. It matches the operator’s own address, an example.com address, our reserved supplier prefix, and internal payment references.
A row counts as a real buyer only when neither rule matches and it is not an anonymous unpaid order. A missing test flag puts a row in the test bucket. These rules reduce known misclassification; they cannot prove that every unflagged row came from a buyer.
Correction, 4 September 2026. Until that date only the naming rule was applied to the order table. Eighteen rows carrying the machine flag were being counted as real buyers, and the live endpoint reported six real orders for August. Under the corrected rule, August has no real orders and one anonymous order that was never paid. The live endpoint and the snapshot builder now use the same counting rule, so their figures differ only when they were read on different dates.
What this log does not contain
- No response time. We have not measured one in a form we would publish. The order counts imply nothing about how fast email is answered.
- No satisfaction measure. A count of orders says nothing about whether a report was accurate or useful to the buyer.
- No revenue. The table counts orders. An order placed is not an order paid, and neither figure is an amount of money.
- No buyer detail. Nothing here identifies a buyer, and nothing here ever will.
- No blank when the live read fails. The saved snapshot stays visible with its own date. An empty table would read as zero activity, which is a different claim from an unavailable read.
How we checked
The table is read from the production order store on the date given in its caption. Real buyers, anonymous unpaid orders and our own tests are counted separately and never merged.