NetNet vs ShopifyQL

ShopifyQL is not an app and does not compete with one. It is a query language, and comparing it to a profit tool is really a question about where your data lives.

What it is

A commerce analytics query language with SQL-like syntax, covering schemas for sales, orders, customers, marketing, inventory and payments. It runs in an editor inside the Shopify admin, through the GraphQL Admin API, and via a Python SDK and CLI.

For anyone comfortable writing queries it is genuinely useful, and free. Questions no packaged report anticipated — how did this collection perform in one region across two seasons, which customers bought product A then product B — are a query away rather than a feature request.

The boundary

ShopifyQL can return anything Shopify knows. The limitation is not the language; it is the data available to it.

Shopify does not know what your carrier invoiced. It records the shipping you charged the customer, which is a different number, and it never sees the surcharges and weight adjustments that arrive weeks later.

Shopify does not know your gateway’s fee structure — the percentage, the fixed component, the tax charged on the fee in some markets. Payment data exists; the fee model does not.

Shopify does not know what you spent on advertising. That is in Meta and Google.

Shopify does not know your landed costs — the freight and duty on imported goods that make cost per item an understatement.

No query reaches data the platform never received. This is a boundary of the system, not a shortcoming of the language.

What you can build with it

More than people assume, and less than enough.

Gross profit is reachable: net sales minus cost per item, cut by product, variant, region or period, with far more flexibility than the packaged profit reports offer. If gross margin analysis is your requirement, ShopifyQL does it well and costs nothing.

Below that line you would need to import carrier invoices, model gateway fee structures, pull ad spend from external APIs, attribute refunds back to originating orders, and maintain effective dates on supplier costs — then join all of it back to orders and keep it running.

That is not writing a query. That is building the application, and then maintaining it.

When the query language is the right answer

Three cases, and they are common enough to be worth naming.

One-off analysis. A specific question, asked once, that no report covers. Faster in a query than in any app.

You have a technical person and unusual questions. A team comfortable with the Admin API can go further than packaged reporting allows, and the flexibility is real.

Your margin is simple. Little advertising, predictable domestic shipping, one payment method. The gap between gross profit and net profit is close to constant, so gross margin queries tell you most of what you need.

The maintenance question

Anything built on queries has to be maintained by whoever wrote them, and that is the cost most often underestimated.

A query is written once and then depended on. Schemas change, definitions drift, the person who wrote it moves on, and a reporting layer made of saved queries quietly becomes something nobody wants to touch. That is a manageable cost for one-off analysis and a real one for a standing weekly number.

When it stops being enough

When the costs that move your margin are invoiced by somebody other than Shopify — and for most stores buying traffic and shipping parcels, that is the majority of them.

The tell is a query you cannot finish: any attempt to compute profit after advertising, or margin after real delivery costs, stops at a join to data that does not exist in the schema. At that point the choice is to build the pipeline yourself or use something that has already built it.

Either is defensible. What does not work is treating gross profit from a query as though it were profit, which is the failure this whole comparison exists to prevent.