How to set up ecommerce analytics that show real profit, not just revenue

Most ecommerce analytics tell you how much you sold but not how much you kept. Shopify shows gross sales, the ad platforms each claim their own revenue, and the profit on an order, after discounts, returns, payment fees, shipping, cost of goods, and acquisition spend, lives in no single tool. Useful ecommerce analytics means pulling those sources into one place and computing the numbers your platforms don’t: contribution margin, profit after ad spend, and new versus returning revenue.

If your DTC or online retail brand has outgrown Shopify’s built-in reports, this guide covers why platform-native reporting falls short, the data sources to connect, a profit framework many dashboards skip, where the data should live, and the metrics to define.

Why platform-native ecommerce reports fall short

Shopify Analytics, Meta Ads Manager, and Google Ads each report a partial, self-interested view. They are fine for a quick read on traffic and sales, but they cannot tell you whether a brand is making money.

• Revenue is not profit. Shopify reports gross and net sales. It does not subtract your cost of goods, payment processing fees, pick-and-pack, shipping subsidies, or ad spend. A product line can be a top seller and still lose money on every order.
• Every ad platform over-claims. Meta and Google each count conversions they influenced using their own attribution windows. Add up what each platform reports and the total exceeds the number of orders you received. This is the same double-counting problem covered in how to build a marketing dashboard, and it is worse in ecommerce because the cart is the conversion.
• No platform sees the full order lifecycle. A sale today can become a partial refund in three weeks. Platform-native ROAS is calculated on the order, not on what the customer ultimately kept. Returns then erode the numbers you already reported.
• Returning customers are invisible to ad platforms. Meta does not know that a “conversion” was a loyal customer who would have bought anyway. Blending new and returning revenue hides whether acquisition is working.

No single dashboard can tell you whether you are profitable. Spend, revenue, costs, and refunds have to come together in one model, with metrics you define yourself.

The data sources behind ecommerce analytics

Before connecting anything, map each source to the data it is the authority for, so you never pull the same metric from two systems and get two answers.

The commerce platform owns the order and the customer, ad platforms own spend, your COGS source owns unit costs, and the processor owns fees. Any profit metric needs at least three of these joined together, which is why no native dashboard can produce it.

The profit layers most dashboards skip

The most useful thing ecommerce analytics can do is walk an order from gross revenue down to the profit you keep. Many brands stop at revenue or blended ROAS, but the number that should drive spend decisions sits further down in the five layers below.

Each layer changes the decision. Gross revenue tells you nothing about health. Net revenue exposes a discounting or returns problem. Contribution margin tells you whether a product or order is structurally profitable before you spend a cent acquiring the customer. Profit after ad spend, sometimes computed at the blended level as net revenue minus total marketing cost, tells you whether the business as a whole makes money.

A brand can grow gross revenue 40 percent and shrink profit after ad spend at the same time. That only shows up if your analytics carry every order through all five layers instead of stopping at the top.

Where ecommerce data should live: Shopify, a warehouse, or both

The right architecture depends on how many sources you have and how much history you need.

Stay platform-native if you sell on one channel, run light paid spend, and mostly need revenue and traffic. Shopify’s reports plus an app or two are enough. Adding a warehouse here is overhead you will not use.

Move to a warehouse once profitability requires joining three or more sources, you want order history that outlives a tool’s retention window, or different teams keep arguing about whose number is right. A central store in BigQuery, Snowflake, Redshift, or Postgres becomes the single source of truth, with ELT connectors (Fivetran, Airbyte) syncing Shopify, ad platforms, and processors into it. This is the same threshold described in when to add a data warehouse.

Run a hybrid in the common middle ground: live-query Shopify for operational, near-real-time order monitoring, and use the warehouse for blended profitability and historical analysis. The tradeoffs between live queries, blending, and a warehouse are covered in how BI tools combine data from multiple sources.

The Shopify Admin API is rate-limited using a leaky-bucket model, so pulling large order histories means paginating and respecting throttles rather than one big extract (see the Shopify API rate limits docs). Managed connectors handle this for you, which is the main reason to use one instead of writing your own sync.

The metrics worth defining

Define these once, in one place, so every report agrees. Vague labels like “revenue” are where dashboards diverge.

Two of these deserve emphasis. MER (marketing efficiency ratio) sidesteps attribution disputes by ignoring which platform claimed which sale and asking only whether total revenue justifies total spend. Splitting new versus returning revenue keeps a brand from celebrating “great ROAS” that comes from loyal customers buying again.

