Raw wearable sensor data gives a product team maximum analytical control, while processed metrics reduce bandwidth, storage and integration effort. Neither option is universally better. The right choice depends on the intended use, algorithm ownership, latency, auditability, device resources, privacy obligations and validation plan. Many B2B projects need a deliberately defined combination rather than unrestricted access to every data layer.
Raw Data and Processed Metrics Are Different Deliverables
Wearable projects often use “health data” as if it were one product feature. In practice, data moves through several layers. A sensor may generate electrical or digital samples; firmware may filter or aggregate them; an algorithm may produce a metric; an application may convert that metric into a label, trend or recommendation. Each layer has different technical, commercial and validation implications.
| Data layer | Typical content | Main value | Main limitation |
|---|---|---|---|
| Raw samples | Sensor readings with timestamps and acquisition metadata | Maximum flexibility for signal analysis and custom algorithms | Highest volume and strongest need for format, timing and quality documentation |
| Conditioned signal | Filtered, calibrated, resampled or motion-compensated values | Reduces some low-level processing work | Processing choices may remove information or introduce dependencies |
| Features or epochs | Windowed statistics, peaks, intervals, counts or quality flags | Balances analytical value with lower data volume | Windowing and feature definitions must be disclosed |
| Derived metric | A calculated value such as a summary, score or trend | Efficient for applications and dashboards | Depends on an algorithm, version, inputs and operating conditions |
| Interpretation | User-facing category, message or recommendation | Easy for a user or workflow to consume | Can exceed the evidence or intended-use boundary if poorly governed |
This layered model is a useful starting point, not a promise that every device exposes every layer. Raw data access, processed fields, sampling behavior, SDK/API support and interface permissions must be confirmed for the selected product and project.
What Counts as Raw Wearable Sensor Data?
“Raw” should be defined in the project data contract. A stream described as raw may already have undergone analogue conditioning, sensor-internal digital filtering, automatic gain control, scaling, clipping, resampling or packetization. Those operations do not make the data unusable, but they affect how an algorithm team can interpret and reproduce it.
For each proposed raw stream, ask for a precise definition:
- Sensor channel and physical meaning
- Numeric representation, scale, offset, unit and valid range
- Nominal and effective sampling behavior
- Timestamp source, clock domain and synchronization method
- Filtering, calibration, gain control and resampling applied before exposure
- Packet sequence, missing-sample and overflow behavior
- Device, firmware and configuration identifiers
- Quality flags and conditions that invalidate or qualify a sample
A list of field names is not enough. The same integer sequence can represent very different physical information depending on scale, sensor mode, timing and processing history. For time exchange, RFC 3339 provides a widely used Internet timestamp format, but a wearable project must still define whether a timestamp represents acquisition, device storage, phone receipt, cloud ingestion or later processing.
What Is a Processed Metric?
A processed metric is a value produced after one or more transformations. It may summarize a time window, detect an event, estimate a physiological or activity-related quantity, or combine multiple signals. The metric is therefore inseparable from its algorithm definition, input requirements and version.
A useful metric contract should state the metric name, unit, aggregation window, update cadence, required inputs, missing-data rules, quality criteria, algorithm or processing version and known limitations. It should also distinguish a measurement or estimate from an interpretation. A trend, score or category should not silently become a diagnosis.
The HL7 FHIR Observation resource illustrates why values need context: it can represent quantities, sampled data, effective time, absent-data reasons, device references, components and relationships to data from which an observation was derived. A B2B wearable project does not have to use FHIR, but it should solve the same basic problem—preserving enough context to understand what a value means.
Decision Matrix: Which Data Layer Fits the Project?
| Project need | Likely starting point | Questions before approval |
|---|---|---|
| Standard dashboard or user application | Processed metrics and quality/status fields | Are definitions, units, latency and version changes documented? |
| Custom signal-processing or algorithm research | Raw or conditioned signals plus acquisition metadata | Are access, format, completeness and ground-truth plans feasible? |
| Operational monitoring | Processed metrics plus device and sync status | Can delayed, missing and invalid data be distinguished? |
| Interoperability with another data platform | Structured metrics with identifiers, units and provenance | Does the receiving system understand the same semantics? |
| Algorithm audit or retrospective investigation | Versioned metrics plus selected source or intermediate data | Can a result be traced to device, firmware, inputs and processing version? |
| Bandwidth- or battery-constrained workflow | On-device features or summaries | What information is lost, and can exceptions trigger richer data capture? |
The best architecture may be hybrid. For example, routine operation can use compact metrics while a defined diagnostic mode captures short, consented segments of higher-resolution data. That approach still requires engineering review; richer transmission can affect device memory, radio activity, mobile synchronization, cloud storage and privacy exposure.
Seven Tradeoffs B2B Teams Should Evaluate
1. Algorithm control and responsibility
Raw data can give a buyer more freedom to develop or replace algorithms, but it also shifts processing, validation, monitoring and support responsibility toward that buyer. Processed metrics reduce that burden only when their definitions and limitations fit the intended use. Ownership, licensing, update rights and support boundaries should be written into the project scope.
2. Bandwidth, battery and synchronization
Higher-volume streams generally require more storage and data transfer than summaries. The actual impact depends on channel count, representation, acquisition schedule, buffering, compression, radio behavior and sync frequency. Do not estimate battery life from sample rate alone. Test the complete device-to-app workflow under representative conditions.
3. Storage and retention
Raw signals can create substantial local and cloud storage obligations. Define retention by data class rather than applying one period to everything. Record whether data can be regenerated, whether deletion must propagate across backups, and which party pays for transport, storage and processing.
4. Latency and user experience
An on-device metric may be available before a raw stream is synchronized and processed in the cloud. Conversely, a cloud pipeline may support richer analysis at the cost of delay and network dependency. Specify when each value becomes available and what the application should show while data is incomplete.
5. Traceability and reproducibility
A number without provenance is difficult to audit. Preserve the device identity appropriate to the project, firmware, configuration, sensor mode, time basis, processing version and quality status. If the algorithm changes, decide whether historical data will be reprocessed or remain associated with its original version.
6. Privacy and access control
Collecting more data is not automatically better. Define purpose, lawful basis or consent where applicable, minimum necessary fields, access roles, export, retention and deletion with qualified privacy counsel for the relevant markets. Raw signals may still be sensitive even when they do not carry an obvious human-readable label.
7. Validation and intended use
Validation should follow the intended decision. A signal-quality test, a metric-comparison study and a user-facing interpretation require different evidence. The FDA's final guidance on digital health technologies for remote data acquisition in clinical investigations emphasizes fit-for-purpose evaluation in that specific regulated research context. It should not be used to imply that an ordinary wellness product or J-Style model is clinically validated.
Build a Field-Level Wearable Data Contract
Before software development begins, turn “we need the data” into a versioned contract. JSON is standardized by RFC 8259, but valid JSON does not define the meaning of a wearable field. The contract should cover semantics as well as syntax.
- Identify the layer: raw sample, conditioned signal, feature, metric, summary or interpretation.
- Define the field: name, meaning, unit, scale, precision and valid range.
- Define time: acquisition clock, time zone, offset, window and upload time.
- Define quality: validity flags, missingness, clipping, motion or other relevant conditions.
- Define provenance: model, firmware, configuration and processing version.
- Define transport: BLE, SDK, API, export or another supported path.
- Define lifecycle: update policy, backward compatibility, deprecation and migration.
- Define acceptance: representative test cases, expected output and pass/fail rules.
Use the wearable API evaluation checklist for authentication, authorization, pagination, errors and version governance. For teams still choosing an access model, compare SDK, API and BLE integration options before finalizing the contract.
How to Validate the Chosen Data Layer
Validation begins with traceability, not a polished dashboard. Collect representative records, then connect each result to the device, configuration, time source, processing version and test condition. Include clean and adverse conditions relevant to the intended workflow, and record missing, delayed and invalid data rather than removing inconvenient cases.
- Confirm that units, scaling and timestamps match the contract.
- Compare packet or record counts across device, app and backend.
- Test interrupted synchronization and late-arriving records.
- Verify quality flags and missing-data behavior.
- Repeat processing with the same version to check reproducibility.
- Run regression tests before accepting firmware or algorithm changes.
- Define whether results are informational, operational, wellness-related or part of a regulated intended use.
The wearable acceptance criteria guide can help convert these requirements into measurable gates. Teams working with HRV should also review the difference between signal conditions, interval data and derived HRV metrics in the wearable HRV data guide.
Common Procurement Mistakes to Avoid
The first mistake is requesting “all raw data” without linking that request to a use case. This can increase technical scope while leaving the engineering team without the metadata, tools or validation evidence needed to use the stream. Begin with the decisions the application must support, then identify the minimum data layer that preserves the necessary information.
The second mistake is treating a visible app value as proof that the same field is available through an SDK, API or BLE interface. Application displays, internal processing and external interfaces are separate deliverables. Confirm the exact interface, field, cadence, historical range and permissions in writing.
The third mistake is accepting a sample payload as complete documentation. A few successful records do not explain nulls, invalid values, clock changes, firmware updates, late synchronization or algorithm revisions. Require negative and boundary test cases as well as ordinary examples.
The fourth mistake is assuming that access creates ownership. Data rights, interface licenses, algorithm intellectual property, derived outputs, support materials and the right to use data for model development may have different terms. Commercial and legal review should match the proposed architecture.
Finally, avoid freezing the data decision before testing representative devices and workflows. A proof of concept may reveal that a compact feature set is sufficient, that selected raw windows are needed for troubleshooting, or that the planned sync pattern is impractical. Record the decision and its evidence so later teams understand why the architecture was chosen.
What J-Style Buyers Should Confirm
J-Style can provide SDK/API support at the company-capability level. Exact availability depends on the selected product, platform and project. Raw-data access, processed fields, BLE protocol, sampling behavior, documentation, licensing, algorithm ownership, security responsibilities and validation materials must be confirmed for the applicable scope.
For a productive technical review, provide the required signals or metrics, target use, data frequency, latency, retention, platform architecture, expected user and device scale, validation plan and acceptance criteria. That information makes it possible to identify a feasible data path without assuming that maximum data volume is the best design.
