Incoming Device Data

Devices can be highly configured to change the way that data attaches to each event. Below we will learn about the configurations available and how you may want to leverage them.

Each device comes with a default configuration that should be appropriate most of the time.

Pulling API Data

Our system queries device APIs every hour. Data returned from the APIs is converted into Form Submissions, one for each data point. These Form Submissions are what show up in Manage Data. The system will then look through open events (and occasionally closed ones as well) to ensure the most applicable form submission is attached to the event. "Most applicable" is determined by the Attachment Strategy.

For some devices we don't query the API, but instead the API will push new data to us.

Additionally you can configure when and how data is attached to events. For example, data can be attached when we first get it and immediately mark the event completed (yellow). Data can also replace what was previously attached (blue). Sometimes it might make sense to wait until the event is over before attaching data (red).

Latency

Most devices have a default 4 hour latency, which means they are given an additional 4 hours after an event window closes to ensure they have all the data they need before taking any actions like attaching data, marking skipped, or applying feedback. This helps prevent issues with delays from API data.

Attachment Strategies

Each attachment strategy determines the criteria for which data point is the "best fit" for the event. In the diagrams below, we are waiting for the event window to end before attaching the most applicable Form Submission, but we could be attaching the Form Submission immediately, as detailed below in Attachment and Closing.





Attachment and Closing

Data can either be attached to an event when it comes in through the API, or it can wait until the event window (plus latency) has passed. The former can be thought of as Push attachment, since as soon as we get data we are pushing it to the event. The latter can be thought of as Pull attachment, since we wait until the event is over to pull from available Form Submissions.

Both configurations will mark an event Skipped if nothing has been attached after the event window (plus latency) has passed.

The Attachment Strategy will always used to determine the best candidate for attachment.



In the above diagram, the second Form Submission could replace the first one depending on other configuration settings as detailed in Replacing Data.

Replacing Data

We we get multiple data points for a device using Push ("Attach data and close event as soon as we have data") we need to know what to do with subsequent Form Submissions. It can either replace the previously attached Form Submission, or it can leave the old data attached.

The Attachment Strategy will always used to determine the best candidate for attachment, so even if you have chosen to allow replacement, it may not replace the data if it's not a better fit (a smaller value than what was previously attached when using Max strategy, for example).

Example usage: Fitbit participant doesn't sync their device until the following day, WTH will replace the '0 steps' with the # of steps that they walked

 

 

 

 

Applying logic

Another way that we are able to configure event behavior is by determining when we run the logic for the event. If there is a chance that data may attach to an event more than once based on other settings, this determines if we re-run any logic configured on that event again for the new data.

  • Only the first time data attaches: If any new data comes in during an encounter window that has already been completed, WTH will not do anything. 

    • This might be used if you want to track data that came in late, but don’t want to re-apply gamification logic around point additions/subtractions

  • Each time a new data point attaches to an encounter: If any new data comes in during an encounter window that has already been completed, WTH will reapply feedback on the encounter for each data entry 

    • This would be useful if you are setting adherence criteria on an event, and late data comes in which would update a non-adherent event to adherent

Intraday Data

Some devices (mainly Fitbit and Withings) support the collection of Intraday data. For more information on how to collect and use this, see https://waytohealth.atlassian.net/wiki/spaces/BG/pages/2575663108 .

Late Data

When participants sync late, W2H receives this data but any logic based on incoming data is not applied when data comes in late. Therefore, if your study applies financial incentives, points, levels, and/org messaging based on incoming data, the project manager will need to reconcile for the late data by adding points back or giving the participant credit, etc.