There are a number of checks one can employ to get to the bottom of what, on first appearance, might look like a case of missing data.

When working through the following steps we would also ask you to fill out the attached Missing Data Checklist.xlsx and send it to support along with any request regarding missing data.  

1. Web Interviews are stored on the web server in the WebInterviews database. In case WebProd had issues writing data to WebInterviews then you can have interviews stored on here as .dat files. If you have access to the web server then you can check the directory: e.g. \\inetpub\webprod\AskiaWeb\[SurveyName] or \\inetpub\wwwroot\webprod\AskiaWeb\[SurveyName]. If you find files there then use Askia Tools to import data into the QES. Check data (again). If you do not have access to this directory please ask your system administrator to provide the .dat files.

2. Check the revision of the missing data respondents in one of two ways:

• Either by creating a variable in Analyse > From interview information > Revision and crossing this by a sub-population (or variable) which contains only the missing data respondents.

• Or by opening the QES with Access and checking Revision column in the ASK Response1 table.

3. If the revision is different than the current one (last working copy) that you are working/checking the routing please check File-Revision History in AskiaDesign for changes to those specific questions.

3. If any changes are present over the involved question(s) or over the chapter/loop/loop iterations that the question is included in (or you are not sure about it), please make sure you do another logic check following points below on the same survey revision as the respondents are.

4. Identify the first missing data point within the survey so go back through all dummy variables and routings to a point where missing data it is not explainable by routing. E.g. if Q1 has all selected responses linked from Qselect please check that Qselect is properly set and has responses in it. If, then, Q1 has values set into it from some routing then check that the values set are in agreement with the ‘All selected responses’ from Qselect. Also, include checks that the missing data is not because of Allow ‘Don’t Know’ or open ends that had space(s) entered as an answer instead of a non-response.

5. Make sure you have taken into consideration all the skip logic (go to / do not ask / only ask if) that can affect the questions you have identified as having missing data (or the chapter/loop/loop iterations that the question(s) belong to). It’s important to note that go to / do not ask / only ask if will clear data stored in questions that do not satisfy these conditions (example QEX file here). So to get around this effect we would recommend to use 'Make question invisible' routing type instead. Here you can also check if 'Even when skipped' is selected or not when evaluating routings. If this is not selected then, in addition, you have to evaluate the condition of the question which the routing is executed after (or before / during).

6. Isolate the missing data respondents into a no routing QES file and check again. This method is employed because when running, imports, merges, edits etc. in Tools the data will be verified against the routings that currently exist in the QES file. If these routings have changed then original data could be altered or blanked out to be cleaned in accordance with final routings. Deleting all routings from the QES file means the data is not subject to verification when carrying out these tasks in Tools. Sometimes this this cleaning effect can be seen when exporting from Supervisor so you can attempt an alternative export method to check this.

You can also avoid this by setting up your routings in such a way so that routing changes during field work do not have an impact. 

For example, if you need to change the routing ??Q13?? Has {1 to 10} to remove code 6 from the selection, then the easy way to write the new routing would be: ??Q13?? Has {1 to 5;7 to 10}. However, if you wanted to the routing to be correct in all time frames you would incorporate your track variable and write it as follows:
((??Q13?? Has {1 to 10} AND ??Track??=1) OR (??Q13?? Has {1 to 5;7 to 10} AND ??Track??>=2)).

8. Deletions or incorrect updates:

• Any question, or code, that is deleted will also have its data deleted, even if it is immediately recreated with the same question shortcut or code caption. You can easily check for this by opening your QES file in Access. In the Questionnaire table there is there is a column ‘LibelleCourt’ which lists out all the shortcuts that have been present in the QES file. If a question has been deleted then the EstSupprime column will contain a ‘-1’. 

• Similarly, in the ‘Modalite’ table, you can check all the responses of a particular question (use the CodeQuestion value from the Questionnaire table to filter the selection here). Any response with a ‘-1’ is a response which has been deleted and its data will not be present unless you run some queries to match with the current codes of the question.

• You might have a case where you have created an update to a task (y.qex) from the original x.qex and later a colleague has created an update to a task (z.qex) from the original x.qex (not the latest y.qex) – at this point it is likely that new questions added will fall out of synch with their ids and there be a possibility for data loss. For example, data is present in a backup QES file and not the latest download.

In this case Supervisor will warn you that the last version is not compatible based on the revision histories not matching. You should never ignore this type of message without fully understanding why it is showing and what the implications of your mismatches are.

(Please see https://support.askia.com/hc/en-us/articles/202099982-Compatibility-checks-when-updating-a-survey-on-AskiaField for more information on compatibility warnings). Therefore, if you have missing data you should check the CCA Log to see if an update has ever been made on that Task while ignoring warnings. E.g.

• If you find that update warnings have been ignored, you will need to compare the relevant QES files from the “CCA-backups” directory to check whether any relevant question IDs have become out of synchronisation.

9. If all visible questions data is missing after a certain point pay special attention to Quotafull / Screening added after the respondents completed the survey. If screening criteria are added afterwards and the interview was modified, missing data can appear as the quota string can change.

10. Check the CCA log for relevant CCA issues like CCA restarts, loss of connection or any relevant messages related to this specific task and if any doubts include these when you send a request to support.

11. Check what you believe to be missing data with every colleague involved on the same project to get a second opinion and evaluate changes done over the survey. Any extra info can clear things up. It is easily possible with several people working on one project that a crucial change has not been sufficiently communicated.

NOTE

When interviews are read and saved in “modify interview”, in Supervisor, all logics are executed and data can be deleted (e.g. if you completely change the meaning of a routing during fieldwork). When interview modification is saved Supervisor, it’s also saved in the webinterviews database, so no restoration of a backup possible.

When there are due to be interview modifications, please make a backup data export before making the changes. For example, you could use export methods 2 or 3 here to get a backup.

In general we would ask you keep detailed track of the following changes made in a project’s lifespan:

• Any changes made in modify interview.
• Any changes made by opening the field task in Askia Tools and running edits on the data.
• Time and date of updates to task, especially routing changes.