Multi-Device Wearable Data: Normalization and Deduplication

Table of Contents

Key Takeaways

The same device often reaches a product twice, once through its own API and once through Apple Health or Health Connect. The two copies are rarely identical, so one path has to be chosen per data type.
When two devices measure the same time window, take the more reliable source for that window. Averaging produces a number neither device recorded.
Who picks the preferred source is a product decision with real trade-offs. Defaults set by the product keep data consistent, while user choice can lock users out of features they would otherwise get.
Sleep should be reported as a single event, coming entirely from one device, even if several are available. Stages from different devices do not add up to a night anyone slept.
Keep every record with its source attached and resolve conflicts when data is read. Rules can then change without losing history.

Is Your HealthTech Product Built for Success in Digital Health?

Introduction

How device priority should work when a user records the same time window on two devices is one of the first questions a product faces once it moves past one wearable data source per user. A phone and a watch count the same walk. A ring sends last night's sleep through its own API while the same session arrives through Apple Health. The dashboard then shows figures that mislead the user.

Multi-device wearable data is a merge problem with a small set of recurring cases. This article covers structural normalization first, then the difference between deduplication and source selection. It also covers who should decide which source wins.

For setup questions about connecting several wearables, the Open Wearables FAQ on integrating multiple wearables without vendor lock-in covers the connection side. This piece is about the data once the connections exist.

Structural Normalization of Wearable Data Comes First

You cannot decide whether two records describe the same event until they share a common grounding, in the time domain or through explicit labeling. Two HRV values can come from different calculation methods and still be recognized as covering the same night once each one is labeled with its method.

You can achieve this by converting each incoming record into one schema before any merge logic runs. This step is structural normalization. It changes how each record is shaped and labeled. Recalculating or rescaling the values is a separate step. Structural normalization covers four areas.

Units. Energy arrives in kilocalories or kilojoules. Some providers report active energy where others report total energy under a similar name.

Time. Store timestamps in UTC with the user's local offset kept alongside. Sleep crosses midnight and users travel, so each session needs a rule for which local day it belongs to.

Type definitions. One provider's resting heart rate can be a nightly minimum while another's is a daytime average. HRV is similar, since some sources report SDNN and others RMSSD. Map each field to a type definition that states what it measures.

Granularity. Some providers send a daily step total together with the intraday records behind it. Flag daily totals so a pipeline uses them as the daily figure and does not add the intraday records on top.

The granularity flag is easy to skip and expensive to miss, because summing both views counts the day twice. We fixed this class of issue in Open Wearables 0.6.2.

Same Time Window, Two Records: Deduplication or Source Selection

Two records for the same time window can mean the same measurement arrived twice. They can also mean two devices measured the same period. The first case calls for deduplication and the second for source selection.

The Same Device Through Two Paths

Many wearables offer their own cloud API and can also write to Apple Health or Health Connect. A product that connects both receives the same night of sleep twice. Timestamps usually differ by seconds or minutes. The durations may differ slightly too.

The two copies are also rarely equivalent. A device only writes to Apple Health if the user has enabled that setting in the device's own app, a step that is easy to miss. Many providers write only a subset of their metrics to phone health stores, so the direct API often carries detail the Apple Health copy lacks, such as sleep stages or HRV. The Apple Health path can feel faster on iOS because it skips a hop through the vendor's cloud. Background delivery on the phone is limited by the operating system though, as covered in what you can and can't do with Apple HealthKit data.

Resolving this case is one part of proper data deduplication. Match on user and data type first, then on a start and end window with a small tolerance. Then keep the path you prefer for that data type, usually the direct API, since it carries more detail.

Two Devices in the Same Time Window

A user carries a phone and wears a watch on a walk. Both count steps for the same forty minutes. These are two independent measurements of one activity, so neither count is a duplicate of the other.

Summing them doubles the activity. Averaging them produces a figure neither device recorded, which becomes a problem the first time a user compares your number with their watch face. Selecting one source per time window works best. For each overlapping window, take the more reliable source as defined by your priority rules. The lower-priority source fills only the periods where the preferred one has no data, such as a phone-only walk while the watch was charging.

