How to Normalize Wearable Data Across Apple, Garmin, Fitbit, Oura, and WHOOP

Every major wearable platform claims to measure the same things, but in practice, they do not. A resting heart rate reading from an Apple Watch and a resting heart rate reading from a Garmin are calculated using different windows, different algorithms, and different underlying assumptions. A sleep score from WHOOP and a sleep score from Oura are not the same metric as well, they are actually fundamentally different constructs.

For individual users, this is a minor inconvenience. For any platform, digital health service, or research trying to work with data from multiple devices at once, it is a foundational problem. Before any analysis can happen, before any clinical insight can be drawn, before any personalized intervention can be delivered, the data has to mean the same thing regardless of which device generated it. That process is called normalization, and it is harder than it sounds.

What Does Normalizing Wearable Data Actually Mean?

Normalization, in this context, means harmonizing data across sources so that the same metric carries the same meaning regardless of which device produced it. In practice, this involves four distinct layers:

• Format standardization: converting device-specific data structures into a consistent schema
• Unit harmonization: ensuring values are expressed in the same units across platforms
• Resolution alignment: reconciling differences in how frequently data is captured
• Semantic harmonization: ensuring that a metric labeled "HRV" on one device actually means the same thing as "HRV" on another

The last layer is the most difficult, and the most commonly underestimated. Two devices can produce a number for the same metric using entirely different methodologies. Without semantic harmonization, you are thinking that you are combining data, but actually you are mixing incompatible signals and treating the result as if it were consistent.

Why Each Platform Is Its Own Data World

Data fragmentation is a big question in today's wearable industry. Each wearable manufacturer has built a proprietary ecosystem, like dedicated hardware, software, and data infrastructure, optimized for their own device and their own user experience. Apple Health, Garmin Connect, Fitbit, Oura, and WHOOP each store data in platform-specific formats, process raw sensor signals through proprietary algorithms, and define derived metrics according to their own models.

This makes sense from a product perspective. It creates a significant problem from an interoperability perspective. When a user connects their Garmin to a third-party health platform, they are not sharing a standardized data stream — they are sharing a data stream that was designed to live inside the Garmin ecosystem, interpreted through Garmin's logic, and formatted for Garmin's applications. Let’s take a closer look at concrete examples. 

Which Health Data Signals Differ The Most

Heart Rate Variability (HRV)

HRV is among the most clinically relevant metrics wearables capture, and also among the most inconsistently implemented. The core issue is that "HRV" is not a single metric, it is a category of measures, each derived from a different statistical method applied to beat-to-beat interval data.

• Apple Watch reports HRV using SDNN, calculated from spot measurements taken during breathing exercises or during sleep
• Garmin reports HRV using RMSSD, measured continuously during sleep and averaged overnight
• WHOOP uses RMSSD measured during the final slow-wave sleep period
• Oura uses RMSSD averaged across the full sleep period
• Fitbit uses a proprietary HRV score derived from sleep data, with limited transparency into the underlying methodology

SDNN and RMSSD are not interchangeable. They reflect different aspects of autonomic nervous system function and produce different numerical ranges. A user who switches from Apple Watch to Garmin will not see a continuation of their HRV trend — they will see a different number measuring a related but distinct construct.

Sleep Staging

Every major platform offers sleep staging, and every platform does it differently. Consumer wearables infer sleep stages from accelerometer data and heart rate patterns rather than the polysomnography used in clinical settings. The algorithms that convert those signals into staged sleep are proprietary and vary significantly.

• Oura classifies sleep into light, deep, and REM stages, with particular emphasis on heart rate and temperature signals
• WHOOP focuses on sleep performance relative to a personalized baseline, with staging derived from movement and heart rate
• Fitbit provides light, deep, and REM staging alongside a proprietary sleep score
• Garmin offers sleep staging with additional HRV and respiration data during sleep
• Apple provides basic sleep tracking integrated with Health app, with more detailed staging on newer Watch models

