| 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. |
| 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. |
| 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. |
| 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. |