Shopify Reporting Apps: Setup and Where Native Breaks

Most searches for “Shopify reporting apps” are really asking one question: which app, installed how, actually closes the gap Shopify’s own Analytics section leaves open. A general roundup answers the first half — a list of names — and skips the second half, the part that decides whether the app tells you anything true once it is live. This is a setup guide, not a roundup: the permissions to grant, the cost fields Shopify never fills in for you, the attribution setting almost every install leaves on its default, and the arithmetic that says exactly when Shopify’s own report screens start hiding rows from you. It closes with what a broken reporting setup actually costs a $3M–$30M merchant in a normal month, worked from real inputs rather than asserted as a round number.

What do you need before installing Shopify reporting apps?

Three things need to exist before any Shopify reporting app is worth installing, and skipping them is why a freshly connected app often looks wrong on day one. A Shopify admin login with owner or full-app-management permission is the first, since installing an app from the Shopify App Store requires approving a scope list that a restricted staff account cannot grant. Read access to whichever ad platforms you actually spend on is the second — a Meta Business Manager login with the ad account attached, and a Google Ads account with API access enabled, not just a personal login to the dashboard. Your own landed cost per SKU is the third, gathered from wherever it currently lives — a spreadsheet, a 3PL invoice, a supplier quote — because no reporting app manufactures that number; it only has a field waiting for you to type it in.

Step 1: Grant the app read-only access to your Shopify admin

Installing a Shopify reporting app starts with Shopify’s own app-approval screen, which lists every scope the app is asking to read or write before you confirm the install. A reporting app has no legitimate reason to request write_orders, write_products or write_customers — it reads your order and product data and writes nothing back to the store — so check the requested scopes for read_orders, read_products, read_customers and read_analytics, and treat any write scope on that list as a reason to stop and ask the vendor why. Shopify shows this exact scope list on every public-app install, not a summary of it, so the check costs nothing beyond actually reading the screen instead of clicking past it.

Step 2: Connect Meta and Google Ads as spend sources

Shopify’s own checkout has no record of what you paid Meta or Google for a click, so a reporting app has to pull ad spend directly from each platform rather than through Shopify at all. Open the app’s own integrations panel and connect Meta Ads Manager and Google Ads individually, each through its own login or API token, granting read-only access to campaign, ad set and spend data. Skipping either one does not break the install; it just leaves that channel permanently blank in every blended report the app produces afterward, a quieter failure than an error message and easier to miss until someone asks why a channel’s numbers look empty.

Step 3: Enter landed cost per SKU, not Shopify’s blank default

A reporting app’s margin and profit numbers are only as accurate as the cost figure behind them, and Shopify does not supply one by default. Shopify’s own Cost per item field, found on each product’s Pricing section in the admin, holds a single number per variant, and it ships blank on every product until someone fills it in. Enter the fully landed cost, not the wholesale price alone: unit cost, inbound freight and packaging, for every SKU the app is meant to report on, either inside Shopify’s own field or the app’s separate cost-import screen if it keeps its own copy. A catalogue of a few dozen SKUs takes an afternoon to do properly; a catalogue in the low thousands is worth exporting to a spreadsheet, filling in bulk and re-importing rather than typing one product at a time.

Step 4: Set the attribution window to your own purchase cycle

Every reporting app ships with a default attribution window, and that default is built to be generally reasonable, not built for your store’s specific customers. Open the app’s attribution settings and look for a lookback window, usually expressed as a number of days of click or view credit before a sale is attributed to a channel; the default is commonly borrowed from the ad platforms’ own reporting conventions rather than derived from your own repeat-purchase behaviour. Pull your own average days between a customer’s first visit and their first purchase from Shopify’s customer order history, and set the window to match it — a supplements brand with a short consideration cycle and a furniture brand with a six-week one should not be running the same attribution window, and most installs never touch this setting after the first login.

Step 5: Add your payment-processing and 3PL fee schedule

Payment processing and 3PL fulfilment fees are two recurring costs that sit outside anything Shopify or an ad platform reports, and both need to be entered as their own line items for a margin number to mean anything. Your payment processor’s exact published rate goes in as a percentage-plus-fixed-fee line the same shape it is billed in — Shopify Payments’ own online rate depends on your specific Shopify plan, so pull the current figure from Settings > Payments in your own admin rather than assuming a number. Your 3PL’s per-order pick-and-pack rate, taken from its own current rate card rather than the number in a contract signed two years ago, goes in the same way. Both change more often than most teams update them; a 3PL renegotiation or a Shopify plan change that quietly moves the payment rate is the most common reason a previously accurate app starts drifting.

Step 6: Build and save the blended profit report

With Shopify, ad spend and cost data all connected, the last step is building the report itself rather than leaving the raw data sitting unassembled. Most reporting apps let you construct a channel-by-day and a SKU-by-day view, combining attributed revenue, ad spend, landed cost, payment fees and fulfilment cost into one contribution-margin figure per row, and save that combination as the account’s default so it is the first thing anyone sees on login rather than a blank dashboard someone has to rebuild from memory each time. A saved default view also turns a reporting app from something one person checks occasionally into something the whole team actually uses, since nobody has to remember which filters to reapply.

