One Dashboard for True Profit: Unifying Shopify, Ads, Fees, and COGS

Shopify shows you revenue the instant an order lands and true profit almost never, because the figures that add up to profit are scattered across systems that were never built to agree with each other. To know what a single order actually earned, you subtract ad spend that lives in your ad platforms, processing fees that live with your payment provider, shipping that lives with your carrier or 3PL, refunds and returns, discounts, and the landed cost of the goods themselves. Every one of those sits somewhere other than your storefront analytics. A true profit dashboard closes that gap: it pulls the pieces into one place, applies your own definition of margin instead of a vendor's, and answers the question revenue can never answer, which is whether a given product, channel, or campaign made money after everything came out.

The short version

• Revenue is a headline; profit is the story. Shopify reports what came in, not what stayed after fees, ads, shipping, returns, and cost of goods. The two numbers can point in opposite directions.
• The inputs live in five or six systems. Ad spend, processor fees, fulfillment cost, returns, discounts, and COGS each sit in a different tool, and none of those tools is responsible for combining them.
• A profit app gives you its formula, not yours. Margin, contribution, and lifetime value mean something specific in your business; a generic dashboard bakes in generic definitions that never quite match.
• The spreadsheet reconciliation is the tell. If someone exports and stitches the numbers every month, the answer is already stale and fragile by the time it is finished.
• Build the pipeline, own the record. A small pipeline into one clean store of record, using your definitions, turns a monthly guess into a view that updates itself and keeps a history you can trust.
• Start with one number that has to be right. Prove true profit by product or by channel end to end before widening, so trust is earned by reconciliation rather than assumed.

Why does Shopify show revenue but not real profit?

Shopify is excellent at the thing it owns, which is the sale. It records the order, the discount, the tax, and, when you use Shopify Payments, the processing fee. That last point is worth being precise about, because it is where most owners assume the platform knows more than it does. Shopify's Admin API exposes a fees field on each order transaction, but as the OrderTransaction documentation notes, those fees are only present for Shopify Payments transactions. If any of your money moves through PayPal, Amazon Pay, or another gateway, the fee on that sale is simply not in Shopify at all. So even the one cost you would most expect the platform to track is partial.

Everything else that eats a margin is somewhere else by design. Your acquisition cost sits inside Meta, Google, or TikTok, reported as spend against impressions rather than against the specific orders it produced. Your true fulfillment cost, the pick, pack, and postage that actually shipped, sits with your carrier or your 3PL. Returns and refunds land back in Shopify as negative events but rarely carry the restocking and re-shipping cost they really incurred. And the cost of goods, the single largest subtraction for most stores, usually lives in a supplier spreadsheet or an accounting system, often without the freight and duty that make it a landed cost rather than a unit price.

None of these systems is wrong. Each is authoritative for its own slice and indifferent to the rest. The gap is that profit is the one figure that requires all of them at once, and no single tool has both the data and the mandate to produce it. That is why the honest answer to "what did I make last month" is so often a shrug followed by a spreadsheet, and why the moment a store starts guessing at profit is usually the same moment it has quietly outgrown spreadsheets as a system of record.

Why does a fuzzy profit picture cost real money?

When profit is approximate, every decision that depends on it inherits the fog. You scale the campaign with the strongest revenue and the weakest margin, pouring budget into orders that lose a few dollars each after fees and returns. You keep featuring the product that sells briskly and clears almost nothing once its landed cost and its return rate are counted. You cannot see which channel is subsidizing which, so a healthy line and a bleeding line average into a number that looks acceptable and hides both.

The waste is not theoretical, and it compounds in a particular direction: the better a bad campaign performs on revenue, the harder you push it, so the losing decisions are exactly the ones you make with the most conviction. A clear profit view inverts that. It points spend, attention, and inventory at what genuinely pays, and it lets you move quickly because you are acting on a settled number rather than a hunch. This is the difference between steering with a clean windshield and steering by feel, and it is why the payback on getting the number right tends to arrive fast, a pattern we trace in the custom software ROI timeline.

What goes into a true profit number?

The reason profit is hard is not arithmetic; it is completeness. A number that omits one real cost is not conservative, it is wrong, and usually wrong in the flattering direction. Before you trust any profit figure, confirm it has every one of these subtracted from revenue, each traced to the system that actually holds it:

