Attribution
How spend is attributed to people, teams, departments, services and seats -- and which of those are records you curate versus values observed in traffic.
Attribution
Attribution answers "whose spend is this". It has five surfaces -- People, Teams, Departments, Services and Seats -- and one structural rule that explains almost everything about how they behave.
Existence comes from identity; activity comes from the window. Every roster is an unwindowed identity dimension joined to a windowed activity aggregate. So a row of zeros is a real answer about a quiet entity, and only an unknown identity is a not-found error.
How a request gets attributed
Three inputs, merged in a fixed order:
| Order | Source | Wins over |
|---|---|---|
| 1 (lowest) | A workload attribution rule you configured | -- |
| 2 | The owner of the issued key the request used | The rule |
| 3 (highest) | The attribution tags the caller sent explicitly | Both |
A vendor-identity fallback fills the user tag alone where nothing else does.
A rule cannot override tags the caller sent. If a service sends
X-Dz-Project, that value wins over anything configured centrally -- which is
the right precedence for a header the calling team controls, and worth knowing
before you try to correct attribution from the dashboard.
Attribution tags are free strings, not references. Nothing validates them
against any registry, so checkout, Checkout and check-out are three
projects. Pick a convention early.
People
A person is one human as your team's telemetry knows them -- which may or may not resolve to a DevZero user. An unlinked vendor account is a first-class row with spend, a score and a team.
A person key takes one of three forms: a DevZero user id once linked, a vendor-qualified form before that, or an unresolved form derived from an attribution tag.
A person's absence from the list does not mean "no activity" -- it means no such identity. And because a person key changes shape when an identity is linked, link identities early: the People screen's linking tab is where that happens.
Teams and departments
Two things wear each name, and the distinction runs through every screen.
| Curated record | Observed value | |
|---|---|---|
| Team | A managed team: a name, an attribution key, members, a colour, a monthly figure, an optional department and a designated lead. | A distinct value of the team tag with no managed team behind it. A full row with members and spend, but no owner, colour or budget -- because there is no record to hold them. |
| Department | A managed department: a curated grouping of managed teams. | A distinct project-tag value with no managed row. |
A managed team's attribution key is what joins it to telemetry, and it is immutable after creation. It defaults to the team's name.
Traffic reaches a department only through the managed team it is filed under.
A managed team's or department's monthly figure enforces nothing. It is intent-only metadata for planning and chargeback. The thing that actually refuses a request is a guardrail budget, which is a different object entirely.
An effective team name resolves in order: the managed team the sender is a defined member of, then the managed team whose attribution key matches the team tag, then the raw team tag, then the unattributed bucket.
Unattributed
Two things again, and both are real rows rather than nulls:
- An unattributed request has no vendor identity. It is invisible to per-person waste readings -- its spend is counted, only its person is unknown.
- The unattributed bucket is the roll-up grouping for an empty team or project tag. It carries members and spend, and it is never an error.
The efficiency team roll-up resolves through the curated roster alone and drops what it cannot resolve rather than filing it somewhere plausible.
Services
A service is the roster entry for one telemetry-emitting installation -- the unit that installation-grained traffic is attributed to. The Services screen lists the backend services calling the gateway with the spend and traffic each is responsible for: the non-human side of attribution.
Each row carries its requests over 24 hours, its spend for the window, its tokens, an efficiency label, an error rate, a status and its session count.
An unknown service is a not-found error, while a registered but silent one returns zeros. And the label on a service row is the heuristic service efficiency label, not the efficiency score -- there is no per-service efficiency score.
Seats
The seat roster is the subscription seats observed sending traffic.
It is what has been seen, never what you bought. The "N of M seats active" figure's M is the observed roster, and the plan costs beside it are published list prices applied to observed activity -- not a bill.
| Figure | Meaning |
|---|---|
| API-equivalent value | What this traffic would have billed on the metered API. Informational, not savings. |
| Active seats | At least one non-denied request in the window, out of the seats seen at the gateway in the roster lookback. |
| Requests, tokens, active days, last seen | Per seat. Last seen means last alive at the gateway, scoped to the roster window. |
A dormant seat -- one on the roster with no traffic in the selected window -- is the finding this surface exists to produce.
The roster lookback is not a constant. It widens with the window you select, and the interface reports the number of days it used.
Avoid the phrase "seat utilization" for spend against a prorated list price: it is a ratio of dollars to dollars, it routinely exceeds one hundred percent, and it is a share of no capacity and no request count.
The word seat itself is cut two ways in this product, and they meet only in the spelling: the credential class on a guardrail -- which forwards with a developer's own subscription login and cannot carry a budget, a rate ceiling or a key binding -- and the seat-roster login here.
Spend and notional price
| Term | Meaning |
|---|---|
| Spend | What the upstream reported charging on connector-routed traffic, and what DevZero's own catalog prices the tokens at everywhere else. It is the figure the governance gate accrues against a budget. |
| Notional price | What DevZero's catalog would have charged. |
Every dollar figure on subscription traffic is notional: no invoice stands behind it.
Building your own view
The attribution surface includes a dashboard builder. You choose a metric (cost, tokens, requests, cache savings, input or output tokens, average cost per request, cache efficiency), a grouping (team, user, project, environment, model, provider), a chart type and a time range, with an optional single-dimension filter.