Analytics hosting where the reports match the orders.
WooCommerce Analytics does not read your orders directly. It reads its own lookup tables, and when those fall behind the reports are confidently wrong.
A second copy of your sales.
Analytics maintains derived tables so reports do not query orders directly. Everything that goes wrong is those tables disagreeing with the source.
Historical imports that reach the first order
Enabling analytics on an existing store means importing years of orders into the lookup tables. That runs as a resumable batch, or the reports start mid-history and look like a collapse in sales.
Figures reconciled against the order list
A report total that does not match the orders screen is the symptom of a stalled import. Those are compared so the gap is found rather than presented in a board meeting.
New orders recorded as they arrive
Lookup rows are written alongside each order. When that write fails the order exists and the report does not count it, which is invisible from either screen.
Report queries that are indexed
A date-range report over years of orders is a large aggregate. Those queries are indexed rather than left to scan the lookup tables.
Rebuild without touching orders
Lookup tables can be regenerated from the orders at any time, so a corrupted report is recoverable without restoring anything.
Reports that quietly disagree.
Nobody notices a slow report. They notice a report saying revenue halved in March, which is usually the month an import stopped rather than the month sales did.
- Historical import run as a resumable batch
- Report totals reconciled against orders
- Lookup writes verified for new orders
- Date-range aggregates indexed
A year of orders, aggregated.
The measurement is a twelve-month revenue report on a store with real history, because that is the query staff run and then wait for.
What we change for WooCommerce Analytics
The reports read derived tables, so every row here is about keeping those in step with the orders they came from.
| Setting | What we do | Why |
|---|---|---|
| Historical import | Resumable batches covering the full order history | Enabling analytics on an established store imports years of orders, and a run that stops leaves reports beginning mid-history and reading as a sales collapse. |
| Reconciliation | Report totals compared against the order list | A stalled import produces figures that are internally consistent and wrong, which is worse than an obvious error because nobody questions them. |
| Lookup writes | Verified for newly placed orders | A failed lookup write leaves the order present and uncounted, which is invisible from both the order screen and the report. |
| Aggregate indexing | Date-range report queries indexed | A twelve-month revenue report is a large aggregate over the lookup tables, and unindexed it becomes the slowest screen staff use daily. |
| Rebuild path | Lookup tables regenerable from orders on demand | Because they are derived, a corrupted report can be fixed by rebuilding rather than by restoring a backup over live orders. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why do my analytics figures not match my order list?
I enabled analytics and older sales are missing. Why?
Can I rebuild the reports without restoring a backup?
Why is my revenue report slow?
Report the numbers you actually took.
Move the store across. Migration is free, lookup tables rebuilt.