Skip to main content

Hello Supermetrics Support,

We’re using the Shopify → BigQuery connector. Our current exports include Returns at the order/line level but do not include refund timestamps. As a result, we can only attribute refunds to the order date, which does not match Shopify’s Analytics (which attributes refunds on the refund date). This causes material discrepancies in daily Net Sales and share metrics.

We’d like to request a new Transactions / Refunds dataset (or an extension to the existing Shopify schema) with event-level refund rows and the following minimum fields:

Required fields

  • order_id (Shopify order ID)

  • transaction_id (if available)

  • transaction_kind (e.g., refund, refund_sale, etc.)

  • processed_at (refund timestamp; created_at also acceptable)

  • amount (refund amount; positive number preferred or documented sign convention)

  • currency (shop currency of the transaction)

  • (optional but helpful) reason, payment_gateway, user_id (who processed it)

 

If there’s an existing way to get this via your connector (e.g., a hidden “Transactions” report type or different field set), please point us to it. Otherwise, we’d appreciate this enhancement or guidance on the best available alternative.

Thank you!

Thank you for the request!

For the transaction object-specific fields (transaction_id, transaction_kind, payment_gateway etc) - we don’t support that endpoint right now. Fields related to this (especially payment ones) have been a very popular request, so I will link it to the backlog item we already have about investigating support. This is something we’d like add next year.

For the other part about refunds - the way the data source works might already get you close what you want? We also show the refunds on the dates they happened, not attached to the original order date. They are tracked as their own line item. Our dates are all using processed_at as the base.

Though it appears as the same order ID as the original purchase, its going to appear as its own row in the data as an “anti-order” with an order count of “0”, line item type “Refund” and a positive Returns amount.

In this example from our test store, the May 21st order had logged adjustments on May 22nd which was the date they happened.

The only thing missing is the actual timestamp (we have the date and the hour, but there’s no timestamp for when the refund occurred). That’s something I can also put into the product backlog if required/desired.

I hope this somewhat helps.

Jessica

Terms & ConditionsCookie settingsAccessibility statement