How do you analyze shipping and delivery data in Metabase?
Shipping is usually the largest line in e-commerce COGS that nobody examines. The reason is structural: your store platform knows what an order was worth, your shipping platform knows what the label cost, and neither can show you one next to the other because each holds only half of the join. Land labels and orders in the same SQL database, join them on your own order ID, and cost per order, lane economics, and margin after fulfillment stop being guesses.
shipping_labels (one row per purchased label, with the billed cost), shipment_tracking (one row per shipment, latest outcome), and orders from your store platform. Join on your own order ID, roll multi-package orders up to order grain before averaging, and exclude voided labels from spend.Which tools does this cover?
- Shippo — shipping transactions (labels), rates and carrier accounts, parcels and dimensions, tracking status updates
- ShipStation — shipments, orders from connected sales channels, carriers and service levels, warehouses and stores
Both sit downstream of a store platform, which supplies the order side of every join: Shopify, WooCommerce, and Amazon Seller are the common sources. The e-commerce category covers how those get into a database in the first place.
The split between the two is mostly about where the data starts. Shippo is API-first multi-carrier shipping — rate shopping, labels, and tracking — so its record is the label. ShipStation is order-fulfillment software that pulls orders from every channel you sell on, so its record carries a store and a warehouse alongside the shipment, which makes fulfillment cost per channel unusually easy to answer.
What is the shared shipping data model?
Three tables carry almost every shipping question. Model them as clean tables, not raw API JSON:
| Table | Grain | Key columns | Used for |
|---|---|---|---|
shipping_labels | One row per purchased label | order_id, carrier, service_level, amount, status, tracking_number, parcel_weight, zone | Spend, cost per order, lane analysis |
shipment_tracking | One row per shipment, latest outcome | tracking_number, shipped_at, eta_at_purchase, delivered_at, tracking_status, days_in_transit | On-time rate, transit percentiles |
orders | One row per order from your store | order_id, ordered_at, paid_at, order_total, shipping_charged, destination_country | The denominator for everything above |
Three modeling decisions do most of the work. Put your own order ID on the label at purchase time — in Shippo's metadata field, or from the channel order in ShipStation — because matching on tracking number or address breaks the moment an order ships in two boxes. Snapshot the carrier's promised delivery date into eta_at_purchase at label purchase, since carriers revise ETAs afterwards and an on-time rate measured against a moving promise flatters itself. And aggregate multi-package orders to order grain before averaging, or cost per order quietly becomes cost per package.
How do you connect shipping tools to Metabase?
- Managed connector — Fivetran's ShipStation connector is official and generally available, which makes it the lowest-effort durable path for that side. There is no equivalent for Shippo's cost data.
- Scheduled API pull — the route Shippo cost reporting requires, because the Airbyte source has no transactions stream. Page the Transactions API into a warehouse table on a schedule, within 50 requests per minute on live keys, and backfill early: records older than 390 days are dropped. ShipStation's V2 API is the equivalent, at 200 requests per minute by default.
- MCP + CLI route — pull a scoped slice through a vendor MCP server, save CSV, and load it with
mb upload csvfor fast exploration. Shippo's hosted server is the polished one here; treat ShipStation's MVP server as exploratory.
Whichever route you take, Metabase reads the resulting SQL database — see the per-tool setup on the Shippo and ShipStation pages, or the e-commerce analytics overview for how shipping fits the wider store model.
What can you analyze across these tools?
- Shipping cost per order — billed label cost at order grain, and as a share of order value
- On-time delivery rate — deliveries on or before the promised date, over shipments with a known outcome
- Lane economics — cost by carrier, service level, zone, and weight band: the table that tells you which contracts to renegotiate first
- Shipping recovery — what customers were charged for shipping against what shipping actually cost, by channel
- Order-to-ship time — hours from payment to label creation, which isolates warehouse lag from carrier transit
- Average order value — the denominator that turns shipping spend into a ratio worth reading
- Gross margin — margin after COGS and fulfillment; shipping is the cost most often left out
Which dashboards should you build?
- Shipping cost — cost per order, spend by carrier and service level, recovery against shipping charged
- Store overview — net revenue, orders, and AOV, the numbers shipping cost has to be read against
- Product performance — heavy and bulky SKUs are where shipping quietly eats the margin
- Repeat purchase — late deliveries show up here before they show up in support tickets
Common mistakes
Related
Analytics
Integrations
Dashboards
Metrics
FAQ
Why analyze shipping data outside the shipping tool?
Can I get Shippo label costs through a managed connector?
What do I need to know before standardizing on ShipStation?
Is there an MCP server for these tools?
mcp.shippo.com with OAuth, plus the @shippo/shippo-mcp npm package for stdio-only clients and headless automation. ShipStation's official server lives in the vendor's GitHub org and targets V2, but it self-describes as an MVP, is distributed as source rather than a published package, and has not seen a commit since August 2025. Both are good for exploratory questions; put durable reporting on a synced database.