Priority should be defined per data type. The device that is best for sleep is often not the best for steps or workout heart rate. A single global ranking of devices breaks as soon as users combine a ring with a watch. Keep the rules in configuration with two levels. The first ranks providers against each other. The second ranks device types within one provider, since a single account can deliver data from both a watch and a phone. One workable split is to prioritize direct API data from wearables such as watches and use the phone only as a fallback.

Any feature that counts activity toward a goal or a challenge depends on the same rule.

Should Users Choose the Source?

Once priority exists, someone has to set it. Teams usually choose between two models that trade consistency against user trust.

Product-defined defaults. The product sets the priority per data type and device, ideally based on validation research comparing devices against clinical reference measurements. Users see one number per metric per day with the source visible on tap. Data stays consistent across the user base. The team can also improve the defaults globally when research or device firmware changes, because no user has frozen an older configuration. On the downside, a user who trusts a particular device for a particular metric has no way to say so.

User-selected sources. The product lets users choose which device wins, per metric or overall. This matches what users believe about their own devices and can reduce complaints that the app "ignores" a preferred tracker. It also creates many configurations to support. Users can pick a source that is objectively worse without realizing it. Someone who sets a device without sleep stage tracking as their sleep source, while another connected device records stages, loses every stage-based feature. Derived metrics such as recovery or strain become harder to compare across users.

Many products land between the two. The system presents a short list of suitable options and explains the risk of each choice, for example that a given device does not record sleep stages. Defaults cover everything else. The right choice depends on whether the product's value rests on comparing users with each other or on each user's personal trends.

Merging Sleep From Several Devices

Blending sources does the most damage with sleep, because several metrics describe one night and they depend on each other. Sleep stages, for example, usually add up to form the total sleep time. Each device processes movement and heart rate signals slightly differently, so its stages only add up correctly against its own total. Taking deep sleep from one device and REM from another produces a structure that describes no real night. Sleep efficiency stops being defined.

Devices also disagree on sleep onset and wake time. The stage structure only makes sense relative to one device's measurement of the whole night.

Use one primary sleep source per user per night. The product takes that source's complete record for the night and falls back to the next source only when the primary has no data. Sources should not be mixed within one night. Naps recorded by a device that missed the main session can be stored as separate events. This is also the cleanest input for health scores built from wearable data, which depend on one consistent record per night.

Keep Every Record, Decide at Read Time

A first wearable pipeline has to decide whether to store every minute-level record or only aggregates. For multi-device data the safer answer is to keep both, together with every source's version of each record. Each record carries its source device and the path it arrived through. Priority runs when data is read for a summary or a score. The stored records stay untouched.

Changing a priority rule then requires no data deletion, because the losing records are still there. A bug in a merge rule can also be fixed and the history recomputed without asking users to resync.

Holding every source's records in your own storage is part of owning the data layer, as we described in data ownership in wearable health products. Stored health data falls under the constraints covered in data residency as an architecture decision. Storage cost can be managed with retention policies that keep minute-level records for a limited period and aggregates for longer.

Device Switches Mid-Program

A user moves from one watch to another and their resting heart rate shifts overnight. Their health stayed the same while the sensor and algorithm behind the number changed. In a product that tracks progress against a plan, this shows up as an artificial regression.

Any feature that compares today against a personal baseline will read a device switch as a real change. The defense starts with recording device identity on every data point, so the product can detect when the primary source for a data type changes. Baselines then get a recalibration window after a switch instead of one average that mixes old and new devices. The old device's history should stay, since it is still valid for trends within its own period.

How to Test Your Wearable Data Merge Logic

Merge logic fails on real users with messy device combinations, so a test set built from synthetic single-device data proves little. Build it from your own production data.

Select users with two or more active sources for the same data type and compare the merged daily figure with each source on its own. A merged step count higher than every individual source means something is summing that should not be.

Check nights that cross midnight and days where the user changed time zones.

Find users who switched devices in the past six months and review baseline-dependent features around the switch date.

Change one priority rule in a staging environment, recompute a month of history and confirm that only the expected figures moved.

