Your Wearable Collects 5 Million Data Points: Here's Why Almost None of It Gets Used

What Seven Years of Wearing a Watch Actually Produces

Most people who wear a smartwatch check their step count, maybe glance at a heart rate chart after a workout, and move on. The device keeps recording either way. Over seven years, one of our engineers' Apple Watch quietly accumulated more than 5 million individual health measurements.

The breakdown is worth looking at closely:

Nearly 2 million active energy readings. Over 600,000 heart rate measurements. Hundreds of thousands of step counts, distance logs, and cycling records. Tens of thousands of respiratory rate samples and walking gait metrics. All from one person, one wrist, one ecosystem.

This is an extraordinarily detailed longitudinal health record. The kind of dataset that a decade ago would have required a clinical study with dedicated monitoring equipment and a team of researchers to collect. Now it accumulates passively on millions of wrists around the world, and the vast majority of it is never analyzed beyond a daily summary screen.

The question worth asking is: what could you actually learn from this data if you could use it properly?

A $200 Billion Industry at an Inflection Point

The scale of the opportunity becomes clear when you zoom out from one wrist to the entire market.

The wearables market is worth over $200 billion in 2025 and is projected to grow to $500 billion by 2030. Over 86 million Americans, nearly one in four people in the country, use health-related wearables. Smartwatches alone represent nearly half of this market, and that doesn't count the expanding ecosystem of fitness rings, continuous glucose monitors, smart clothing, and specialized biosensors entering the space every quarter.

CES 2026 made the direction unmistakable. The event was packed with health tech and wearables announcements, and the pattern was clear: the industry is shifting from all-in-one devices toward specialization. Manufacturers are focusing on battery life and repositioning AI as an active analytical tool rather than a passive tracking feature. Over half of the health-related exhibits were tied to the "longevity economy," a market valued at $35 trillion today and projected to reach $95 trillion by 2050.

What this means practically is that the number of devices generating health data is growing, the types of data being collected are diversifying, and the expectation from users and the industry alike is shifting from "show me my steps" toward "tell me something I don't already know about my health."

The raw material for that shift already exists on millions of devices. The gap is in what happens next.

What Researchers Are Already Discovering in Wearable Data

While most consumer-facing apps still show basic charts and daily summaries, the research community is finding that wearable data, when properly aggregated and analyzed, contains signals far more powerful than step counts.

Predicting health issues before they become critical. Machine learning models trained on wearable data are demonstrating the ability to identify early warning signs of cardiovascular events, respiratory decline, and metabolic dysfunction. The key insight is that continuous passive monitoring captures subtle longitudinal trends (a gradual decline in HRV over weeks, a slow shift in resting heart rate, a change in sleep architecture) that episodic clinical visits miss entirely. Your doctor sees you for fifteen minutes twice a year. Your watch sees you twenty-four hours a day.

Detecting patterns no human would spot. AI-powered wearable analysis is finding correlations across heart rate, sleep quality, activity levels, and recovery metrics that are invisible in isolation but become meaningful in combination. A single night of poor sleep might mean nothing. But poor sleep correlated with rising resting heart rate, declining HRV, and reduced physical activity over a two-week window can signal overtraining, early illness, or chronic stress, well before the person feels anything is wrong.

Transforming chronic disease management. Studies show that continuous glucose monitors paired with AI are fundamentally changing how diabetes is managed. Rather than relying on periodic blood tests and self-reporting, continuous data streams allow models to learn individual glucose response patterns and provide personalized recommendations. The same principle applies to other chronic conditions: asthma management through respiratory rate tracking, cardiac rehabilitation through activity and HRV monitoring, mental health screening through sleep pattern analysis.

Personalizing training beyond generic plans. In the fitness and performance space, the most interesting applications combine data from multiple sources. A runner's heart rate data from their watch, recovery score from their Whoop, sleep stages from their Oura ring, and training load from their cycling computer together tell a story that no single device can tell alone. Coaches and athletes who can access this unified picture are making training decisions based on data rather than intuition.

Enabling population-level health insights. Beyond individual health, aggregated wearable data is opening new possibilities for public health research, corporate wellness measurement, and clinical trial design. Researchers can study health patterns across thousands of participants using data collected in real-world conditions rather than controlled lab environments, producing insights that are both more scalable and more representative of how people actually live.

The common thread across all of these applications is that the value isn't in any single metric from any single device. It's in the combination: multiple data types, from multiple sources, tracked continuously over time, and analyzed by models that can see the full picture.

Which brings us to the problem.

Why This Data Is Still Trapped in Silos

If wearable data holds this much potential, why isn't more of it being used? The answer is fragmentation, and the problem is structural, not technical.

Every major wearable provider speaks a different language. Not metaphorically. Literally different data schemas, authentication systems, sync mechanisms, and API architectures.

Garmin uses push-based webhooks that send data to your server when it's ready. Apple Health has no backend API at all. The data lives on the device and can only be accessed through HealthKit on iOS, meaning you need a native mobile app even if your entire product is web-based. Whoop has its own OAuth implementation with different scopes and token behaviors. Polar and Suunto each define the same health metrics (sleep, activity, heart rate) using completely different data structures and field names.

A metric as simple as "sleep score" can be calculated entirely differently across providers, making direct comparison meaningless without normalization. Heart rate data might arrive as minute-by-minute averages from one device and as raw beat-to-beat intervals from another. Time zones, data granularity, sync frequency, and historical backfill behavior all vary by provider.

