Difference between revisions of "Iecompdup"

Jump to: navigation, search
Line 42: Line 42:


==Output==
==Output==
After running iecompdup, you will be able to browse the dataset and explore the
The output from '''<code>iecompdup</code>''' allows you to explore the
differences between observations to determine the best way to correct the duplicates.
differences between [[Unit of Observation|observations]] to determine the best way to correct the [[Duplicates and Survey Logs|duplicate values]]. Broadly, there are three cases that can explain why duplicate values in [[ID Variable Properties|ID Variables]] can arise when working with [[SurveyCTO Coding Practices|SurveyCTO]]. Given below are the cases, and information on how '''<code>iecompdup</code>''' can help you identify which of these applies to a particular pair of duplicates. Some details can change if you use a different [[Computer-Assisted Personal Interviews (CAPI)#Software|software]], but the general idea should remain the same. And while '''<code>iecompdup</code>''' can not guarantee any of the cases below, the output will allow you to identify one of these cases as the source of the problem.
We have identified three cases as the main reasons for the occurrence of duplicated
IDs when working with SurveyCTO. The section below lists them and indicates how
iecompdup can be used to identify which of these cases applies to a particular pair
of duplicates. The general picture should be the same even if you are using different
software, but some details might be different. No output from iecompdup can guarantee
any of the cases below, but most of the times the output will still be conclusive for one
of the three cases.


===Case 1:  Same Observation, Same Data===
=== Case 1:  Same observation, same data values ===
This case often occurs with [[Computer-Assisted Personal Interviews (CAPI) | CAPI]] surveys as a consequence of poor internet connection. If a submission is interrupted, then the server still saves that incomplete data; when the server receives a second submission, it saves both submissions since it does not know if the two submissions and the changes made between them were intentional. In <code>iecompdup</code>’s output, this case would appear as very few different variables; the variables that differ would mostly be submission meta data such as submission time or submission ID (called ''KEY'' in SurveyCTO). If no media files (i.e. audio, images, monitoring) were used and only the meta data differs, it does not matter which observation you keep. However, it is good practice to keep the one submitted most recently.
A '''Case 1 error''' occurs when the same observation is submitted twice, with the same data values. This often happens during [[Computer-Assisted Personal Interviews (CAPI) | CAPI]] or [[Computer-Assisted Field Entry (CAFE)|CAFE]] surveys because of poor internet connection. If submission of data to the server is interrupted before you can finish completing all fields, the incomplete data may still be saved. This is because [[SurveyCTO Server Management|SurveyCTO servers]] never delete any data. When you re-submit the data the second time, the server saves that too. However, it cannot identify which submission was intentional, and which one was accidental.  


In most cases, submission interruptions occur because media files did not upload correctly. Those files themselves do not come up as variables in Stata -- only their file names do – and thus, only submission meta data variables differ. The file name variable is submitted even when the file is not. When both duplicates have file name and the same file contents, it does not matter which duplicate you keep. However, it is good practice to keep the one submitted most recently. If only one has the file name, keep that observation.  
Note that in this case, the output of '''<code>iecompdup</code>''' will display two observations with very few differences. These differences will mostly be in the form of '''submission time''' or '''submission ID''' (which '''SurveyCTO''' lists as the '''"KEY"''' variable). Information of this form is called '''metadata'''. Sometimes the only difference between the two observations is in terms of the '''metadata''', and the data does not include any media files (audio, images, monitoring). In such cases it does not matter which observation you keep. However, it is a good practice to keep the most recent submission.


The case may also occur if a duplicate is created on the server. This is very uncommon but in these cases, even some submission data would be the same. In this case, either observation can be dropped.
In most cases, however, submission gets interrupted occur because the data contained media files which did not upload correctly. Those files do not always appear as variables in Stata, depending on the [[Computer-Assisted Personal Interviews#Software|data collection software]]). Even in such cases, only the '''metadata variables''' will appear to be different, so you must carefully check the media files which lie outside the imported data set for duplicate observations.


===Case 2: Same Observation, Modified Data===
===Case 2: Same Observation, Modified Data===

Revision as of 21:15, 8 May 2020

iecompdup is the third command in the Stata package created by DIME Analytics, iefieldkit. The iecompdup command helps the research team identify the reason for why duplicate values for ID variables exist, so they can be resolved. ID variables are variables that uniquely identify every observation in a dataset, for example, household_id.

Read First

  • Stata coding practices.
  • iefieldkit.
  • While ieduplicates identifies duplicates in ID variables, iecompdup provides more information to resolve these issues.
  • To install iecompdup, type ssc install iecompdup in Stata.
  • To install all the commands in the iefieldkit package, type ssc install iefieldkit in Stata.
  • For instructions and available options, type help iecompdup.

Overview

Once ieduplicates creates the duplicate correction template, iecompdup compares the duplicate entries variable-by-variable to understand why the duplicates exist. While the decision of how to correct a duplicate is always a qualitative decision, iecompdup provides the information necessary to make that decision, and ensure high quality data before cleaning and data analysis. It allows the research team to also select the output format based on their decision process.

Follow these steps when using the ieduplicates and iecompdup commands on incoming primary data:

  1. Run ieduplicates on the raw data. If there are no duplicates, you are done. If there are duplicates, the command will output an Excel file containing a duplicates correction template, and a link to this file. It will also stop the code from moving forward, and show a message listing the duplicate values in the ID variables. You can prevent the command from stopping your code by using the force option. This will remove all observations with duplicate ID values and allow the code to continue.
  2. Open the duplicates correction template. This template will list each duplicate entry of the ID variable, and information about each observation. It also contains 5 blank columns - correct, drop, newid, initials, and notes. Use these columns to make corrections, and include comments to document the corrections.
  3. Use iecompdup for more information. Sometimes the template is not enough to solve a particular issue. In such cases, run the iecompdup command on the same dataset.
  4. Overwrite the previous file. After entering all the corrections to the template, save the Excel file in the same location with the same name.
  5. Run ieduplicates again. This will apply the corrections you made in the previous steps. Now if you use the force option, it will only remove those duplicates that you did not resolve.
  6. Do not overwrite the orginal raw data. Save the resulting dataset under a different name.
  7. Repeat these steps with each new round of data.

Syntax

Sometimes when there are a lot of variables that are different for observations with duplicate IDs, ieduplicates cannot store all the information. In such cases, or when there are more than two duplicates, you can use iecompdup to explore the differences.

iecompdup id_varname [if], id(id_value)
   [more2ok didifference keepdifference keepother(varlist)]

The following points provide a detailed explanation of the syntax and usage of iecompdup.

  • Basic inputs: iecompdup uses id_varname and id_value as its basic inputs:
    • id_varname: The name of the unique ID variable, which is also used with ieduplicates.
    • id_value: This is the value that the ID variable takes in the duplicate observations you want to compare. For example, if the household with the ID value A1234 appears twice, then id_varname is household_id, and id_value is A1234.
  • More than one pair of duplicates: If you have more than one pair of duplicates in your dataset, you will need to run this command multiple times for each such pair to compare the differences.
  • More than two observations with same id_value: If there are more than two observations with a particular ID value, the command will return an error. This is because iecompdup can only be compare two duplicates at a time. In this case, use on of the following options:
    • if: Using if allows you to select the pair of observations you want to compare.
    • more2ok: Using more2ok allows iecompdup to pick the first two observations by default, as per the sort order. It will then display a warning message so that the user is aware that the sorting order of observations will affect the result.
  • Default output: By default, iecompdup displays two lists of variables in the form of macros - one, variables for which the duplicate pair has identical values, and two, variables for which the duplicate pair has different values. iecompdup also provides the following options with respect to these lists:
    • didifference: This option will also make the command print the list of variables with different values.
    • keepdifference: This option will only keep the variables which have different values across the duplicate pair. This option effectively drops variables which are not of interest.
    • keepother: This option can be used if you want to retain additional variables that you think are useful for analyzing the duplicate pair.

Output

The output from iecompdup allows you to explore the differences between observations to determine the best way to correct the duplicate values. Broadly, there are three cases that can explain why duplicate values in ID Variables can arise when working with SurveyCTO. Given below are the cases, and information on how iecompdup can help you identify which of these applies to a particular pair of duplicates. Some details can change if you use a different software, but the general idea should remain the same. And while iecompdup can not guarantee any of the cases below, the output will allow you to identify one of these cases as the source of the problem.

Case 1: Same observation, same data values

A Case 1 error occurs when the same observation is submitted twice, with the same data values. This often happens during CAPI or CAFE surveys because of poor internet connection. If submission of data to the server is interrupted before you can finish completing all fields, the incomplete data may still be saved. This is because SurveyCTO servers never delete any data. When you re-submit the data the second time, the server saves that too. However, it cannot identify which submission was intentional, and which one was accidental.

Note that in this case, the output of iecompdup will display two observations with very few differences. These differences will mostly be in the form of submission time or submission ID (which SurveyCTO lists as the "KEY" variable). Information of this form is called metadata. Sometimes the only difference between the two observations is in terms of the metadata, and the data does not include any media files (audio, images, monitoring). In such cases it does not matter which observation you keep. However, it is a good practice to keep the most recent submission.

In most cases, however, submission gets interrupted occur because the data contained media files which did not upload correctly. Those files do not always appear as variables in Stata, depending on the data collection software). Even in such cases, only the metadata variables will appear to be different, so you must carefully check the media files which lie outside the imported data set for duplicate observations.

Case 2: Same Observation, Modified Data

This case is rare but possible in most data collection software. This occurs if an observation is modified after the first submission and then re-submitted. Sometimes it is necessary to modify already-submitted data, though in these cases, it is best practice to do so in a do-file to ensure proper documentation. In iecompdup’s output, this case would show up as the submission meta data differing and some observation data differing. Look into these cases closely and follow up with the enumerators and supervisors responsible for this submission. There is no clear rule on which observation to keep: you have to make that decision yourself. Remember that this case is rare since most survey software has systems to prevent this.

Case 3: Incorrectly Assigned ID

The case occurs when the same ID is used for two different respondents. This may happen due to typos or to unfollowed protocols. In iecompdup’s output, this case would show up as submission data differing as well as a lot of observation data differing. Follow up with enumerators and supervisors responsible for this submission and assign a new ID to one of the observations based on your findings.

Back to Parent

This article is part of the topic ietoolkit

Additional Resources