• Advertising and acquisition spend, attributed to the channel and ideally the campaign, pulled from each ad platform rather than estimated.
• Payment processing fees, from every gateway you use, not just the Shopify Payments share the storefront can see.
• Actual fulfillment cost, the real pick, pack, and shipping charged by your carrier or 3PL, not a flat average.
• Returns and refunds, including the cost to receive, restock, or write off the goods, not only the refunded revenue.
• Discounts and promotions, counted against the orders they applied to so a margin is not credited with money that was given away.
• Landed cost of goods, the unit cost plus freight and duty, so COGS reflects what the product truly cost to have in hand.
• Your own definitions, written down: what you mean by margin, by contribution, and by lifetime value, so the dashboard computes your business rather than a template.

That last item is the one people skip and the one that decides whether anyone believes the result. Contribution margin at a store that treats fulfillment as a variable cost is a different figure from one that treats it as overhead, and neither is wrong, but only one is yours. Pinning these definitions down first is what separates a dashboard people act on from a dashboard people argue with.

How do you build one profit dashboard, step by step?

You do not build the whole thing at once, and you do not start with the interface. You start with a single trustworthy number and grow outward from it. This is the order that works:

1. Write the profit formula in plain language. Before any code, agree on exactly what gets subtracted from what, and what each term means. This document is the specification, and disagreements surfaced here cost nothing, while the same disagreements surfaced after launch cost the dashboard its credibility.
2. Pick the one question worth answering first. Usually it is true profit by product or true profit by channel, whichever is currently costing you the most in blind decisions. Building one question end to end beats building ten questions half way, a prioritization habit we argue for in what to automate first.
3. Identify the source of record for each input. Orders and Shopify Payments fees from the Admin API, ad spend from each platform's reporting API, other processor fees from their exports, fulfillment cost from the 3PL, COGS from wherever the landed cost truly lives. Name the owner of every number.
4. Wire the sources into one clean store of record. A small pipeline reads each system through its real interface and writes normalized records into a single database designed for the question, which is the durable alternative to the copy-and-paste stitching described in why connecting your stack beats copy and paste and rests on the modeling ideas in database design for non-DBAs.
5. Reconcile against a number you already trust. Run the new figure beside a month you have painstakingly worked out by hand, and chase every discrepancy until they agree. This step is the whole point; a profit dashboard that has not been reconciled is just a prettier guess.
6. Automate the refresh and freeze the history. Once the number is proven, schedule the pipeline so the view stays current on its own, and keep every period on a consistent basis so trends are real signals rather than artifacts of how last month happened to be assembled.

Isn't a profit app from the App Store good enough?

Sometimes, and it is a fair first move. If your model is simple, one gateway, one warehouse, a handful of SKUs with stable costs, an off-the-shelf profit app can get you a defensible number for a monthly fee, and you should use it rather than build. The strain shows up along the same edges every time: the app pulls fees only from the sources it integrates, applies its own margin definition, and gives you a fixed set of breakdowns. The moment your real question is "profit by cohort for customers acquired on this channel who bought this bundle," you are back to exporting the app's data into a spreadsheet to answer it, which means you have added a subscription without removing the reconciliation.

The deeper issue is ownership of the logic and the history. When the definitions and the accumulated record live inside a vendor's product, you rent your own numbers, and you cannot take three years of consistent profit history with you if the app changes its calculation or its price. A custom pipeline keeps the store of record, the definitions, and the history as yours, which is what lets the dashboard become a durable internal tool rather than another monthly bill, in the same spirit as building an internal dashboard your team actually uses. The trade is real effort up front for a number you control forever, and the right answer depends entirely on how distinctive your economics are.

Common pitfalls

The failures here are almost never technical. They are decisions to trust an incomplete number, and they cost the same way each time: confident action in the wrong direction.

Blended metrics that hide a loser. The most common trap is reporting one store-wide margin or one blended return on ad spend. A blended figure is an average, and an average of a strong product and a bleeding one looks merely fine, so the bleeding one keeps its budget. Profit has to be sliced by product, channel, and campaign or it conceals exactly what you most need to see.

Counting revenue as recovery on a return. A refund reverses the sale, but the goods came back needing inspection, restocking, or disposal, and the return shipping was real money. Treating a return as a clean reversal overstates margin on every product with a meaningful return rate, which tends to be the higher-consideration items where the error matters most.

Unit cost masquerading as landed cost. Pulling COGS from a supplier price list without freight and duty quietly understates the largest cost line in the business, so everything looks a little more profitable than it is, uniformly, which is the most dangerous kind of wrong because nothing looks off.

