This page provides information and answers to frequent questions we receive from users.
- Can I substantively change an indicator?
- My map is out of date. How do I update it?
- Should I add unknown as a disaggregation category?
- Can I add or edit disaggregation categories?
No. Any substantive change to an indicator's definition will require creating a new indicator. Substantive changes include any revisions to:
- Data Source
- Indicator Type
- Reporting Level
- "Results are reported separately for each activity"
DevResults generally acquires maps for your country or countries from the publicly available files at gadm.org. If the information we have provided is inaccurate or out of date, it is your responsibility to provide the .kml or shape files with the information you want to use on your site.
Your team would need to provide any set of KML files or shape files that contain the correct administrative divisions for which you need to report indicator results. Please see more information about KML files.
There are a few circumstances in which we could address this issue without needing new maps:
- If your lowest level of administrative divisions (smallest shapes) is the only incorrect level, and you do not intend to report data at that level, we can just delete it.
- If any administrative division levels are incorrect but you don't need to report data for each division (say, you report data for larger geographic areas or smaller ones, like facilities), AND you don't need to view results aggregated by that level, then again, we could just delete that level and all other tools would work fine.
- If the lowest level is incorrect and you would like to treat those places as points on a map instead of shapes, this would also work with all DevResults features, IF you do not intend to report data for any smaller entities, like cities or facilities.
This is up to you and the way your organization collects data. In cases where you have several teams reporting on a single indicator despite not sharing the same disaggregations, adding an "unknown" category would help capture detailed information where it's available.
E.G: Every project reports on # people trained, but not everyone captures the information disaggregated by gender.
Unlike deleting disaggregations or disaggregation categories (which will delete associated data), DevResults will allow you to add new categories to an existing disaggregation, as well as edit the name of an existing disaggregation category. However, care must be taken to avoid changing the nature of the indicator or the definition of the data. Whether a change is methodologically valid depends on how you've defined your categories in documentation and in practice.
For instance, if you had a disaggregation for age with categories named '<18' and '18+', you could change the names to 'Youth' and 'Adults' respectively, assuming that you've clearly defined 18 years of age as the threshold of adulthood. All of the data previously associated with the '18+' category would now be associated with the 'Adults' category.
Similarly, if you disaggregate your training participants by the type of trainings you offer — e.g. 'finance', 'administration', 'advocacy' — and you intend to begin offering a completely new training — 'data collection' — there's no risk that any of the previous training participants would have ever completed this newly available training, and so your data integrity is maintained.
However, if you disaggregate "Household size" by the categories "1, 2, 3, 4+" and decide that going forward you want to add more granularity by using additional categories such as "1, 2, 3, 4, 5, 6+," you would be making a fundamental change to the original '4+' category. DevResults will allow you to make this change, but you must either re-enter data for all '4+' households to ensure accuracy, or create a new indicator with a new disaggregation to collect more granular data going forward.
Didn't answer your question? Please email us at firstname.lastname@example.org.