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. Currently, only the Twilio SMS Receiver and related devices work in this manner.
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).
Reapplying Event Logic
When you allow data replacement, you may or may not want re-run event logic if a new data point attaches to the event. This can be configured using the "Apply Event Logic" setting.
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.