This article outlines recommendations and notes certain limitations imposed by the data source API, which you may need to consider when building your queries.
If you’re connecting to this data source, please follow the instructions in our connection guide, and the available fields for this connector are listed in the metrics and dimensions documentation.
Request limits and recommended refresh rate
Request limit: See Shopify’s rate limit documentation.
Recommended refresh window: Refresh window logic does not apply to the Shopify data source because data is continuously synced, not pulled from the API on every request.
Historical range
With the Shopify data source connector, the data is available for the last 5 years for destinations other than data warehouses. For data warehouse destinations, we provide the store’s lifetime.
Accounts in Shopify
In the Shopify connector, each Store is considered a separate account within the connection.
Your Supermetrics subscription determines how many data source accounts you can use simultaneously.
Things to consider
Session and conversion metrics not supported
Shopify doesn't currently support session and conversion metrics in its data. If this changes, we'll let you know in our documentation updates.
However, Google Analytics 4 can fetch these metrics — we recommend using it instead.
Time zone differences
Shopify reports use the time zone set in your store's settings, while Supermetrics may use a different default depending on your destination. This can cause order dates to differ between Shopify's own reports and your Supermetrics report. See About time zone setting discrepancies in Shopify data for a detailed example and how to fix it.
Date range basis
The date fields are all based on the processed_at field from the API, which is defined as:
The date and time (ISO 8601 format) when an order was processed. This value is the date that appears on your orders and that's used in the analytic reports. If you're importing orders from an app or another platform, then you can set processed_at to a date and time in the past to match when the original order was created.
Currency differences
Supermetrics doesn't round order amounts until the final calculation, so your totals may differ from Shopify's by a cent here and there.
If an order is placed in a currency other than your store's default, Shopify converts it in its own reports and exports, but Supermetrics uses the original order currency. This can cause bigger discrepancies. To find these orders, split your data by order currency code and order ID.
Marketing attribution differences
Shopify and Supermetrics use different models to attribute orders to UTM parameters, such as UTM campaign name and UTM source. This is why you may see different results when you split orders by these fields.
Shopify's marketing reports use a last-touch model: they show UTM data from the customer's most recent visit before the order.
Supermetrics checks the most recent visit first, too. However, if the order came from the customer's first-ever visit, we fall back to that visit's UTM data instead, so the order can still be attributed to a source. This fallback is why Supermetrics sometimes shows UTM data that Shopify's own reports don't.
Incorrect sales numbers and orders
Sometimes, the Shopify Graph API gives completely incorrect sales and order data for certain stores. When this problem happens, you’re not getting all of the orders for the Shopify store for certain time ranges, and the orders and sales are missing.
Supermetrics has made some changes to the way we use Shopify’s Graph API, which, according to Shopify, should reduce the likelihood of this happening again. It’s, however, still possible that the same problem will affect some Shopify stores in the future. If this happens to you, contact Shopify’s support, share the Shopify store domain, and ask to have the search documents for that store re-indexed.
Refunds
Supermetrics records each refund as its own line item, with a date corresponding to when the refund was processed. If your date range only covers the original order date, a later refund won't show up until you widen the range to include it.
If a refund is triggered on one day and completed on another, we report it on the completion date. Shopify's own export may show it on the trigger date, or leave it blank.
If a refund is canceled, Shopify's export shows it as a positive value, but we don't report canceled refunds at all, since no order ID exists for that transaction.
Gross profit
Gross profit calculations use the Cost per item value from Shopify. If a product's Cost per item is empty, we treat it as a 100% profit margin, which can inflate your gross profit. To fix this, add a Cost per item value to the product in Shopify.
Cost of goods sold
For the cost of goods sold, Shopify's reporting uses the cost per unit at the time of the sale, but Supermetrics uses the current cost per unit. Since Shopify doesn't provide historical cost data through the API, we can't exactly match its profit reports.
Discrepancies caused by editing orders
Shopify generally recognizes that certain kinds of edits after the order has been placed can cause some analytics reporting issues. The various considerations are listed in Shopify's documentation. The main ones that concern Supermetrics users are:
Some discounts may not be recalculated correctly after editing an order
Shipping rates may not be recalculated after an order is edited
Orders edited the day after the order was placed cause a new copy of the order to appear in the analytics with the edit. This isn’t actually a new order, but it can be confusing, as it shows in the UI and is exported as an order. You’ll need to check the Supermetrics data for the original order placement date.
Filtering your data
If you filter a query on a field that isn't included in your selected fields, some counts, such as order count, may come out wrong. Add the filtered field to your field selection to fix this.
Stale data
As the Shopify API is tight on the rate-limiting, Supermetrics has implemented some aggressive caching to make sure data is available without excessive requests. This does mean, though, that data older than today/yesterday may get stale. To work around this, add yesterday's or today's date to the date range and refresh the query. This should cause the cache to update to the current state.
Also, be aware that Supermetrics imports a store’s data about twice a day, so there may be delays in to data.