# Business Metrics — Cost Per User, Per Order, Per Whatever You Measure

> Define a business denominator and ZopNight computes cost per unit alongside your cloud spend. Push values by API, upload a CSV, or have ZopNight pull them from your endpoint on a schedule.

Source: https://zop.dev/integrations/business-metrics
Updated: 2026-08-20

---

## Common questions

### How often can ZopNight pull my metric endpoint?

Between once an hour and once a week. Cost data lands daily and no faster, so a shorter interval adds load without value; beyond a week the number is too stale for the overlay to mean anything.

### What happens if I send the same day's value twice?

Nothing doubles. Values are keyed by organisation, metric and date, so a retried push, an overlapping CSV upload and a pull that fires twice all resolve to one row per day. Re-uploading a month to correct one day leaves the other twenty-nine as they were.

### Can ZopNight work out my active user count for me?

No. You supply the denominator and ZopNight divides spend by it. If nobody owns the definition of an active user, the resulting chart is exactly as trustworthy as that agreement. Deciding what to count stays a business decision.

A cloud bill that grew twenty percent is only bad news if the business did not grow with it. Business metrics are how you supply the other half of that sentence: a number ZopNight can divide spend by, so the reports overlay speaks in cost per active user or cost per order rather than dollars in isolation.

## Definitions and facts are stored apart

A metric definition (its name, its unit label, how its values arrive) is configuration, and lives with the rest of an organisation's configuration. The daily values themselves are facts, and live in the analytics store beside cost data.

The split matters because the two have completely different lifecycles. A definition is edited a handful of times and read constantly; values arrive every day forever and are queried in ranges. Storing them together would force one access pattern to lose.

## Three ways in, and why the third exists

**Push.** Your systems POST values to the ingest endpoint. Best when you already have a job that closes the books each night.

**CSV upload.** Same ingest path, driven from the interface. This is not a lesser route: for a metric someone maintains in a spreadsheet, uploading it is honest about where the number really comes from, and the source is recorded so you can see which is which later.

**Pull.** ZopNight fetches an HTTPS endpoint you own, on a schedule. The interval floor is one hour and the ceiling is one week. Below an hour adds load without value, since cost data lands daily and no faster; beyond a week the number is too stale for the overlay to mean anything. Endpoints can be open or authenticated with a bearer token, basic credentials, or a custom header, and those credentials are stored encrypted.

## Sending the same day twice is safe

Values are keyed by organisation, metric and date. That key does the idempotency work for all three ingest paths at once: a retried push, a re-uploaded CSV covering an overlapping range, and a pull that fires twice all resolve to one row per day rather than a double count.

This is the property that lets you backfill without fear. Re-uploading a month to correct one day does not inflate the other twenty-nine.

## Reading the number back

The trend endpoint serves daily, weekly or monthly granularity over a window of up to 366 days, so a year-on-year comparison fits in a single request.

Values are stored exactly as you send them and scaled only at read time: per unit, per hundred, or per thousand. Cost per thousand requests is a display choice, not a different number in the database, so changing how you want to read it never rewrites history. Values are held with four decimal places, which is enough for both small integer counts like signups and high-volume rates aggregated into a daily figure.

## What it will not do for you

ZopNight does not invent the denominator. If nobody owns the definition of "active user", this feature will faithfully divide by whatever number is supplied, and the resulting chart will be exactly as trustworthy as that agreement. The engineering here is in getting your number in reliably and dividing correctly. Deciding what to count stays a business decision.