Active versus total calories: stop mixing incompatible energy fields

Do not add active and total calories as though they describe independent energy expenditure over the same interval. Preserve each provider field’s meaning, time range and unit. If the application derives a fallback, label it as an estimate with its own calculation version rather than renaming it as a provider observation.

This guide is about data contracts, not dietary targets or advice. Prerequisites are an inventory of the source data types and a clear statement of what each product label promises. “Calories burned” is too ambiguous to serve as the storage schema, analytics event and visible dashboard label simultaneously.

Name active, basal and total separately

Google Health’s energy documentation distinguishes active energy, total calories and basal metabolic rates. Those API concepts provide a useful reference for field meaning; they do not make the Google Health API interchangeable with Android Health Connect or Apple HealthKit. Verify each platform’s identifiers and rate-versus-interval representation independently.

Google Health: calories and energy data types

The numbers are invented to explain overlap. They are not measured person data and are not recommended energy intakes. A basal rate is not an interval energy total until an explicit calculation integrates it over a defined duration. Preserve the rate unit and assumptions rather than treating every energy-related number as directly additive.

Trace fallback meaning before choosing a label

The reviewed UltraFit360 Android reader tries ActiveCaloriesBurned records before a later fallback path. The inspected portion adds energy values in kilocalories and returns a positive active total. This source observation motivates a full mapping review; it does not validate a fallback formula, establish complete pagination or prove that every zero is preserved.

For each fallback, write the trigger and output semantics. “No active record” is different from “active record with zero” and “read failed.” A fallback should not hide a permission or provider failure by generating a plausible number. When an estimate is necessary for a defined feature, retain its status so summaries and explanations can display that fact.

Use an explicit summary contract

{
  "interval": "synthetic reporting day",
  "activeKcal": 500,
  "totalKcal": 2100,
  "displayMetric": "totalKcal",
  "provenance": "provider observation",
  "estimateVersion": null
}

This is a proposed result shape. It keeps the selected display metric explicit instead of calculating a catch-all calorie sum. Add original source identity, import time and coverage in the real contract. If one field is unknown, preserve null rather than using another field’s value under the wrong label.

Test overlapping intervals and late corrections

Use fixtures where active and total cover the same day, where they cover different windows and where one source arrives later. A same-day date string alone does not establish identical boundaries. Verify timezone, interval length and source policy before comparing the numbers or computing a difference.

Test a correction to active energy without changing total, and the reverse. Derived summaries should invalidate only the dependencies the selected contract uses. Keep a stale value visibly stale if the new read fails. A backend receiving an estimate should not overwrite an observation merely because both currently fit a field named calories.

The review deliverable is a field lineage sheet: source identifier, unit, interval, observation or estimate status, mapping rule and visible label. It lets product and engineering assess meaning before discussing score weighting, and gives support a precise answer when two legitimate energy views differ.

Check exports and analytics alongside the dashboard. A UI can use precise active-energy wording while a CSV still labels the same column total calories. Map the selected meaning into every output and retain its unit in machine-readable fields. For a synthetic regression fixture, export the same reporting interval used by the screen and compare the field identity, not merely the number. Matching numbers on one day can conceal a semantic mismatch that appears only when another source arrives.

Health data provenance app

Building ultrafit360

Bring the specific record types, device/OS targets and one failing or proposed data journey to scope a wearable integration review.

Explore wearable integration