How to Track Cloud Cost per Order with Pushed Order Counts

Cost per order divides infrastructure spend by completed orders. The numerator comes from your cloud bills; the denominator lives in your own order database, which no cloud provider can see. ZopNight’s Unit Economics takes the denominator from you and draws cost per order as a second axis on the Cost Reports trend chart. This guide uses the two push-style inputs: a CSV for history and the Push API for each new day. If your system can serve the numbers over HTTPS instead, see the pull-based cost per MAU setup.

1. Decide what an order is

Write the definition down before exporting anything, because it will be argued about later. Typical decisions: completed orders only or all placed orders, whether refunds subtract, whether test and internal orders are excluded, and which time zone draws the day boundary. Keep the same rule for history and for new days, or the trend line will jump at the switchover.

2. Count orders per day

One row per calendar day. For example, in PostgreSQL:

SELECT (completed_at AT TIME ZONE 'UTC')::date AS date,
       COUNT(*)                               AS value
FROM orders
WHERE status = 'completed' AND is_test = false
  AND completed_at >= DATE '2026-01-01'
GROUP BY 1
ORDER BY 1;

3. Create the metric

In ZopNight, add a unit metric from the quick-add catalog (it offers MAU, DAU, requests, transactions and signups) or define your own named “orders”. Set the display scale to 1, 100 or 1,000; cost per 1,000 orders is easier to read when single-order cost is a fraction of a cent. The scale is applied only when values are displayed, so changing it later does not rewrite what you stored.

4. Backfill with a CSV

Export the query result and upload it to the metric. Uploads are capped at 1 MB and 5,000 rows, which is more than 13 years of daily rows, so a single file usually covers the full history. Values are upserted per date, so re-uploading a corrected file replaces those days rather than duplicating them.

5. Push each new day

Schedule a job after your day closes that sends yesterday’s count to the metric’s push endpoint, POST /orgs/ORG_ID/unit-metric-values/METRIC_ID, with a JSON array body of date and value pairs:

[ { "date": "2026-09-23", "value": 18342 } ]

Because writes are upserts keyed on the date, a retry or a late correction is safe to send again.

6. Read and sanity-check it

Open Cost Reports; the trend chart gains a cost-per-order axis. The same series is available from GET /orgs/ORG_ID/reports/unit-economics with metric_id, from, to and a daily, weekly or monthly granularity. Each bucket is total cost divided by total orders, so a weekly point is not an average of daily points, and days with zero orders are skipped rather than drawn as infinity. When enough history exists the response includes a forecast based on the average of recent points.

Check three things in the first week: the most recent day is present, the count matches your order dashboard for one sample day, and weekends look like weekends.

Narrow it to a team or tag

Add team_id, or a tag_key and tag_value, to the report request to divide only that team’s or tag’s cost by orders. If you have not pushed order counts for that team, the org-wide order count is used as the denominator. Unit economics covers choosing a denominator that tracks what actually drives cost.