For any developer or team trying to build something that uses data from more than one wearable ecosystem, this means implementing separate integration codebases for each provider, each with its own OAuth flow, data mapping logic, error handling, rate limiting, and ongoing maintenance as APIs evolve. A single wearable integration typically takes weeks. Supporting three or four major providers can set a project back by months, months spent on plumbing that has nothing to do with the actual value the product is supposed to deliver.

This is the bottleneck. Not a lack of data, not a lack of ideas, not a lack of demand. The structural fragmentation of wearable data across incompatible ecosystems is what prevents the vast majority of those 5 million data points from ever being combined, analyzed, or acted upon.

What a Unified Approach Looks Like in Practice

To make the problem (and the solution) concrete, it's worth seeing what "unified wearable data" actually looks like at the code level.

When wearable data is properly normalized, requesting a daily activity summary produces a consistent response regardless of the source device:

import requests

response = requests.get(
    "http://localhost:8000/api/v1/users/{user_id}/summaries/activity",
    headers={"X-Open-Wearables-API-Key": api_key},
    params={"start_date": "2025-01-01", "end_date": "2025-01-31"}
)

# Same schema whether the source is Garmin, Apple Watch, or Whoop:
# {
#   "date": "2025-01-15",
#   "steps": 8432,
#   "distance_meters": 6240.5,
#   "active_calories_kcal": 342.5,
#   "active_minutes": 60,
#   "heart_rate": {"avg_bpm": 72, "max_bpm": 145, "min_bpm": 52},
#   "source": {"provider": "apple_health", "device": "Apple Watch Series 9"}
# }

One request. One schema. No conditional logic for different providers in your application code. The provider field tells you where the data came from, but the structure is identical whether it originated on a Garmin Forerunner or an Apple Watch Series 9.

On the mobile side, syncing data from on-device sources like Apple Health becomes a configuration step rather than a development project:

import 'package:health_bg_sync/health_bg_sync.dart';

class HealthService {
  Future<void> initialize() async {
    await HealthBgSync.configure(
      environment: HealthBgSyncEnvironment.production,
    );

    if (HealthBgSync.isSignedIn) {
      print('Session restored for ${HealthBgSync.currentUser?.userId}');
      return;
    }

    final credentials = await yourBackend.getHealthCredentials();

    await HealthBgSync.signIn(
      userId: credentials.userId,
      accessToken: credentials.accessToken,
    );

    await HealthBgSync.requestAuthorization(
      types: [
        HealthDataType.steps,
        HealthDataType.heartRate,
        HealthDataType.sleep,
        HealthDataType.workout,
      ],
    );

    await HealthBgSync.startBackgroundSync();
  }
}

Background sync, retries, and data normalization are handled by the SDK. The backend receives clean, unified data without additional engineering work on the mobile side.

This is what closing the fragmentation gap looks like at the implementation level. The complexity of dealing with multiple providers, their authentication quirks, and their schema differences gets absorbed into the infrastructure layer, leaving application developers free to focus on what they're actually building.

Three Paths Forward

For teams building products or research platforms that need wearable data from multiple sources, the landscape currently offers three approaches, each with real trade-offs.

Build it yourself. This gives you full control over every aspect of the integration: data handling, storage, processing logic, compliance. It also means your engineering team spends weeks or months on integration work for each provider, inherits a permanent maintenance burden, and rebuilds solutions that hundreds of other teams are also rebuilding independently. For well-funded teams with very specific requirements and long timelines, this can make sense. For most, the opportunity cost is too high.

Use a commercial SaaS aggregator. Several companies offer wearable data aggregation as a service. They handle the provider integrations and give you a unified API. The trade-off is per-user pricing that can scale unpredictably, dependency on a third party's infrastructure and roadmap, and limited visibility into how sensitive health data is being processed and stored. For teams that need to move fast and can absorb the cost, this is a viable option. For teams in regulated environments or those building long-term infrastructure, the control trade-off can become a problem.

Use open-source infrastructure. This approach combines the control of building yourself with the speed of using pre-built integrations. You run the platform on your own infrastructure, maintain full visibility into the codebase, and avoid both per-user pricing and vendor lock-in. The trade-off is that you own the deployment and operations. For teams that are comfortable running their own services (which is most development teams), this eliminates the primary downsides of both other approaches.

{{lead-magnet}}

What We're Doing About It

The third option is what led us to build Open Wearables. It's an open-source platform that normalizes data from Garmin, Apple Health, Whoop, Polar, and Suunto into a single REST API. Self-hosted via Docker, MIT-licensed, and designed so that a team can go from zero to pulling unified wearable data in minutes rather than months.

We built it because we kept solving the same integration problems across different client projects and decided to solve them once, properly, and make the result available to everyone.

This article is the "why" behind the project. If you want the "how" (architecture, tech stack walkthrough, setup guide, and the full developer experience), we've written a companion technical deep-dive that covers everything from the FastAPI backend and React developer portal to getting the full stack running with docker compose up.

You can explore the project at github.com/the-momentum/open-wearables, read the documentation at docs.openwearables.io, or join the community on Discord.

The data is already on millions of wrists. The research proves it's valuable. The infrastructure to unlock it should be open.

‍