TENANT ANALYTICS · ATTRIBUTION AND DAYS
Tenant usage analysis: compare isolated meter totals
Attribute nine usage events to two tenants for one billing day and see how API keys, missing claims and time zones move usage between tenants.
Your experiment
acme bills in UTC and globex in UTC-8. A partner app calls for both tenants, a batch job for acme sends no user token, and two globex calls sit near midnight UTC. The correct totals are acme 1,400 and globex 1,350 tokens. Start with API-key attribution and UTC days.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional tenants, keys and events. The correct totals are defined by the fixture: each event belongs to the tenant that made it, on that tenant’s billing day. The partner key is registered to acme when it is shared. No analytics warehouse or billing system is queried.
Two tenants, one billing day
The report covers 14 October. acme bills in UTC and globex in UTC-8, and the correct totals are acme 1,400 tokens and globex 1,350. With the opening settings usage is attributed by API key, and the partner app uses one key for both tenants, registered to acme. The two globex calls through the partner app, G2 and G4, land in acme’s total, so acme shows 1,900 and globex only 350: CROSS-TENANT LEAK. One tenant can now see another tenant’s activity in its usage report.
Separate keys or the token claim
Clear Partner app uses one API key for both tenants: each tenant’s partner traffic has its own key and acme is exactly 1,400. Set Attribute usage by to Tenant claim in the user token instead: G2 and G4 go to globex, but the acme batch job A3 sends no user token and becomes unattributed, so acme shows 1,200. Tenant claim, else a single-tenant API key uses the claim when there is one and falls back to a key that belongs to exactly one tenant, so A3 is counted for acme and nothing leaks. A shared key is never a valid fallback.
Whose midnight?
Even with correct attribution, globex shows 850 with UTC days. G3 at 02:00 UTC on 15 October is 18:00 on 14 October in globex’s zone, and G5 at 06:00 UTC on the 14th is 22:00 on the 13th. Set Day boundary for the 14 October report to Each tenant’s billing time zone: G3 moves in, G5 moves out, and globex is exactly 1,350. With the fallback attribution and local days the report is ISOLATED AND EXACT for both tenants.
Leaks and errors are different failures
With local days but API-key attribution on the shared key, globex is still 850 and acme still 1,900: the day boundary cannot repair attribution. An unattributed bucket is safer than a wrong tenant, because it is visible and leaks nothing, but it still leaves both totals wrong until the batch job carries a tenant identifier.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through each event and the report across sixty seconds; the table lists each event’s true tenant, claim, key, time and where it was counted. The fixture is fictional and small; real tenant analytics also handle late events, deleted tenants, reseller hierarchies and daylight-saving changes, which shift the local-day boundary twice a year.