Best way to Capture Interview Duration

[sham]

Hi Family,
I have being wondering how one can measure the actual duration of a interview(using the start time and end time logic of the system- all protected) most especially where you have enumerator starting an interview say exactly 8:00AM but along the line say (8:30AM), the respondent had an emergency and rescheduled the interview session say at 11:00AM within the same day. So enumerator partially save the case and went back later at 11:00:AM as scheduled to continue the interview from the partially save case and ended the interview at 12:00PM. Now technically because the start time has already being established and captured at 8:00AM and protected, the end time will now also captures 12:00PM when the enumerator accepted the case as finally completed, which means that the enumerator has used 4hours to complete that interview which is not accurate interms of the actual action of the interview.
So is there a way that the Cspro logic can take care of the breaks and finally calculate the actual "engaging" hours to complete such an interview?
So for this scenario, the actual interview time to complete the survey would have being (1hr:30mins) instead of the 4hrs.

IN summary:
start time: 8:00AM
Break:(8:30AM-11:00AM)
Back to continue and finish (11:00AM-12:PM)

Is there any help to resolved this particular situation with interviews that has break time in between?(my worries)
I would be very grateful if you could help me in that regards because interview duration is one of the most important variable for quality checks.

This is usually the logic that I used to capture start time and end time of interview to help me get the Duration.
PROC STARTTIME
preproc
Satr
if visualvalue(STARTTIME) = notappl then
STARTTIME = systime("HHMM");
endif;

PROC ENDTIME
preproc

if visualvalue(ENDTIME) = notappl then
ENDTIME = systime("HHMM");
endif;

Thank you.

[sherrell]

You have two choices, but both require a little bit of work. You could either:

[1] use the statistics that CSPro generates when collecting paradata, or
[2] you can collect the information yourself.

[1] To utilize CSPro's paradata, go to Options > Application Properties within the CSPro developer. "Paradata" is the first choice in the tree on the left. With that chosen, on the right side you'll see the "Paradata Collection" block. Choose all events. When you run your data entry application, be sure to use a ".cslog" extension when naming your paradata fle. After completing entry, you can launch the Paradata Viewer by double-clicking on the generated ".cslog" file.

You'll see a bunch of reports listed; Durations > Sessions by CaseID might be what you want. When you select a report from the list, you'll see the table on the right. Note in the lower right-hand corner of the Paradata Viewer application that you can save the results to Excel. Do that, and from there either create a CSPro dictionary to manipulate the data further or do whatever you want within Excel to analyze the data.

[2] If you collect the information yourself, then you'll need to create a repeating record or item within a record to collect the start & stop times yourself. I suggest you use the timestamp() function to record the start & stop in seconds as it makes the math easier to do then if collecting the times in a day/month/year and then hours/seconds format. Make sure the roster is big enough to handle the number of times an enumerator might reenter a given case (5? 10? higher?). After entry is over you'd then use CSBatch to evaluate the start & stop times.

Sherrell

[sham]

Hi Sherrell,
Beautiful guide.
I understood the process for option1. But for Option2 where you recommended me using the timestamp() function is where I am actually missing the steps. I will be grateful if you could kindly come again with the steps if possible give example to get it more clearer since I would like to go by your recommendation.

I do appreciate your time and effort Sherrell and team.

Thank you.

[sherrell]

I modified the simple app you sent earlier to include a timestamp. Test it by doing a partial save after you enter the first field, Q1. I've allowed for 9 occurrences (9 timestamps), so if you try to reenter a case a 10+ time, no new timestamps will be recorded. So, if you envision an interviewer accessing a case more than this, increase the # to an appropriate value.

Note the interviewer will never be able to access this field, and so on a CAPI app, they would never even see it, as CSPro will be handling the assignment.

Sherrell

[sham]

Hi Sherrell,
Great effort thank you.
However, when I open the app the occurrence was set to 3 to allow for 3x and not 9 is that correct?

The next difficulty I am facing now is how to retrieve the timestamp that the system generated for me to make sense out of it (ie. Knowing the exact time that each interview(case) duration has taking). I created a CSBatch but still could not retrieved the time.

So like you suggested in your last statement "After entry is over you'd then use CSBatch to evaluate the start & stop times".
How do I go about that to achieve the desire results.

With your permission I attached the sample app which included the budge.

I am most grateful for your time and guidance.

Sham.

[khurshid.arshad]

Dear,

Please take a look at the attached app. You should now be able to view the time.
Best.
a.

[sham]

Hello Khurshid,
I would like to express my gratitude for your assistance in retrieving the necessary information. Your help is greatly appreciated.
I have a question regarding the use of CSBatch to evaluate start and stop times.