The ecommerce-specific data problems

Ecommerce data has quirks that generic analytics advice misses.

• Guest checkout breaks customer identity. The same person can order under multiple emails or as a guest each time, inflating “new customer” counts. Stitch identity on email plus address or phone before computing repeat rate or CAC.
• Refunds arrive late. An order recorded as revenue this week may be partly refunded next month. Model refunds against the original order date, not the refund date, or your historical net revenue will keep changing after the fact.
• Discounts are not one thing. Automatic discounts, codes, and price drops hit margin differently. Keep them as separate fields so you can see which promotions erode contribution margin.
• COGS changes over time. Landed cost shifts with supplier pricing and freight. Store COGS with an effective date so old orders keep their real cost instead of today’s.
• Subscriptions and one-time orders mix. If you sell both, separate them. Subscription churn and one-time AOV behave nothing alike and should not be averaged together.

Common mistakes

• Reporting blended ROAS as if it were profit. ROAS ignores COGS, fees, and returns. A 3x ROAS on a low-margin product can still lose money.
• Trusting each platform’s reported conversions. Summing Meta and Google conversions double-counts. Reconcile against actual orders in Shopify.
• Ignoring returns until quarter-end. Returns belong in the daily model, attributed back to the original order, not bolted on later.
• Averaging new and returning customers together. It hides whether acquisition works and flatters CAC.
• Defining metrics inside each chart. When AOV is calculated three different ways across three dashboards, people stop trusting all of them. Define metrics once, upstream.

When platform-native analytics is enough

You do not need a warehouse or a BI tool for every store. Stay with Shopify Analytics and a focused app when you sell on a single channel, run little or no paid acquisition, carry simple and stable margins, and need mostly revenue and traffic visibility. Once you start spending meaningfully on ads, selling across channels, or arguing about profitability, the gap between native reports and reality justifies building proper analytics.

Tools for ecommerce analytics

A few categories fit different stages, and a fuller breakdown lives in the best ecommerce analytics tools compared.

• Platform-native dashboards (Shopify Analytics) are free and instant but cannot join ad spend, COGS, or returns.
• Purpose-built ecommerce analytics (Triple Whale, Glew.io) connect Shopify and ad platforms directly and ship pre-built profit and attribution views, best for Shopify-centric brands without a warehouse.
• Warehouse-native BI (Looker, Sigma, Metabase, Basedash) connects to the warehouse where Shopify, ad, and cost data have been unified. Once your data is centralized, contribution margin and profit-after-ad-spend models live here. Basedash adds plain-English querying on top, so an operator can ask “contribution margin by product over the last 90 days” without writing SQL.

The right choice follows the architecture decision above: platform-native for single-channel simplicity, purpose-built for Shopify-first brands, and warehouse-native once profitability spans many sources.

FAQ

What is the difference between ROAS and MER?

ROAS (return on ad spend) is reported per platform and counts only the revenue that platform claims, so the numbers double-count across Meta and Google. MER (marketing efficiency ratio) is blended: total net revenue divided by total marketing spend across all channels. MER avoids the attribution arguments and is harder to game, which is why many DTC teams treat it as the headline efficiency metric.

How do I calculate true profit per order in ecommerce?

Start from the order’s net revenue (after discounts and refunds), subtract cost of goods sold, then subtract variable costs such as payment processing fees, shipping, and pick-and-pack. That gives contribution margin. Subtracting attributed or blended acquisition cost gives profit after ad spend. You need data from the commerce platform, your COGS source, the processor, and the ad platforms to compute it, which is why it cannot come from one dashboard.

Do I need a data warehouse for ecommerce analytics?

Not always. A single-channel store with light ad spend can run on Shopify’s reports. You need a warehouse once profitability requires joining three or more sources, you want order history beyond a tool’s retention window, or teams disagree about whose numbers are right.

Why don’t my ad platform numbers match Shopify?

Each ad platform attributes conversions using its own window and view-through rules, and they all claim overlapping orders. Shopify records the actual order. Reconcile against Shopify as the source of truth for orders and revenue, and use blended metrics like MER instead of summing platform-reported conversions.

How should I handle returns in ecommerce reporting?

Attribute refunds back to the original order date, not the date the refund is processed. This keeps historical net revenue and contribution margin stable instead of shifting every time a late refund lands. Track return rate as its own metric, since it is a common and easily hidden drag on margin.