Best Practices

Recommended setup

Choose the right entity for your goal

Use Orders for order-level summaries (revenue, AOV). Use Orders with line items for product-level analysis (which SKUs sell most). Use Orders refunds transactions for financial reconciliation. Use Products with variants for catalog and pricing data. Start with one entity and add more data flows as your reporting needs grow.

Use column selection for order entities

The GraphQL source lets you choose exactly which columns to include for order-related entities. Select only the fields you actually need — this speeds up data flow execution significantly and keeps your destination clean. You can always add more columns later.

Use date filters from day one

Even for initial setup, set Created after to a reasonable start date rather than pulling your entire order history. Stores with years of data can have hundreds of thousands of orders. Start with the last 90 days, verify the data, then expand the range if needed.

Use status filters to exclude noise

Set Financial status to Paid if you only care about completed sales. Set Status to Closed for finalized orders only. This reduces data volume and avoids confusion from draft, cancelled, or pending orders appearing in your reports.

Data refresh and scheduling

Daily refresh for most stores

Orders typically come in throughout the day, so a morning refresh captures the previous day's sales. Daily is the right frequency for most e-commerce reporting — it balances data freshness with API usage.

Hourly refresh during peak periods

During sales events (Black Friday, product launches), switch to hourly refresh for near-real-time dashboards. Switch back to daily after the event to conserve API quota.

Use date filters to scope your exports

Set Created after to the start of your desired window (e.g., 30 or 90 days ago) to pull only the records you need. For monthly reports, set Created after to the first of the month and Created before to the last day. Update the dates periodically or use auto-refresh to keep data flowing.

Use Changed after for incremental updates

Instead of re-pulling all orders every time, set Changed after to a date 7 days ago to pull only recently modified records. This is especially useful for large stores — it reduces processing time and API load while still catching order status changes and refunds.

Performance optimization

Select fewer columns

Column selection is the single biggest performance lever. If you only need order totals and dates, don't include customer journey, billing address, and shipping line columns. Each additional column group adds processing time.

Split large exports by date range

For stores with 50,000+ orders, create separate data flows for different time periods (e.g., 2024, 2025, 2026). Use Coupler.io's Append transformation to combine them in the destination. This avoids timeout errors entirely.

Use Products instead of Products with variants

If you don't need variant-level detail, use the Products entity instead of Products with variants. A store with 1,000 products and 10 variants each produces 10,000 rows with the variants entity vs. 1,000 rows without.

Stagger multiple data flows

If you have several Shopify data flows against the same store, stagger their refresh schedules by at least 15 minutes. Running them simultaneously increases the chance of hitting Shopify's API rate limits.

Dashboard accuracy

Understand Shopify's sales metrics

Coupler.io exports raw order data, not Shopify's calculated report metrics. Current order total is the latest total after adjustments. Net payment is total minus refunds. For "Gross sales" as Shopify defines it, you'll need to sum line item original totals before discounts and returns.

Account for timezone differences

Coupler.io date filters use your browser's timezone, while Shopify reports use your store's timezone. If your browser and store are in different timezones, order counts for a specific day may differ. For precise daily reports, always compare using the same timezone reference.

Exclude test orders

Shopify's Bogus Gateway test orders are included by default. Filter them out in your destination or transformation step using the "Is Test Order?" field, or by excluding orders with the test tag. Failing to do this inflates revenue and order count metrics.

Use the right entity for refund analysis

Don't try to calculate refunds from the Orders entity — use Orders refunds transactions instead. This entity gives you per-refund detail with transaction amounts, gateway info, and dates. The Orders entity only shows the current net total.

Common pitfalls to avoid

Do

• Use date filters to limit export scope, especially for large stores

• Use column selection to speed up order-related exports

• Use date filters to scope exports to the period you need

• Use Orders refunds transactions for refund analysis

• Check for test orders in your data and exclude them

Don't

• Don't expect Shopify reports, analytics, or session data — only raw entity data is available

• Don't pull entire order history without date filters — this causes timeouts for large stores

• Don't assume Coupler.io totals match Shopify report totals — they use different calculations

• Don't ignore timezone differences between your browser and Shopify store

• Don't use legacy (REST-based) Shopify sources for new data flows — use the current GraphQL source

Shopify reports and analytics are not supported. Coupler.io pulls raw entity data (orders, products, customers, inventory) via the Shopify API. Built-in Shopify reports (Sales reports, Finance reports), analytics dashboards, conversion rates, and session data are not accessible via the API. To build equivalent reports, export raw order and product data and calculate metrics in your destination.