For instance, let's consider the following scenario
1. An Enumerator began an interview at 8:00 AM (with timestamp1) and worked for 30 minutes.
2. The respondent rescheduled the interview at 11:20 AM, prompting the Enumerator to partially save the case at 8:30 AM.
3. The Enumerator returned to continue the interview, retrieved the partially saved case at 11:20 AM (with timestam2), and finalized the case at 12:00 PM.

My inquiry is how to use the CSBatch setup to calculate and obtain the actual number of hours or minutes that the interview took to finish, considering the partial saves?
I would be grateful for any guidance you could provide as I have attempted to use the Batch and export the time into Excel. However, I am still unsure of how to use Excel to determine the actual interview time based on the partial saves.
With your permission, I have attached the setup for your reference.

Thank you for your time and expertise.

[sherrell]

Hi Sham,

I was testing with 3 occurrences to make testing faster but set it to 9 before zipping...or so I thought! Sorry for the confusion.

As to the app, you would of course need to include an end time which I totally forgot to do (!). And doing so makes it a bit more complicated. In this simple example one can only exit from two fields, Q1 or Q2; but assuming you had a much larger app, you would need a way to trap IN ONE PLACE the interviewer's early exit when they do a partial save. However when a case is saved using partial save, it doesn't exit through the postproc logic of the case (i.e., the level), so you can't put logic there. So what you have to do is add logic for the global OnStop function to manage this. See here for a description of the OnStop function:

https://www.csprousers.org/help/CSPro/o ... ction.html

You'll note in the help page above that when you use this global function, you now have to manage reentry to the application--that is, CSPro will no longer prompt the user with "Do you want to resume where you left off?" So if you want to offer that option to the user, you'll have to manage it yourself.

See attached for logic that covers the above. And hopefully you won't find any other omissions!

Sherrell

[sham]

Hi Sherrell,
Great news! I am thrilled to have been of help.
May I kindly request your assistance with two additional clarifications that I have come across?

1. So time various timestamps obtained, it means if I take the difference between each start and stop time and collapse the sum difference by case it will give me the accurate/actual interview time the enumerator spent to complete that interview is that correct?

EXAMPLE
id srt stop time_difirence(hh:mm:ss) Actualtime((hh:mm:ss)
1. 1681182712 1681183070 00:00:50
1. 1681183410 1681183423 00:00:10
1. 1681183467 1681183472 00:00:13 00:01:13

Hence, the person used 1min 13 seconds to conduct such an interview is that okey?


2. I also realized that, even if the case is completed and you want to just review the case, the start and stop timestamp is being created, so I went ahead and add another logic on MRESPONSE_ID to only trigger the start and stop timestamps if you are starting a fresh interview or resuming from the partial. but I only succeed when reviewing the completed case and also when resuming from the partial save case(which is wrong).
Can you help me figure out such that;

The timestamp is only active when you are beginning a new case and

When you are resuming from the partially save case.

But For all cases that are being completed, we do not allow the timestamp to work in an attempt to review/modify that case it should not apply with the time at all.

I attached the updated setup containing the new logic I added.

PROC MRESPONSE_ID
preproc
do varying numeric i=1 while i <= 9 and stop_loop=false; // 9 is the max # of occurrences for the start/stop time record
if demode()=1 then//TO STOP ADDING START AND STOP TIME AFTER A CASE IS COMPLETED BUT ENUMERATOR DECIDES TO REVIWE__SHAM
if start_time_secs(i)=notappl then // we found the next empty start time entry

start_time_secs(i)=timestamp(); // initialize it to the current time, in seconds
start_time_occ = i;
stop_loop=true;
endif;
endif;////SHAM
enddo;

if stop_loop=false then // all 9 occurrences have previously-entered data, so don't adjust the end time either
start_time_occ=notappl;
endif;


Thank you very much for your continued assistance.

[sherrell]

Hi Sham,

If you could, just send back the application you want me to look at--sending two forces me to have to do windiffs between the logic files to see what's going on.

As for your first question, yes, that's all you have to do, sum them up.

As for your second question, you added your if check within the do loop. I'm not sure why you want to enter the loop if all you're going to do is only execute the logic under certain circumstances. Therefore, the if demode()=1 should be before the do loop, not within it. And as you mentioned, adding this stops CSPro from adding new timestamps unless you're in add mode. All you have to do is add a call to the function isPartial(), to see if you're resuming a partially-saved case, and that handles the other piece of your work:

if demode()=1 or isPartial() then

Sherrell