Our Wearable Data Audit runs these checks against your own production data and reports which figures users are most likely to question.

How Open Wearables Handles Multi-Device Data

Open Wearables, the open-source wearable data platform Momentum built and maintains, runs on your own infrastructure. The merge rules and the stored records stay with you. It normalizes the structure of incoming data into a documented unified data model that keeps the source device on every data point.

Source priority is configured in the developer portal at two levels, provider priority and device type priority, as described in the priorities documentation. When data from several providers overlaps in time, the higher-priority provider wins. Within one provider the device type order decides. Summary endpoints apply the same priority rules. The sleep sessions endpoint returns every session by default and keeps only the highest-priority source's sessions per night when the priority filter is enabled.

curl -H "X-Open-Wearables-API-Key: YOUR_API_KEY" \
  "http://localhost:8000/api/v1/users/{user_id}/events/sleep?start_date=2026-09-01&end_date=2026-09-07&filter_by_priority=true"

Setting the nap filter to false returns main sleep only, which matches the one-session-per-night approach above.

Heart Monitor runs Open Wearables in production for roughly 90,000 monthly active users on its own infrastructure, as described in how Heart Monitor self-hosts its wearable data. The code and current provider coverage are in the Open Wearables repository. Teams that run their own pipeline can apply the same rules without adopting the platform, a choice we covered in why teams outgrow SaaS aggregators.

Find Out Where Your Numbers Diverge

Our Wearable Data Audit looks at your current data sources and how consistent the data is across devices. It also shows where your integrations are fragile to provider changes. You get a picture of your current setup with the risks named and concrete next steps. If your users connect more than one device, talk to our team or see how our Wearable App Development services cover the data layer.

Frequently Asked Questions

What is data deduplication in wearable data?

Data deduplication in wearable data is the process of detecting records that describe the same real-world measurement and keeping only one of them. In a health product this usually means the same sleep session or workout arriving through two paths, such as a provider's API and a phone health store. Two devices measuring the same activity independently are a separate case that needs source priority rules.

How do you deduplicate wearable data?

You deduplicate wearable data by matching records on user and data type within an overlapping time window, then keeping one copy. This applies when the same measurement arrives through two paths, such as a provider's API and a phone health store. When several devices measured the same period, the product selects one source per window with priority rules, which is a separate step from deduplication.

What is an example of data deduplication in a health app?

A common example is a sleep session recorded by a ring that reaches the app twice, once from the ring's own cloud API and once through Apple Health. The two copies differ by a few minutes in start time. Deduplication matches them as one night and keeps the copy with more detail, usually the direct API record with sleep stages.

What does data normalization mean for wearable data?

Data normalization for wearable data usually means structural normalization, which converts records from each provider into one consistent schema before they are stored or compared. It covers units and timestamps with time zone handling. It also covers type definitions and granularity, so a daily total is not summed together with the intraday records it was built from. Normalizing the measured values themselves is a separate step.

What is an example of normalized wearable data?

A typical example of structural normalization is energy expenditure that one provider reports in kilojoules as total energy while another reports it in kilocalories as active energy. After structural normalization both are stored in the same unit under separate, clearly defined types. The product then never compares total energy from one device with active energy from another.

How long does it take to build source selection and deduplication for multi-device wearable data?

The time to build source selection and deduplication for multi-device wearable data depends mainly on how many data types the product merges and whether records are stored with their source. Many edge cases only appear once real users connect combinations of devices, so the rules need a round of tuning on production data. Pipelines that already keep every record with its source can add or change merge rules much faster than ones that merge at write time.

Can Momentum review how our product merges wearable data?

Yes, Momentum's Wearable Data Audit reviews your current wearable data sources and how consistent the data is across devices. It also identifies integration points that are fragile to provider changes. You get the risks named with concrete steps to fix them. Talk to our team to start.

Written by Filip Begiełło

Lead Machine Learning Engineer

He specializes in developing secure and compliant AI solutions for the healthcare sector. With a strong background in artificial intelligence and cognitive science, Filip focuses on integrating advanced machine learning models into healthtech applications, ensuring they adhere to stringent regulations like HIPAA.