The most common mistake in ecommerce reporting is treating a bad dashboard as the problem. It rarely is. A dashboard just displays whatever numbers feed it, and when reporting feels chaotic, the actual fault almost always sits upstream: in numbers that were never reconciled, sources that were never labeled consistently, or metrics that mean two different things depending on which report you open.
Rebuilding the dashboard without fixing any of that just moves the same errors into a nicer-looking interface. The chart gets better colors and the wrong numbers keep flowing into it.
An ecommerce reporting audit is the step teams skip: checking whether the numbers are even correct before anyone builds something new to display them. Here is what that audit actually looks at, in the order the findings tend to matter.
Layer one: does anything reconcile against the store
Start here, because everything downstream depends on it. Pull total revenue reported by every ad platform for a fixed window, then compare it against what the store's order export actually shows for the same window.
One delivered reporting audit put that comparison side by side for the first time and found a 40% gap: the ad platforms' combined revenue claims added up to 40% more than the store had actually banked in the same window. The cause traced back to duplicate order IDs, the same sale claimed as a full conversion by more than one platform at once, a double count nobody had caught because nobody had ever lined the two exports up next to each other.
This is not necessarily a tracking bug. Google Ads and Meta both run their own attribution models over their own windows, and those windows overlap by design. Google's own documentation on data discrepancies walks through why: click-date attribution, network-level processing differences, and model-specific crediting all mean the "conversions" column in any single platform's dashboard was never meant to be read as your total revenue.
The fix at this layer is not picking a "more accurate" platform. It is adding a blended figure, marketing efficiency ratio (MER): total revenue divided by total ad spend across every platform, which cannot double-count the way platform-reported ROAS can. MER should sit next to platform numbers in every report, not replace them, because platform numbers still matter for optimizing that platform.
Layer two: does traffic source data mean what the report says it means
The second most common finding in a reporting audit is traffic fragmentation. In one delivered audit, roughly 31% of a store's sessions landed as "direct / none" in the analytics tool while ad platforms recorded the matching click volume for those same visits. The cause was mundane: three different UTM spellings for the same channel (fb, facebook, meta-paid) plus a batch of untagged email and influencer links that had no source attached at all.
Every report built on top of that traffic data is quietly wrong in the same direction: paid channels look weaker than they are, and "direct" looks like a channel doing real work when it is actually unlabeled paid and organic traffic hiding in one bucket.
A reporting audit checks:
- Whether UTM naming is standardized across every team member and vendor who builds a campaign link.
- Whether "direct / none" volume is proportionate to what it should be, or ballooning in a way that signals untagged traffic.
- Whether internal links accidentally carry UTM parameters, which overwrites a visitor's true original source on their next session.
None of this requires new tooling. It requires someone to actually look, which is the part a dashboard rebuild skips.
Layer three: do the metrics mean the same thing in every report
A reporting audit also checks metric definitions, because "revenue" and "conversion rate" quietly mean different things depending on which report you are reading. Gross revenue before or after discounts and returns. Conversion rate calculated on sessions or on users. Contribution margin that includes shipping costs in one dashboard and excludes them in another.
Teams that have never audited this usually find at least one metric with two live definitions in circulation, both correct in isolation, both producing different numbers when someone quotes them in the same meeting. Standardizing this is unglamorous work, but it is the reason two people can look at "our numbers" and mean different things without realizing it.
Layer four: who owns each report, and what breaks it
The last layer is an inventory: every report, dashboard, and spreadsheet actually in use, who reads it, what feeds it, and how much manual work keeps it alive. This step routinely surfaces three or four places reporting the same metric differently, plus at least one spreadsheet that only one person understands well enough to fix when it breaks.
That inventory is also where the audit decides what happens next. If most of the reporting stack is spreadsheets fed by manual exports, the roadmap usually points toward a data warehouse, most commonly BigQuery fed directly by GA4 and the store, since GA4's BigQuery Export is available on every property at no extra cost and removes the manual export step entirely.
This four-layer process, reconciliation, source-of-truth mapping, metric definitions, and the report inventory, is exactly the scope of Anlyto's ecommerce reporting audit, delivered as a fixed-scope engagement rather than open-ended consulting hours. Once the audit has identified what is actually broken, our ecommerce reporting service builds the fix: a warehouse, automated pipelines, and a dashboard layer that reads from one reconciled source instead of five disagreeing ones.
A related but separate question worth checking at the same time is whether your Looker Studio setup is hitting connector limits before you scale it further; our GA4 to Looker Studio connector limits guide covers the quotas and sampling behavior that quietly cap a dashboard built directly on the free connector. And if the dashboard itself is the weak link rather than the data underneath it, the ecommerce dashboard views a founder actually opens weekly is a useful reference for what belongs on it once the numbers are trustworthy.
What a reporting audit should hand you
A reporting audit that is worth paying for delivers more than a diagnosis. At minimum, expect:
- A reconciliation of platform-reported revenue against real store revenue for a fixed window, with the gap quantified in dollars and percent.
- A traffic source audit flagging UTM inconsistency and any abnormal direct/none volume.
- A list of metrics with more than one live definition across current reports, with a single recommended definition for each.
- An inventory of every report and spreadsheet in active use, who owns it, and where the manual failure points sit.
- A prioritized roadmap: what to fix immediately, and what points to a bigger rebuild.
If a proposal skips the reconciliation step and jumps straight to "we'll build you a Looker Studio dashboard," it is selling the fix before doing the diagnosis. Anlyto's fixed-price audits run this reporting audit as a standalone engagement, with the fee credited toward the reporting build if a brand moves forward within 60 days, so the audit stays a paid diagnostic rather than a cost stacked on top of the rebuild.
The short version
Before anyone touches Looker Studio, BigQuery, or a new spreadsheet template, run the ecommerce reporting audit checklist above against what already exists:
- Does platform-attributed revenue reconcile with actual store revenue for a fixed window.
- Is traffic source data consistent, or fragmented across UTM variants and untagged links.
- Do shared metrics like revenue and conversion rate carry one definition, not two or three.
- Is there an inventory of every report and spreadsheet, with an owner and a known failure point for each.
Most teams that run through this find their real problem was never a missing dashboard. It was a set of numbers nobody had reconciled, dressed up in whatever chart happened to be open at the time.
