Why analytics MAU and billable MAU diverge
Product analytics answers "roughly how many people used this?" and is allowed to be approximate. Billing answers "exactly what does this invoice charge for?" and is not. The two diverge for structural reasons:
- Identity. Analytics dedupes by device, cookie, or session. The same human on a laptop and a phone is two analytics users but one billable user.
- Blockers. Client-side analytics is invisible to a growing share of users. Your server saw them; your tracker did not. Billing from the tracker undercharges and, worse, makes the number unreproducible.
- Timezones and windows. A rolling 30-day window and a calendar month disagree at every boundary. Invoices are monthly; the meter must be too.
- Mutability. Analytics numbers move as late data arrives and models change. An invoiced number must be explainable months later, from raw events.
If a customer disputes a seat-based or MAU-based invoice, "our analytics said so" is not an answer. "Here are the distinct user ids we recorded for August" is.
The unique_count pattern
In UsageBox you create a string meter with agg_type: unique_count and a unit like "users". Then every billable user action sends one usage event whose value is the user id:
POST /api/v1/usage
[
{ "meter": "meter_active-users-xxxxxxxx", "value": "user_8412" },
{ "meter": "meter_active-users-xxxxxxxx", "value": "user_1077" },
{ "meter": "meter_active-users-xxxxxxxx", "value": "user_8412" }
]The rollup for the month counts 2, not 3. Repeats within the month are free by definition: the distinct set already contains the id. You do not need to remember client-side whether a user was already counted this month, and you should not try - that cache is exactly the kind of state that drifts. Send on every qualifying action and let the meter dedupe.
Uniqueness is kept per UTC calendar month, which matches how the rollups are keyed and how invoices read. On September 1 the set is empty again and the first action of the month re-counts the user.
The three decisions that make or break MAU billing
1. Which id is the user?
Pick the most stable identifier you own, almost always your internal user id. Emails get changed, sessions rotate, anonymous ids reset with cookies. Every unstable identifier inflates the count, and inflated counts are the disputes customers actually win. If you must count pre-signup visitors, meter them separately as "anonymous sessions" and do not bill them as users.
2. What counts as "active"?
Write the sentence down: "a user is active when they do X". Login alone is generous, a billable action (ran a job, sent a message, opened a project) is defensible. Whatever you choose, instrument exactly that server-side, at the point where the action is authoritatively known. Do not meter page views for billing.
3. Where do the events come from?
The server, not the client. The event fires in the same code path that performs the action, so blockers, offline clients, and bots do not distort it. Related: if some of your traffic is automation you never intended to bill, decide the policy explicitly - see should you bill bot and crawler traffic.
Seats, MAU, and the agentic wrinkle
Seats bill for potential use, MAU bills for actual use. MAU pricing feels fairer and sells better to buyers burned by shelfware, but it needs exactly this metering discipline to be creditable. There is also a 2026-specific wrinkle: AI agents acting for one human can look like heavy "activity" while being one user, which is one reason per-seat pricing struggles with agentic users. A unique_count meter on the human owner's id, paired with a volume meter for the agent's consumption, prices both dimensions honestly.
Verifying the number before anyone is charged
Because the meter is queryable, verification is a curl, not a data pull: read the month's rollup and compare it against a distinct-count over your own application database for the same UTC month. Do this once when you wire it up and again at your first month close. The two sources should agree exactly; if they do not, the gap is your definition of "active" leaking, and it is much cheaper to find in week one than in a customer's audit. Duplicate deliveries are the other classic inflator, which is why ingestion should be idempotent - though for unique_count specifically, a redelivered event is naturally harmless: the id is already in the set.
The honest take
MAU billing has a reputation for arguments because most implementations cannot answer "which users, exactly?". A unique_count meter makes that question boring: the invoice is a distinct set you can enumerate. Design the meter deliberately (see designing billing meters), send events from the server with your internal user id, and MAU becomes the easiest line on the invoice to defend. UsageBox gives you the meter, the monthly distinct set, and the queryable rollup out of the box.