Identify interviews completed through the browser (web-interviews)

Not sure if this belongs here or in the web-interviewing section, but that category appears to be more focused on self-enumeration surveys.

We’re currently running a price survey in a number of countries. Our enumerators are of different ages and have different degrees of technological affinity. I’ve therefore given some leeway in how the data is entered. Some are entering data on tablets directly, whereas others are using their phone to take pictures, or even write down prices on paper, to enter the data on the server using the web interface later.

I’d like to get an idea of how much of our data is collected using the tablets and how much comes from browsers. However, I can’t seem to find an easy way to identify which device was used to complete the survey. Is there an option to get this info through the API? I’m using the excellent wrapper by @arthurshaw2002 to run regular data exports. Is there a way to link the interviews to devices using this package?

Interesting question.

Unfortunately, I’m not sure I have a good answer. But I wonder if the interviewer action logs might not contain some clues. Intrigued by the question, I tried to see what I could find on my personal testing server.

In the image below, all cases were completd online:

While I’m not what everything in the logs mean exactly, I see two potential clues that might help tell whether interviews were filled on the web or on a tablet

  • “User [USER] logged in application”
  • “Sync started (Online)”

For a small modicum of reproducibility, here’s how I did this using my wrapper:

susoapi::get_user_action_log(
    user_id = "cc78158d-e987-4d7e-9cfb-fb4546d2c895", 
    start = "2021-01-01", 
    end = "2021-10-21", 
    workspace = "primary"
)

(Thanks, by the way, for the really kind words. I’m delighted to hear the package is useful for more people than just me.)

@renshendriks , you assume that an interview could be one of either types, but in fact it can be both: it can be started using the web interface, then continued using a tablet, and there could be numerous changes like this. So the answer must be more complex.

In practice - check the action types - InterviewReceivedByTablet 13 is what signals that subsequent edits were made on the tablet (from that event to Completed 3 event). If the edits appear without that event - that was portion completed on the web.

Of the top of my head, I don’t think event 13 is recorded for the new interviews Created on the tablet though. So you might need to establish the origin of the first editing spell using other clues.

Hope this helps.

You’re talking about the interview__actions file–correct?

If so, would these codes help? I’m not sure which actions would actually trigger them.

Code Meaning
19 InterviewSwitchedToCawiMode
20 InterviewSwitchedToCapiMode

For reference of those following this thread, here are the action values.

That will depend on the version.

If the interview was taken with the tablet running Survey Solutions 21.05 or newer, it should contain the events you’ve mentioned, such as shown below:

But CAWI mode is the mode where the interview is accessible from the internet, and not by the interviewer himself from the web login. So it is a bit of a different thing.

Read more about CAPI/CAWI switch here:

Thanks to you both!

@arthurshaw2002, I don’t think codes 19 and 20 are of help to me in this case. It looks to me like they pertain to a situation where the interview is explicitly set to CAWI mode on the complete screen on the tablet, where-after it’s accessed through a dedicated url in a browser. In my case, the enumerators simply login to the server using the same credentials as they use on the tablet. From what I can tell, the mode of such a survey remains CAPI.

I might be able to hack something together on the basis of status code 13 and some other triggers, but I’m not sure it’s worth the effort. I may take an easier approach and simply ask our price collectors what they did instead. That said if anyone has an idea that can be implemented in a simple way it would still be very welcome.

Do the action logs provide any leads?