Interview key change

Our user Jennifer Goede has sent us the following question:

Can you explain to me when the interview key changes? I made a list of mistakes interviewers made, with their name and ED number. However when I look the interview key up it is now allocated to another interview.

An interview key is an 8-digit number assigned to interviews on the server (for example, 12-34-56-78). Every interview on a server has a unique interview key (even when they are in different surveys). If the interview is created on the server, its interview key will never change.

Yet, some interviews are created on tablets. Clearly there is a chance that two tablets will come up with the same number, and hence the same interview key. If that happens, the interview key of the first interview to reach the server will remain, while the second one will be changed.

This change can clearly occur only once, and at a particular time: at synchronization, when the interview reaches the server.

Chances of this happening are quite large. For a survey with 100,000 interviews you will have a noticeable number of interview key changes. So any program or script dealing with interview keys should be written with expectation that this will happen, rather than with a hope that this will not.

For working with exported data, match the records in different files not on interview__key, but on interview__id variable, which is stable (never changes).

1 Like

Thank you for the explanation.

Hi Sergiy,

A follow up to this question, Are the interview keys created completely at random? or is there any bias in the starting numbers, e.g. are certain interviewers given ranges of interview key or do earlier created interviews receive lower starting digits or anything like that?

Many thanks,

Lachlan

Hello @lachb , it is difficult to judge from the question whether this is something desirable, something that you want your project to rely on, or is it something undesirable, and what you’d rather avoid as this may be a risk. So please explain WHAT you want to do with the interview key.

In the above it was already written that “An interview key is an 8-digit number assigned to interviews on the server…” This definition shies away from mentioning randomness. In practice this means that this is something not promised, and even if it is random now, it may change in the future. There is nothing to hide though in an open-source project. You can see how the interview key is generated for yourself in the current version: surveysolutions/InterviewerInterviewUniqueKeyGenerator.cs at master · surveysolutions/surveysolutions · GitHub , but I wouldn’t rely on ‘random nature’ of the interview key for any practical project, especially since even if it is “completely random” it doesn’t necessarily mean that it is “normally distributed” or “uniformly distributed” which could be important for things you want to do with it, which you didn’t describe.

Hi Sergiy,

Thank you for the detailed reply, very helpful. And apologies for the lack of detail.

We are investigating some different methods to conduct a listing exercise and then complete the random selection and full interviews completely in the field. We are aware it is obviously better to do the selection back at HQ but for various operational reasons this isn’t possible.

We have a combined the listing and full survey into one designer questionnaire with the full questionnaire sections being enabled by a supervisor level question. This is working nicely, the supervisor will review all of the completed listings for the EA, activate those required for full survey and reject back to interviewers to complete.

The question is how what is the best method to select x of the eligible cases listed at random for full interview. One idea is to use the ‘interviews’ tab in HQ for supervisors to first filter on the required EA. Then sort the cases by their interview_key and take the first 12 eligible for full survey. Thus the question about any inherent biases in the generation of the interview_key which might make this not random.

We have considered also an EA level form for the supervisors to complete which would make the selection but there are concerns about the level of entry error and potential missed cases which would likely occur here.

If you have any thoughts, or alternative methods for selection we’d love to hear.

Many thanks,

Lachlan

Hello @lachb ,

I see the following as contradictive:

First you wrote:

and then later:

Will the listing data be sent to the server/HQ from the EA before the selection is made? If yes, do the selection centrally.

Hi Sergiy, sorry bad choice of terms - here I meant the physical headquarters as in the central office, not the application :slight_smile: