Shopify Analytics discrepancies: Reports vs data warehouse

If you’ve ever compared Shopify’s built-in analytics with the data from your data warehouse, you’ve probably noticed the numbers don’t always match.

This doesn’t mean your data is wrong. Instead, it reflects how Shopify’s Analytics UI and the Shopify API process, aggregate, and present data differently. When you use Weld (or any ETL tool) to sync Shopify into your data warehouse, you’re pulling what the API exposes, and that doesn’t always follow the same logic as Shopify’s reports.

In this post, we’ll take a deeper look at the three most common reasons Shopify data doesn’t align with your warehouse, with examples of how these differences show up in practice.

1. Attribution and conversion differences

Attribution is one of the biggest sources of mismatched numbers.

By default, Shopify Analytics uses last-click attribution: the final marketing touchpoint before purchase gets 100% of the credit. But Shopify also allows toggling to:

• First click attribution → gives credit to the first interaction.
• Last non-direct click attribution → ignores direct visits, crediting the last marketing channel before the order.

These attribution settings directly affect reported conversions.

Another common issue:

• Orders vs conversions → A single session can generate multiple orders, but Shopify only counts one conversion.
• Sessions vs customers → Shopify deduplicates visitors differently depending on the report.

Takeaway: Always confirm which attribution model and entity (sessions, orders, conversions) you’re comparing. If your warehouse query is order-based, but Shopify Analytics is showing conversions, the numbers will diverge.

2. Aggregation of events

Shopify’s reports aggregate events differently than its APIs.

• Shopify Analytics (UI) → Includes multiple order statuses: pending, paid, fulfilled, refunded, canceled.
• Shopify API → Primarily exposes finalized transactions.

This explains why warehouse exports often look lower than Shopify’s UI.

Takeaway: Always check which order statuses are included in your query. Shopify’s UI counts orders earlier in the lifecycle, while API-based data models often only include completed transactions, leading to lower numbers in the warehouse.

3. Time zones

Time zones are one of the most common, and most confusing, sources of discrepancies.

• Shopify Analytics (UI) → Uses the shop’s configured time zone (set in Settings → Store details). Reports and charts are always displayed in this local zone.
• Shopify API → Returns timestamps in ISO 8601 format. Most are UTC (Z), but some include explicit offsets. The API does not automatically adjust to the shop’s local time zone.

Example:

• Shop time zone = CET (UTC+1 in winter, UTC+2 in summer).
• An order created at 2025-05-01T23:30:00Z (UTC) will:
  • Appear in the API as May 1, 23:30 UTC.
  • Appear in the Shopify UI as May 2, 01:30 local time.
• Result: Warehouse queries grouped by UTC will count this as May 1, while Shopify’s UI shows it on May 2.

API filters and daily boundaries

• Parameters like created_at_min and created_at_max are interpreted in UTC.
• This means that if you’re trying to reproduce “orders for May 2” as seen in the UI, you need to adjust your filters based on the shop’s local offset.

Daylight saving time (DST)

If the shop is in a timezone with DST, the offset between UTC and local time changes during the year. Shopify’s UI applies DST automatically, but API timestamps remain in UTC. Without adjusting for DST, your warehouse daily totals will drift around March/October (EU) or March/November (US).

Best practices for time zones

1. Store both UTC and local timestamps in your warehouse.
2. Convert API timestamps to shop-local time before grouping daily aggregates.
3. Be explicit about which time zone each report uses.
4. Test queries around DST transitions.

4. Refunds and returns

Refunds and returns are another major source of mismatches, especially because Shopify’s Sales, Payments, and Finance reports treat them differently.

Here’s how different scenarios play out:

These differences explain why the same refund can look different in UI vs warehouse queries.

Takeaway: Always clarify whether you’re looking at gross sales (before refunds), net sales (after refunds), or payouts (after payments/refunds processed). Aligning definitions is the only way to reconcile Shopify UI with warehouse data.

5. Metrics and definitions

The third driver of discrepancies is Shopify’s metric definitions.

Here’s where misalignment often happens:

• Gross sales vs net sales
  • Gross sales = item price × quantity sold (includes canceled and unpaid orders).
  • Net sales = gross sales minus discounts and returns.
  • Warehouses often model net sales; Shopify Analytics often shows gross sales.
• Sales including vs excluding taxes and shipping
  • Shopify’s Sales reports often include taxes, shipping, and duties.
  • Warehouse models usually strip these out.
• Orders vs transactions vs checkout completions
  • Order = created when checkout is initiated.
  • Transaction = payment attempt (can be multiple per order).
  • Completed checkout = successful flow completion.
• Restocks and inventory metrics
  • Refund + restock → reduces sales, increases inventory.
  • Refund without restock → reduces sales, no inventory impact.
  • Restock without refund → shows as reverse tax in Sales, absent from Payments.
• Currency
  • Shopify reports in store currency.
  • API/warehouse often recalculates with prior-day FX rates.
• Customers and visitors
  • Customers over time → only those who placed at least one order.
  • Customers list → all customers, including non-purchasers.
  • Unique visitors → deduplicated in UI, but may appear multiple times in API/warehouse data.
• Cookies, ad blockers, and apps
  • Shopify Analytics relies on scripts and cookies. If a visitor blocks scripts or declines consent, Shopify tracks fewer sessions/conversions.
  • Custom checkouts, upsell apps, or third-party scripts can also cause mismatches if events fail to fire.

Takeaway: Define your metrics explicitly across the stack. If your warehouse query is net sales before tax and you’re comparing it to Shopify’s gross sales including tax and shipping, the numbers will never align.

Bringing it together

Discrepancies between Shopify Analytics and your warehouse are not errors, they’re the result of different rules. Attribution, aggregation, refunds, and metric definitions all shape the numbers.

The key is not to eliminate discrepancies, but to decide which definitions your team will rely on. Once aligned, your reporting becomes both consistent and trustworthy.

Checklist when comparing Shopify to warehouse data:

1. Attribution model
2. Aggregation rules
3. Time zone alignment
4. Refund and restock handling
5. Metric definitions
6. Browser/app tracking setup
7. Awareness of Shopify updates (returns, reporting logic, etc.)

Weld’s perspective

At Weld, we see this all the time: teams lose confidence in their reporting because Shopify UI and warehouse numbers don’t align.

Our approach is to make Shopify data clear, consistent, and documented in the warehouse, with SQL-based models that match your business definitions. And with reverse ETL, you can sync those aligned metrics back into the tools your team uses every day.

That way, you’re not debating dashboards, you’re making decisions.

Sources

Google: Currency reference

Data discrepancy with GA4 - Shopify

Analytics discrepancys - Shopify

Data-discrepancies-between-ga4-and-shopify - Analytica Digital

Marketing Attribution - Shopify