A store owner checks last month’s revenue in three places and gets three answers. WooCommerce > Analytics > Revenue says one, the payment processor dashboard says another, and the new chat-with-your-store plugin quotes a third without blinking. Nobody lied. They’re each measuring something slightly different.
That gap is the first thing WooCommerce AI analytics runs into, and closing it is most of the work. What got me thinking about it is Hugo Lu’s argument on Towards Data Science that agentic BI is collapsing the effort a question deserves. His frame is what he calls the Valley of Choice, and it maps onto a store better than most BI theory does.
What the valley of choice looks like on a store
The idea is a tradeoff between how hard a question is and how much effort you’ll spend on it. “How many orders did we get yesterday” is the easy end, and the Analytics Overview screen already answers it instantly. The hard end is “why did revenue drop in the second week of last month”, which today means a person opening orders, checking refunds, working out whether a coupon misfired, and looking at traffic. Dashboards live in the middle: they answer questions repeated often enough to be worth building once.
They do not help discover insights, but help you deliver insights you have already found.
That’s Lu on dashboards, and I’ve not seen the job described better. His bet is that agents with memory take over the middle, so manual digging stays justified only for questions that genuinely need a human. I buy the direction. What I’d push back on is the assumption underneath it: that the agent arrives somewhere that already knows its own numbers. BI platforms have semantic layers and people whose job was deciding what revenue means. A typical store has none of that. The definitions live in one person’s head, and when that person is busy the numbers are up for grabs.
Where WooCommerce AI analytics gets its numbers
Order data on a store lives in one of a few places depending on age and settings. Legacy stores keep orders in wp_posts and wp_postmeta, one meta row per field. Stores on High-Performance Order Storage, the default for new installs since WooCommerce 8.2, keep them in dedicated tables: _wc_orders, _wc_order_addresses, _wc_order_operational_data and _wc_orders_meta, per the developer docs. During a migration both sets can be populated at once through compatibility mode.
The Analytics screens don’t query any of that directly. They read lookup tables, wc_order_stats and wc_customer_lookup, that background jobs keep filled. That’s why the revenue chart can drift from what you’d compute by walking the orders yourself, until you reimport from Analytics > Settings. So there are at least three honest answers to “what was last month’s revenue”, and nothing in the schema tells you which one the person asking means. I’m not sure any of this reasoning holds for a store sitting mid-migration with compatibility mode still on, where both copies of the data exist and can disagree.
An agent writing raw SQL inherits that ambiguity and then hides it. A confident number calculated from wp_postmeta on an HPOS store looks like an answer, and nothing in the stack flags it as wrong.
So the move I’d make before connecting any agent is to expose functions rather than tables. wc_get_orders() is the one query API that behaves the same across post storage and HPOS, so it’s the right thing to put in front of a model. Define each metric once, in code, and let dashboards and agents call the same definition:
<?php
function bbioon_net_revenue( DateTimeImmutable $from, DateTimeImmutable $to ): float {
$orders = wc_get_orders( array(
'status' => array( 'wc-processing', 'wc-completed' ),
'date_created' => $from->getTimestamp() . '...' . $to->getTimestamp(),
'limit' => -1,
) );
$total = 0.0;
foreach ( $orders as $order ) {
$total += $order->get_total() - $order->get_total_refunded();
}
return round( $total, wc_get_price_decimals() );
}The status list is doing real work there. Pending, failed, cancelled and refunded orders are excluded, and partial refunds are subtracted by hand because a partially refunded order keeps its processing or completed status. Whether revenue should include tax and shipping isn’t a technical question, and no tool decides it for you. That decision, written down in code, is the store’s semantic layer, and it’s the part that survives every tool swap. One more thing: whatever you connect to the database, connect it with a read-only user.
Do the dashboards you build for clients survive?
The source’s headline says agentic BI will kill data analysts, but its quieter point is the one I’d bet on. A dashboard people already trust stays, because clicking through to a known screen is still less effort than typing a question, waiting, and asking again for a graph. The Overview screen is exactly that for a store owner, and it has years left.
What disappears is the layer in the middle, and it’s work I’ve done plenty of: the one-off custom sales report plugin, the monthly CSV export, the “can you just pull this” request that quietly becomes a recurring favor. Those jobs exist because asking a question used to require a developer. Once the definitions are callable, an agent takes them, and I won’t miss them. What replaces them pays better anyway. Someone has to own the definitions, keep them current as the store adds refund policies or sales channels, and audit the agent’s answers against them. Lu calls that role semantic architect. On a store it’s whoever decides what revenue means, and that deserves its own line item in the budget. Two threads worth reading next: what a data agent means for WooCommerce reporting, and why WooCommerce AI analytics should ask rather than count.
If you’re weighing this for a store you run or maintain, it’s the kind of work I do: working out where the numbers come from, pinning the definitions down in code, and putting a safe read path in front of an agent.
Before any of that, test the gap. Pick one settled month, ask the agent or the plugin you’re evaluating for net revenue, then check it against Analytics > Revenue and against the processor’s payout report. If three numbers come back, stop shopping for agents and fix the definitions first. And if a store’s real questions all fit on the Overview screen, there’s no valley to escape and skipping the project is the correct answer.