A concrete case. A home-goods store came to us convinced its flagship product was its engine, because it topped the revenue chart and its ad account showed a healthy return on spend. When we built the first phase, true profit by product, and subtracted the real inputs, that flagship dropped near the bottom. It carried a high return rate, and each return cost inbound shipping plus a restock the team had never counted; its landed cost included ocean freight the supplier price list omitted; and a standing promotion was shaving margin on most of its orders. The product was moving volume and losing a little on nearly every unit, subsidized by two quiet, unglamorous SKUs that were actually paying the bills. Nothing about the situation was visible in revenue or in blended ROAS. Reallocating spend toward the two real earners changed the store's monthly profit within a quarter, and none of it required selling more, only seeing clearly. The lesson is the one that runs through this whole piece: an incomplete profit number does not just mislead, it misleads you most about the things you are proudest of.

How we build it so you can trust the numbers

A dashboard you do not believe is worse than none, because a number people half-trust still gets argued over and quietly overridden. So the build is arranged to earn belief before it asks for reliance. We start with discovery, learning how you define profit and where each input truly lives, and you get a plan and a fixed price for a first phase that is deliberately narrow: one high-value question, built end to end, reconciled against your existing figures until they match. You own the pipeline, the definitions, and the historical record outright, with no lock-in, and when you want a new metric or a new breakdown it is a direct request to the person who wrote the logic. The order is the point. We prove one number is exactly right before adding a second, so the dashboard becomes something you trust through experience rather than on faith.

If you can recite your revenue but only estimate your real profit, that gap is closable, and closing it tends to pay for itself in better decisions quickly. Tell me which number you most wish you could trust and I will sketch a first phase that gives you a single, reconciled source of truth for it.

FAQ

Why doesn't Shopify tell me my real profit?

Because Shopify only owns the sale, not the costs around it. It records orders, discounts, taxes, and, for Shopify Payments transactions, the processing fee. It does not hold your ad spend, your other gateways' fees, your actual fulfillment cost, or the landed cost of your goods, because those live in the ad platforms, the processors, the carrier or 3PL, and your accounting system respectively. Assembling all of those inputs into one bottom-line figure is a job no individual system is built to do, which is precisely why a real profit number has to be constructed deliberately rather than read off a screen.

What data do I need to calculate true profit per order?

Start from revenue and subtract, from their real sources, every cost the order caused: advertising attributed to its channel, processing fees from whichever gateway handled it, the actual shipping and handling charged to fulfill it, any discount applied, a share of returns for products that come back, and the landed cost of the goods including freight and duty. The rule is completeness: leaving out one genuine cost does not make the number cautious, it makes it wrong in the direction that flatters you.

What is the difference between gross profit and contribution margin?

Gross profit subtracts only the cost of goods from revenue, so it tells you the raw spread on the product. Contribution margin goes further and subtracts the variable costs of actually selling and delivering that unit, the ad spend, the processing fee, the fulfillment, so it tells you what the order contributes toward covering your fixed overhead and, beyond that, toward real profit. For deciding where to spend and what to promote, contribution margin is usually the honest number, because a product with a fat gross margin can still lose money once acquisition and shipping are counted.

Can a Shopify profit app do this for me?

For a simple store it often can, and if it gives you a number you trust for a monthly fee, use it. The limits appear when your economics are distinctive: the app pulls costs only from the sources it integrates, applies its own definitions of margin, and offers a fixed menu of breakdowns, so any question it did not anticipate sends you back to exporting its data. It also keeps your definitions and history inside its product, which is fine until the price or the calculation changes and you find your numbers were never really yours.

How long does a profit dashboard take to build?

Less than owners expect, because the right first phase is narrow on purpose. A single high-value question, true profit by product or by channel, wired to its real sources and reconciled against a month you already trust, is a small, well-scoped build rather than a sprawling analytics platform. You get a trustworthy answer to one important question first, then widen from there as each addition proves itself, which keeps both the cost and the risk of any single step small.

Do I own the dashboard and the underlying data?

Yes, and that is the point of building rather than renting. The pipeline, the profit definitions, and the accumulated historical record are yours, held in your own store of record with no lock-in, so a consistent multi-year profit history stays with your business regardless of any vendor's roadmap. When you need a new breakdown or a changed definition, it is a quick change requested from the developer who built it, not a feature request filed with a company that may or may not agree it matters.