How would you standardise Helicone properties and user IDs across teams for cost attribution?

## The real failure mode The mechanics of attribution in Helicone are a day-one task: set `Helicone-Property-*` headers for the dimensions you want and `Helicone-User-Id` for identity, and the dashboards slice accordingly. The reason organisations still cannot answer "what does feature X cost us per month" a year later is never the mechanics. It is that `env`, `environment` and `ENV` all exist; that half the services set nothing; that one team put a tenant id in a property and another put it in the user id; and that the eval pipeline's traffic is mixed into production numbers. Every one of those is a coordination problem, so the design has to be a coordination design. ## Fix a small vocabulary Start from the questions the business will ask, not from the fields available. Usually that is: which environment, which service, which product feature, which version. Four dimensions covers most of it, and the discipline is to resist growth — a dimension is only useful if *every* caller populates it, so each addition is a fleet-wide obligation, not a local decision. Write the vocabulary down with the exact header names, the allowed values, and the casing. Keep every value low cardinality and enumerable. Identity goes in `Helicone-User-Id`; per-run grouping goes in the session headers. Reaching for a property to hold a unique value produces a dimension with one member per row and quietly makes the dashboards useless. ## Enforce it in code, not in a document A wiki page describing header conventions has a half-life of about one quarter. What works is a shared client wrapper or factory that every service uses to construct its LLM client, which sets `Helicone-Auth` and the standard properties from the deployment environment automatically. Service and environment come from the platform, version from the build, and only the feature name is left for the caller to supply — ideally as a required argument, so omitting it is a compile-time or review-time problem rather than a missing dashboard column six weeks later. That wrapper is also where you normalise values, so `prod` versus `production` can never diverge, and where you later change integration mode for a whole fleet without touching call sites. ## Identity without PII `Helicone-User-Id` is the dimension that answers per-user and per-tenant cost questions, and it is also the one most likely to leak. It travels to and is stored by a trace store that many engineers can read, alongside the prompts themselves. Use a stable opaque internal identifier — an account id or a hashed user key — never an email address, username or anything else that identifies a person directly. Decide deliberately whether the unit of identity is the end user or the paying tenant; for a B2B product, tenant-level attribution is usually the one finance cares about, and per-end-user detail adds sensitivity without adding an answer. ## Match granularity to the decision Attribution is only worth what it changes. Ask what decision the number feeds before choosing a granularity: - **Budget awareness** — coarse dimensions (service, environment) are enough, and cheap to maintain. - **Team chargeback** — needs to reconcile with the provider invoice, which means being honest that derived cost figures can drift from what you are actually billed. Treat the vendor's number as the allocation key and the invoice as the total, rather than expecting them to match to the cent. - **Per-customer margin or usage-based pricing** — needs tenant-level attribution and, realistically, an export into your own warehouse. A vendor dashboard is a fine investigative tool and a poor financial system of record; you want the data joined to your own billing entities, retained on your terms, and reproducible after a retention window passes. ## Rollout and drift Two practical constraints shape the plan. Properties are not retroactive: a dimension exists only on traffic logged after you shipped the header, so the standard set should go out before anyone needs a breakdown, and comparisons should not straddle the rollout boundary. And attribution decays — new services appear, features get renamed, someone adds a property for an incident and leaves it. Give the vocabulary an owner, review it on a cadence, and add a simple check that flags traffic arriving without the standard dimensions, so gaps surface as a small ongoing fix rather than as a discovery during budget season. ## Where the tradeoff really sits The temptation is to instrument everything at maximum granularity because the headers are free. They are not free: each dimension is a permanent obligation on every caller, each identity field is a governance question, and every unused breakdown is maintenance nobody signed up for. The principal-level answer picks the smallest dimension set that answers the questions the organisation actually acts on, makes it structural so it survives turnover, and is explicit about which numbers are indicative and which are allowed to reach finance.