Survey timing fields
| Field | Meaning |
|---|---|
measurementTime | A timing expression, such as a fixed time or window |
measurementInterval | Repetition interval, for example DAILY |
activeTimeMinutes | Response-window length in minutes after the start |
reminderOffsetsMinutes | Cumulative reminder offsets after the initial request is delivered |
notificationsEnabled | Notification choice made in the study configuration |
The compatibility path gives screen-level timing precedence over survey-level defaults. Check both occurrence identity and screen timing when presenting questions at different times.
Example timing fragment
Add this fragment to a survey definition. The reminder values are cumulative offsets of 15, 30, and 45 minutes after the request.
{
"measurementTime": "09:00",
"measurementInterval": "DAILY",
"activeTimeMinutes": 60,
"reminderOffsetsMinutes": [15, 30, 45],
"notificationsEnabled": true
}
An empty reminder list explicitly disables reminders. Omitting the field can use a different legacy compatibility path.
Dynamic anchors, including wake time
study_config.json can contain participant-specific availability windows and anchor policies. Current paths resolve a wake anchor (wakeAt), participant profile times, and supported health sleep-end records. Missing values and unavailable providers must be distinguished from a valid timestamp.
A dynamic policy requires its full configuration and connected collection items. Changing one string does not establish arbitrary event-triggered scheduling.
Operational checks
Check windows crossing midnight, expiry, reminders after completion, reboot, participant replacement, and timezone changes. Notification display and permission to submit are separate states; submission checks availability again.
The INSPIRE presentation's four daily requests, 60-minute window, and 15-minute reminders belong to that study protocol. They are not necessarily the values in the current repository's survey file.