Where energy is consumed decides who bears the cost
Aliases: energy cost attribution · carbon accounting by location · grid carbon intensity
What it is
Behind every interaction decision (default quality, cloud versus local processing, whether to add one more model call) sits an energy cost, but where that energy is consumed decides whose account it hits: on the user's device it drains the user's electricity and battery; in a data center it burns the operator's power and carbon budget; on the transit network the cost lands on infrastructure and (ultimately spread back on) all users. Three implementations of one feature can feel identical and consume nearly the same energy while assigning the cost to entirely different parties. Locational attribution is the first quantitative question of sustainable design — before optimizing, ask "whose ledger does this energy go on," because whoever bears the cost is whoever has the incentive to save it.
Why it happens
Location determines the political economy of the cost. Device-side energy is immediately tangible to users (battery percentage), giving users direct motive to punish power-hungry apps — uninstall, restrict background — market pressure that forces designer optimization. Data-center energy is invisible to users, borne by the operator and booked into carbon disclosures; the incentive to optimize exists organizationally but is cancelled out by growth — efficiency gains get eaten by usage growth (the rebound effect). Grid carbon intensity complicates things further: the same kilowatt-hour can carry several times the emissions on a coal-heavy grid versus a hydro-rich one, making data-center siting an environmental decision, not only a commercial one; moving computation from user devices into a clean-grid data center can lower total emissions — and the reverse. Location also decides who can measure: device-side consumption is directly observable by users, center-side only via operator disclosure, and this transparency asymmetry makes invisible costs harder to govern.
Studying it
Carbon-accounting methodology supplies the quantitative frame: life-cycle assessment partitions emissions by location (device manufacturing, use-phase electricity, data-center operation), with use-phase emissions = power × duration × grid carbon intensity (mass per kilowatt-hour, fluctuating with grid mix and time of day). Empirical work measures real consumption: power meters and per-app energy interfaces on the device side; PUE (total facility energy / compute energy) and server power telemetry on the center side — combined, a single feature's energy can be attributed to a location. Methodological cautions: carbon-intensity data comes in temporal and regional granularities, and cross-region comparisons need aligned grid boundaries; amortization assumptions ("one-time manufacturing carbon spread over service life") materially change conclusions, so reports must disclose the amortization horizon; device-side measurement is confounded by hardware variance and should be stratified by device model.
Where it stops holding
Attribution is not optimization: neither "moving to the cloud is greener" nor "local processing is more responsible" holds in general — the answer depends on the grid, the hardware, and the feature's workload; the location frame supplies the structure of the question, not a ready verdict. Nor does attribution analysis cover all environmental cost: the embodied carbon of manufacturing (building one device emits far more than a year of its use) does not change with interaction design — that belongs to the hardware layer. What interaction design can move is use-phase power and duration, and indirectly the replacement cycle when bloatware forces early retirement.
Applying it
- Build an energy-attribution table for core features: each high-energy path tagged with its location (device / transit / data center), estimated power and duration, and the carbon-intensity band of the corresponding grid — a feature-level carbon profile.
- Add an "attribution parity" check to design reviews: feature upgrades must not quietly shift cost from an observable location (device battery) to an unobservable one (cloud); shifts require explicit declaration with a total-quantity comparison.
- For features with switchable compute location (local versus cloud inference), decide dynamically on the user's grid carbon intensity, defaulting to local when emissions are comparable (with battery-saving and offline-resilience benefits attached).
- Verify: re-measure the feature-level attribution table quarterly against updated grid intensity and business growth, confirming no feature has moved cost to a less transparent location under "net-neutral" rhetoric.
Related
- Same group: P4.15.2 Video bitrate and resolution are the largest single variable · P4.08.3 Software support windows deciding device lifespan
- Adjacent: P4.08 General facts of environmental cost · K6 Power characteristics of device form factors
- Search terms:
grid carbon intensity·carbon accounting·energy attribution