🔧 Provide an option to suspend data collection

[shankari]

We just received a request from @mattwigway to add support for suspending data collection. They are running a panel study, so they want to suspend between multiple rounds of data collection.

The principled way to support this is to have the phone stop tracking. We do currently have the option to turn off tracking (profile -> tracking) but it needs to be done by the user at a per-phone level. This issue tracks the changes required to support this new functionality.

@asiripanich since you run panel studies as well

[shankari]

There are a few potential options to change this in the short-term:

1. Ask the users to manually turn off tracking
2. Switch to a different server for the second round
3. Ignore uploaded data if tracking is suspended

The first requires no changes, but requires individual users to make changes, which they will forget.

The second option would work as follows: People who do not turn off tracking will continue to accumulate data on their phones, but it won’t be accessible to anybody else while the server is offline.

Once the new server comes back online:

• Reconsent case: When users log out and log in with the new opcode, all their accumulated data will be deleted (thanks to @JGreenlee cleaning this up) https://github.com/e-mission/e-mission-phone/blob/89127bca0ae3f4074ab1fc9d7be0581ad62ea24f/www/js/control/ProfileSettings.tsx#L591 New data will be uploaded to the new server.
• No reconsent case: If users don’t log out or stop tracking, data will continue accumulating locally. Presumably at some point they will notice that the app is using a lot of storage and will delete it.

However, this also requires users to log off and log on with a new opcode, which increases user burden.
And it will still lead to additional storage on the phone when tracking is suspended.

I think that (3) solves both these issues, so I will expand on it in the next comment.

@Abby-Wheelis for visibility

[shankari]

Ideally, we would have an option that we would set once, at the project level. If it is set, then users will not have to do anything, but their data will magically not show up on the server.

As outlined earlier, the principled approach to make this happen is to have the phone stop tracking based on the config setting. But this is more tricky to implement; since we currently only download the config manually, and we don't currently store the tracking state separately, but have it reflected in the FSM directly.

A quicker-to-implement hack would be to have the server ignore any data that is received from the phone while tracking is suspended.

This would involve changing usercache/put to exit early if the program was suspended.

This means that:

• users can have the app installed with the same opcode
• when the program is suspended, they can launch the app and see their previous trips
• the app will continue collecting data and sending it to the server
• however, the uploaded data will simply vanish; it will not be stored anywhere
  • since the upload is "successful", the data will be deleted from the phone app
  • since the data was never stored on the server, it will not be visible there either

There may be a bit of an boundary issue, particularly if the user has a backlog of data on their phone - e.g. if the program is resumed on Jan 25, but a user has a backlog of data from Jan 20th, when that data is finally uploaded, it will be stored, although it was collected before the resume date.

A fairly simple workaround to that would be to have the suspended flag be a timestamp (or a range) instead of a boolean. usercache/put would then ignore all entries with a write_ts before the suspended timestamp (or within the range). This is not as simple as giant hammer of the early return, but it will avoid any boundary issues and is not too much more complicated to implement.

@mattwigway thoughts on this approach and whether it supports your use case?
@asiripanich thoughts on whether this would work for your panel studies?

[mattwigway]

I think the only use case this doesn't cover is re-consenting users for Wave 2 (which is pretty common in academic research, I think). Unless I'm mistaken, the process above would resume data collection for everyone (who still has the app and hasn't manually turned off tracking) when data collection resumes, rather than requiring users to opt back in to collection.

[JGreenlee]

I think the only use case this doesn't cover is re-consenting users for Wave 2 (which is pretty common in academic research, I think).

Good point.

In cases where Wave 2 deviates from the original Wave 1 consent agreement, I think it may make more sense to assign new opcodes and put them under a new subgroup for Wave 2.
We should be able to pause/resume on the server at the subgroup level.

To link the Wave 1 and Wave 2 data, we'd have to establish a mapping, or have a way to transfer data from Wave 1 opcodes' data to Wave 2 opcodes (related to what we are discussing in #1103)

[shankari]

To link the Wave 1 and Wave 2 data, we'd have to establish a mapping, or have a way to transfer data from Wave 1 opcodes' data to Wave 2 opcodes (related to what we are discussing in #1103)

@mattwigway is it a requirement, or even a nice-to-have that users in wave 2 would expect to see their trips from wave 1?
wrt re-consenting, what is the desired flow?

Is it: user opens app in wave 2; user is prompted to consent to wave 2; tracking starts?

How is that substantially different from the approach of asking them to turn tracking off and on manually in the app?
I thought that the benefit of approach (3) is that you wouldn't need to rely on users to do anything, which would reduce user burden.

[mattwigway]

I think we need to be able to turn tracking off across the board, because people haven't consented to wave 2 yet.

For turning it back on, it's more flexible; a prompt in the app would be the ideal situation but I'm not expecting that to be possible. If there were a way to blanket turn off tracking so that folks could just go into the app and turn it back on would work, but it sounds like the tech stack isn't really built to enable that. I guess that leaves us with generating new opcodes.

Let me double check what the consent documents actually said and check with my co-PI to see if there might be any other options.

[asiripanich]

Hi @AlirezaRa94 and @MaliheTabasi - If this feature is something we might need, it would be beneficial for us to contribute to the discussion as well.

[mattwigway]

I think our preference will be to do as @JGreenlee described—if it is possible to turn off tracking by opcode groups, we will turn off tracking for Wave 1 participants and create a new opcode group for Wave 2. We will have an opcode-to-participant mapping locally that we can use to link Wave 1 and Wave 2 participants.

What's the timeline for implementation of suspension of tracking?