Commercial analytics & AI
Every system holds a partial truth. We build the one that holds all of them.
One warehouse in BigQuery, inside your own Google Cloud project — marketplace, storefront, media and fulfilment at day and SKU grain, with real fees taken from settlement data rather than anyone's estimate.
Seller Central, Walmart, Shopify, Google Ads, Meta and Google Analytics each answer a different question in a different shape. Reconciling them by hand every month is how brands end up managing a spreadsheet instead of a business.
We connect read-only to the systems where your data already lives, inside your own accounts, and build the model once. Because sessions, conversion, units, spend and margin all key on the same grain, a revenue drop decomposes into a traffic problem, a Buy Box problem, a conversion problem or a price problem without switching tools or arguing about definitions.
Onboarding a second brand is dataset instantiation from a template, not a rebuild — which is why the second account costs a fraction of the first.
one grain
Marketplace, storefront, both ad platforms, web analytics and the 3PL — modelled into a single BigQuery project you own. Read-only, inside your accounts, and yours if we ever part company.
What lands, at what grain
History varies by source because the platforms differ — Amazon advertising is a rolling 95-day API window, finance and inventory go back to 2024. We state that rather than implying a longer series than exists.
Sources vary by engagement — a brand without a 3PL feed or without Meta simply has fewer.
The gap between what Amazon's fee preview said this account would be charged and what the settlement reports show it actually paid. Every model built on the estimate is wrong by that much — and the estimate is what most dashboards use, because it is the number the API hands over first.
Estimated fee against settlement-derived actual
Amazon is the sharpest example because its fee structure is the most elaborate, but the principle holds on every channel: we take the money line from the settlement, the payout or the invoice, never from the platform's forecast of it.
View as table
Illustrative composite account · one calendar month, Amazon US. Hover a row for the figures.
× channel
Not month × account. One row is one product on one day in one channel, carrying every line between what the customer paid and what you kept. Anything coarser averages the problem away — and the problem is almost always one SKU, on some of the days.
One row of your business
This is the shape of the table everything else is built on. Roll it up by month and you get the P&L; filter it to one SKU and you get the argument about that SKU.
The key 2026-08-29 · 23124-A · amazon_us · 412 sessions · 63 units
| Revenue | Referral | FBA | Ads | COGS | Freight | Returns | Kept |
|---|---|---|---|---|---|---|---|
| $1,247.37 | −$187.11 | −$149.68 | −$124.74 | −$561.32 | −$39.91 | −$24.95 | $159.66 |
$159.66 kept on $1,247.37 sold — a 12.8% contribution margin, on one product, on one day, in one channel.
Illustrative composite row. Every fee here is settlement-derived; none of it is an estimate.
Why the grain matters
Each cell is one SKU on one day. Blue is profit, red is loss, pale is near break-even. A profitable month routinely contains loss-making days on individual SKUs — averaged up they are invisible, and at grain they are a decision.
Illustrative composite · 8 SKUs × 21 days. Hover a cell for the value. Four SKUs here ran below zero for a week: a promotion stacked with a fee change nobody connected.
across 6 groups
Detection is deterministic and versioned — the same data and the same thresholds yield identical findings, every run. The language model narrates and correlates; it never decides what fires. If a source is stale, the run records the reason and skips that domain rather than publishing a confident number built on nothing.
See what two of them foundWhere the twenty-eight sit
Ranked by how many detectors cover the group. Bar darkness is rank, not category. The last group are the detectors that watch the detectors — stale ingestion, findings left unresolved, and false positives that keep coming back.
View as table
Detector set as of this quarter. Share of findings from an illustrative composite of live accounts.
Findings we can't explain arrive as questions, not assertions. Your answer is written to an append-only decision log, and the next day that finding is explained rather than re-alerted — so the same false positive never costs you the same morning twice.
and the apps behind them
A warehouse nobody opens is a cost centre. We build the things that use it — the dashboards your team reads, and the small applications that turn a finding into an action without anybody exporting a spreadsheet.
Talk about what you'd buildWhat we have built on it
Each of these runs against the same warehouse, so none of them needs its own copy of the truth.
Channel, margin and inventory views your team opens directly — plus the warehouse itself, which you can query without us.
A shipping plan arrives, gets audited SKU by SKU against velocity and cover, and comes back with a verdict, a suggested quantity and the query behind it.
Eligible products and checkpoints drive a daily cohort, with a send ledger for frequency capping and revenue attributed back per email.
Every change the team makes, recorded against the finding that prompted it — what was changed, from what to what, who authorised it, and what it was expected to do.
Built per engagement on the shared model. Client connections stay read-only unless you decide otherwise.
What you receive
An insights report each morning — typically 14 to 27 findings, triaged by our team before it reaches you.
A check-in deck per account: what moved, why, and what we're doing about it this week.
Dashboards you can open yourself, and a warehouse you can query without us.