What one platform calls "deep sleep" and what another calls "deep sleep" may be identified using different signal thresholds and different model architectures. Aggregating sleep stage data across platforms without harmonizing the underlying definitions produces noise, not insight.

Activity and Steps

Step counting appears straightforward but it is not. Each manufacturer calibrates its step detection algorithm differently, handles different movement patterns differently, and applies different filters to reduce false positives. A brisk walk measured on a Fitbit will typically produce a different step count than the same walk measured simultaneously on a Garmin.

Calorie estimation compounds this further. Total energy expenditure calculations incorporate resting metabolic rate, activity classification, and heart rate data — each of which is handled differently across platforms. A "500 calorie workout" on one device is not the same claim as "500 calories" on another.

Heart Rate

Resting heart rate is one of the most widely used biometric baselines, but the calculation window differs across platforms. Some devices calculate resting heart rate as the lowest average over a defined nighttime window. Others use the lowest reading during any low-activity period over a 24-hour window. Others derive it from a moving average. The resulting values are close, but not identical, close enough to appear comparable, different enough to distort trend analysis over time.

The Technical Challenges of Normalization

Data Format and Schema Differences

Each platform exposes data through its own API structure. Timestamps may be in different formats or time zones. Data may be organized by day, by session, by epoch, or by individual reading. Fields may be named differently, nested differently, or split across multiple endpoints. Before any semantic harmonization can occur, the raw structural differences have to be resolved.

Sampling Resolution

Resolution mismatches are a persistent problem. One device may capture heart rate every second during activity; another captures it once per minute. One platform provides minute-by-minute sleep staging; another provides a single summary for the night. When data from different resolutions is combined, the lower-resolution source limits what can be derived from the merged dataset, and if that limitation is not made explicit, it introduces silent errors into downstream analysis.

Missing Context

Raw biometric values often cannot be interpreted correctly without contextual metadata: activity type, device placement, wear time, environmental conditions. This information is inconsistently captured and inconsistently shared across platforms. A heart rate reading without activity context means something very different during a rest period than during a workout. An HRV reading without a wear time indicator cannot be assessed for reliability. Missing context does not just create gaps, it creates misleading signals that look like complete data.

What Data Normalization Actually Requires

Handling normalization at the application level, writing device-specific parsing logic for each platform your product supports, is technically possible but operationally unsustainable. Every API update from every manufacturer becomes a maintenance burden. Every new device integration requires a new normalization pass. The logic becomes fragile, expensive to maintain, and increasingly difficult to audit for consistency.

True normalization requires infrastructure that addresses all four layers, like format, unit, resolution, and semantics, systematically and consistently, across all supported devices, and maintained as the ecosystem evolves. This means:

• Standardized data models so that metrics are stored in a consistent structure regardless of source
• Harmonized metric definitions so that HRV means RMSSD, sleep staging follows a defined classification schema, and step counts are processed through a consistent filter
• Device-agnostic APIs that return normalized data without requiring the consuming application to know which device produced it

Without these layers, data from multiple devices can be retrieved and displayed, but it cannot be reliably combined, compared, or analyzed.

How Thryve Handles Data Normalization

At Thryve, normalization is built into the infrastructure layer rather than left to each partner to implement independently. Our API connects to 500+ wearables and health data sources and returns data through a single, consistent model regardless of the origin device.

With our wearable API, you get:

• Standardized Biometric Models: A unified data model across activity, sleep, heart rate, HRV, respiration, and more with consistent metric definitions applied across all connected devices
• Seamless Device Integration: Support for Apple Health, Garmin, Fitbit, Oura, WHOOP, and hundreds of additional sources through a single integration, without maintaining device-specific normalization logic
• GDPR-Compliant Infrastructure: Data handling that meets European privacy requirements by design, with consent management and data residency controls built in

If you are building a product that depends on reliable, cross-device health data, the normalization layer is not optional,  it is the foundation everything else is built on.

Book a demo with Thryve to see how normalized health data works across your target device ecosystem!

‍