Which step do most Shopify teams get wrong?

Step 3, the landed cost, is the one most installs get wrong, and it is wrong in a quiet way rather than an obvious one. A reporting app with no cost entered does not show a blank margin column — it shows a number, usually treating cost as zero or inheriting whatever sits in Shopify’s own Cost per item field, still blank, which means every order looks like it converted at 100% margin. That number is confident-looking and completely wrong, and because a dashboard with a wrong number looks exactly like a dashboard with a right one, the mistake survives for months until someone cross-checks it against an actual bank statement or a supplier invoice. The fix is not a setting inside the app; it is the discipline of updating landed cost on the same schedule a 3PL contract or a supplier price actually changes, which for most catalogues means quarterly at minimum and immediately after any known cost change.

How do you verify a Shopify reporting app is reporting correctly?

Verification starts with one comparison: pick a specific week, open the reporting app’s total revenue for that week, and open Shopify’s own Analytics Sales report for the identical date range and time zone, then check whether the two numbers actually agree. A small, consistent gap usually traces to one of three causes — the app’s time zone is set differently from the store’s own admin time zone, so a day boundary falls in a different place; a batch of refunds posted inside the window and Shopify’s Net sales figure moved retroactively while the app’s cached total did not; or the app is reporting gross revenue where Shopify’s own report is reporting net, or the reverse. A gap that keeps growing rather than staying flat points somewhere else entirely, usually a subscription order or a draft order whose properties the app’s default filters were never built to recognise — the same failure mode covered in why Klaviyo sometimes shows the wrong order count.

At what point does Shopify’s native reporting break down?

Shopify’s native reports break down once an order-level report needs more than 1,000 rows, and Shopify says so itself: its own Reports documentation states that reports display a maximum of 1,000 rows, a limit chosen so the report loads quickly, with totals calculated across every row even though only the first 1,000 display in the table. The totals stay correct past that point, but any report where the individual rows matter, not just the total, stops showing the full picture right where row 1,000 and row 1,001 happen. An export gets around the display cap for most report types. Whether a few report types — the finance sales tax reports among them — additionally cap the underlying ShopifyQL query itself, requiring the query to be edited by hand to remove the limit, is — metric to confirm — since the cited documentation covers the general 1,000-row display cap only, not which specific reports also cap the query beneath it.

Work out your own break-even point rather than trusting a general one, because it depends on average order value, not on revenue alone. Divide monthly revenue by average order value; once the result passes 1,000, an order-level report — one row per order, not one row per month or per product — is already losing rows in a normal month, not only during a peak. At the $3M annual floor this site writes for, monthly revenue works out to $250,000, so the break-even average order value is $250 — $250,000 divided by 1,000 orders. Below a $250 average order value, which covers most Shopify DTC brands, an order-level report clears the cap before the month is even finished, and every $3M–$30M merchant reading this should re-run that division with their own numbers rather than this one.

What does bad reporting actually cost a $3M–$30M merchant every month?

No vendor publishes a per-order or per-SKU cost of bad Shopify reporting, because the honest number depends on your own catalogue, team and ad mix, not a rate card anyone sells — metric to confirm — so what follows is a worked calculation with invented inputs, built to show the method rather than a number to copy. Three costs actually recur every month a reporting setup stays broken, and all three are invented for this example; swap in your own hours, spend and units before trusting the total. Manual reconciliation time: an ops person spending six hours a week stitching Shopify exports, ad-platform CSVs and a 3PL invoice together by hand, at a $50 loaded hourly rate, across four weeks, comes to $1,200 a month (6 × 4 × $50). Continued spend on a channel a blended view makes look healthy: an $8,000-a-month channel running one extra month at a true, post-landed-cost contribution of −$1,500, before anyone with a real per-channel margin number catches it. A missed reorder trigger on a top SKU: no join between sales velocity and 3PL receiving lead time means a five-day stockout on a SKU selling 40 units a day at $28 of contribution margin each, for $5,600 in lost margin (5 × 40 × $28).

A Shopify reporting app is a piece of software; the setup behind it — the scopes it can access, the cost data it never invents on its own, the attribution window nobody resets, and the row cap that quietly limits what you can see without an export — is a reporting and analytics problem, not an app-choice problem. Getting all four right the first time is most of what a reporting and analytics build actually does: not picking Triple Whale over Northbeam — Northbeam’s own published Starter tier is $1,500 a month (vendor-reported); Triple Whale’s current tier pricing is — metric to confirm, since its pricing page could not be retrieved directly and third-party summaries of its tiers disagreed with each other — but making sure whichever one gets picked is fed correct inputs from day one instead of confidently wrong ones for the first two quarters. For the boundary between what Shopify’s own admin already reports and what any app is closing, see what Shopify Analytics actually covers and what a Shopify dashboard is versus a profit dashboard; for checking the margin math that feeds a reporting app’s cost fields, the margin calculator works the same contribution-margin arithmetic used in this guide’s stockout example.