What to look for in an export file.

“Can I export my data?” is the right question to ask before buying, as the device guide says. This is the follow-up: once you have the file, how do you tell whether it is any good? You do not need special software. A text editor and a spreadsheet are enough.

Your right to the file, and its limit

In the EU, the data-protection regulation gives people the right to receive personal data they provided to a company “in a structured, commonly used and machine-readable format,” where the company processes it by automated means on the basis of consent or a contract.¹ That is a legal floor in one region, and we have not surveyed the rest. Note the phrase “machine-readable.” A graph as an image, or a PDF report, does not meet the spirit of it, and is not much use to you either.

Step 1: open it in a plain text editor

Before a spreadsheet tidies anything, look at the raw file. For CSV, the closest thing to a reference is a 2005 informational document, and it says something worth knowing: the format “has never been formally documented,” so implementations vary.² That makes a few checks worthwhile, all drawn from that document’s description of common practice:

• A header row, so every column has a name you can read.
• The same number of fields on every line. A ragged file can mean a comma inside a value that was not quoted.
• Fields containing commas, quotes or line breaks wrapped in double quotes, with any quote inside doubled.

Step 2: read the timestamps

Sleep crosses midnight, people travel, and clocks change twice a year. A timestamp is only meaningful if you can tell which moment it refers to. The internet’s timestamp standard stresses this: a numeric offset, as in 18:50:00-04:00, converts unambiguously to UTC (22:50:00Z), whereas a bare local time cannot be converted by anyone who does not know the zone, and daylight-saving rules are convoluted and change at unpredictable times.³

So look at a few rows. Does each time carry an offset or say it is UTC? If the file has bare local times, can you at least tell which zone the device thought it was in? Pick a night you remember, convert its timestamps yourself, and see whether they match reality. A one-hour shift around a clock change is one thing to look for.

Step 3: check the gaps

Missing data is normal. In a study of wearables, some data are never captured, for example when a device is not making skin contact, and devices may delete readings that fail their own quality checks, such as during large movement.⁴ Both leave gaps. What matters is how the file represents them:

• A blank or an explicit missing marker is honest. A zero is not: a heart rate of zero is a different statement from “no reading.”
• Check the sampling. Some research-grade devices report at an exact fixed rate by downsampling or interpolating,⁴ which means a smooth, gapless stream may be partly constructed. If you can, find out whether the file holds measured values or filled-in ones.
• Count rows per hour. If every hour has the same count when you know the device was off your wrist for two of them, the file may have been padded.

Step 4: units, labels and what is derived

Every value needs a unit and a clear meaning. EDF, a 1992 format for exchanging digitized polygraphic recordings, builds this in: its header stores the start date and time, the sampling for each signal, and a physical dimension for each, such as microvolts or degrees Celsius.⁵ A good CSV should tell you the same things in its column names or documentation. A column called value tells you nothing.

Also ask which columns are measured and which are derived. Sleep stages are the clearest case: they are an algorithm’s estimate from other signals, and in a comparison with laboratory recordings, consumer devices’ stage readings were described as inconsistent.⁶ A stage label in an export is a guess with a name. Look for whether the file says so, and for whether the underlying signals are included too, so a different method could re-derive it. EDF+ exists for just this need: it adds time-stamped annotations and allows derived results, such as sleep stage scorings, to be stored in linked files that share the original recording’s timing.⁷

Step 5: raw, or a summary?

One row per night is a summary. One row per minute, or per heartbeat, is much closer to raw. Summaries are fine for a diary and bad for comparing two devices, switching to another, or checking a device against itself. Prefer an export that offers both, and keep the original file untouched: work on a copy.

Sources

The studies and standards behind the claims above, so you can read them yourself. Listing a source is not an endorsement of any device it tested.

1. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 20, right to data portability — text read at gdpr-info.eu/art-20-gdpr.
2. Shafranovich Y (2005). RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files. Informational; updated by RFC 7111.
3. Klyne G, Newman C (2002). RFC 3339, Date and Time on the Internet: Timestamps. Proposed Standard.
4. Bent B, Goldstein BA, Kibbe WA, Dunn JP (2020). NPJ Digital Medicine 3, 18, doi 10.1038/s41746-020-0226-6 — data missingness and 1 Hz resampling in wearable heart-rate data.
5. Kemp B, Värri A, Rosa AC, Nielsen KD, Gade J (1992). Electroencephalography and Clinical Neurophysiology, A simple format for exchange of digitized polygraphic recordings — the EDF specification, as described at edfplus.info/specs/edf.html.
6. Chinoy ED, Cuellar JA, Huwa KE, et al. (2021). Sleep 44(5), zsaa291, doi 10.1093/sleep/zsaa291 — consumer sleep trackers vs polysomnography.
7. Kemp B, Olivan J (2003). Clinical Neurophysiology 114, 1755–1761 — European data format “plus” (EDF+), as described at edfplus.info/specs/edfplus.html.

← All articles

This article is general wellness education, not medical advice. SoluneFit is a wellness tool, not a medical device. It does not diagnose or treat any condition. Talk to a clinician about health concerns.