.png)
When a user connects both an Apple Watch and an Oura Ring to your platform, you do not get twice the data. You get the same data twice. Sleep duration, resting heart rate, step counts, any metric both devices are capable of measuring will appear in your system from two separate sources, covering the same time window, with values that may be identical, similar, or slightly different depending on how each device processes its sensor signals.
For a typical user, owning multiple wearables is quite common. For the platform processing their data, it is a structural problem that compounds quickly. Duplicate data inflates metrics, distorts baselines, and corrupts the downstream analytics that health recommendations, risk scores, and clinical insights depend on. It is also, in most cases, entirely avoidable, but only if the data pipeline is designed to handle it from the start.
Duplication in wearable data pipelines has four main sources, each requiring a different approach to resolve.
Multiple devices measuring the same signal simultaneously is the most obvious case. A user who wears an Apple Watch and an Oura Ring to bed generates two sets of sleep data, two sets of heart rate readings, and potentially two HRV measurements for the same night. Both records are real. Both will arrive in your system as valid data. Neither is wrong, but treating them as independent observations doubles the apparent data volume and produces incorrect aggregates.
Aggregator apps are the more subtle and frequently overlooked source of duplication. Apple Health and Google Fit act as central hubs that collect data from all connected devices and apps on a user's phone. When a platform connects to both a device directly and to an aggregator that has also collected data from that device, the same event arrives twice: once from the device's native API and once from the aggregator's export. A step count from a Garmin watch may appear in your system as a Garmin record and again as an Apple Health record, with timestamps that are close but not necessarily identical.
User reconnection events occur when a user disconnects a device and reconnects it, either to troubleshoot a sync issue or to re-authorize data access. Depending on how the reconnection is handled, the initial data backfill on reconnection can duplicate records that were already ingested during the device's first connection period.
API retry and pagination logic can introduce duplicates at the ingestion layer. If a data fetch times out and is retried without idempotency controls, or if pagination logic does not correctly track which records have already been retrieved, the same records can be written to the data store multiple times.
Missing data creates gaps. Gaps are visible and can be flagged, handled explicitly, or acknowledged in downstream analysis. Duplicate data creates inflation that looks like complete, valid data.
A user whose steps are recorded by both a Garmin watch and Apple Health, and whose platform fails to deduplicate, may appear to have walked 20,000 steps on a day they walked 10,000. The consequences ripple through the entire analytics stack:
Unlike a data gap, which is visible and can be explicitly handled, duplication is silent. It looks like valid data because it is valid data, just from the wrong number of sources.
Apple Health and Google Fit deserve specific attention because they are the source of the most common and least visible form of duplication in wearable data pipelines.
Both platforms act as local aggregators: they collect data from every app and device connected to the user's phone and store it in a unified health database. When a user grants your platform access to Apple Health, they are granting access to a database that may contain data from their Apple Watch, their Oura Ring, a third-party fitness app, and a sleep tracking application, all merged into a single feed.
If your platform also connects directly to the native APIs of those devices, you will receive the same data from two sources: the device API and the Apple Health export. The records will cover the same time windows. They may have different timestamps, different levels of granularity, or different field structures, but they represent the same underlying measurements.
The standard approach is source hierarchy: for any given metric and time window, define which source takes priority and suppress records from lower-priority sources that overlap with it. But implementing this correctly requires knowing which Apple Health records originated from which device, which the Apple Health API does not always make straightforward.
Deduplication depends on reliably identifying which records represent the same underlying measurement. Three approaches apply to different types of wearable data.
Identifies records from different sources that cover overlapping or identical time windows for the same metric. A sleep record from Oura covering 23:00 to 07:00 and a sleep record from Apple Health covering the same window are duplicates. Timestamp comparison works well for session-based data like sleep and workouts, where records have explicit start and end times.
Tags each incoming record with a source identifier that persists through the pipeline. When the same measurement appears from multiple sources, the fingerprint allows the deduplication logic to identify the overlap and apply priority rules rather than treating the records as independent.
Handles time-series data like heart rate, where records are sequences of readings rather than discrete events. Two heart rate streams from different devices covering the same time period need to be compared as sequences, not as individual records, and the overlap needs to be resolved at the stream level rather than the individual reading level.
Source hierarchy and priority rules are the most practical approach for most production systems. Define a ranked order of source preference for each metric, for example, a medical-grade device takes priority over a consumer device, which takes priority over an aggregator export, and suppress lower-priority records that overlap with a higher-priority source for the same metric and time window.
Canonical source selection per metric extends the hierarchy approach by allowing different priority rules for different metrics. A user's Oura Ring may be the canonical source for sleep staging while their Apple Watch is the canonical source for activity. Priority rules do not need to be global, they can be metric-specific and user-specific.
Windowed deduplication for time-series data applies a time window within which records from multiple sources are compared and resolved. Records that fall within the same window and represent the same metric are collapsed to a single canonical value based on the source priority.
Idempotent ingestion pipelines address duplication at the infrastructure level by ensuring that writing the same record twice produces the same result as writing it once. Idempotency keys derived from source, metric, and timestamp prevent duplicate records from accumulating in the data store regardless of what happens at the fetch layer.
Deduplication resolves the question of which record to keep. Conflict resolution addresses what to do when two sources report different values for the same metric at the same time.
For most health metrics, the right approach is source priority rather than averaging. Averaging two HRV readings from different devices does not produce a more accurate measurement, it produces a number that is accurate for neither device's methodology and that cannot be meaningfully compared to either source's historical data.
The cleaner approach is to:
The exception is when no source hierarchy can be established, for example, when two devices of equal priority report different values. In these cases, flagging the conflict rather than silently resolving it is the more defensible approach. Downstream systems can then apply their own resolution logic or exclude the flagged records from analysis.
At Thryve, deduplication is handled at the infrastructure layer before data is delivered to partner platforms. Our API includes source tracking for every record, priority rules maintained across all 500+ connected devices and aggregators, and overlap detection for both session-based and continuous time-series data.
When a user connects multiple devices or authorizes access to an aggregator that overlaps with a directly connected device, the Thryve platform resolves the duplication upstream. Partners receive a single, deduplicated stream of normalized health data, without needing to implement source hierarchy logic, idempotency controls, or conflict resolution in their own applications.
With our platform, you get:
If you are building a platform that handles multi-device users and need a data foundation that resolves duplication before it reaches your application layer, book a demo with Thryve.
Friedrich Lämmel is CEO of Thryve, the plug & play API to access and understand 24/7 health data from wearables and medical trackers. Prior to Thryve, he built eCommerce platforms with billions of turnover and worked and lived in several countries in Europe and beyond.
.png)
.png)