├── README.md └── translations └── français.md /README.md: -------------------------------------------------------------------------------- 1 | # The Quartz guide to bad data 2 | 3 | **An exhaustive reference to problems seen in real-world data along with suggestions on how to resolve them.** 4 | 5 | As a reporter your world is full of data. And those data are full of problems. This guide presents thorough descriptions and suggested solutions to many of the kinds of problems that you will encounter when working with data. 6 | 7 | Most of these problems can be solved. Some of them can't be solved and that means you should not use the data. Others can't be solved, but with precautions you can continue using the data. In order to allow for these ambiguities, this guide is organized by who is best equipped to solve the problem: you, your source, an expert, etc. In the description of each problem you may also find suggestions for what to do if that person can't help you. 8 | 9 | You cannot possibly review every dataset you encounter for all of these problems. If you try to do that you will never get anything published. However, by familiarizing yourself with the kinds of issues you are likely to encounter you will have a better chance of identifying an issue before it causes you to make a mistake. 10 | 11 | If you have questions about this guide please email [Chris](mailto:chrisgroskopf@gmail.com). Good luck! 12 | 13 | This work is licensed under a [Creative Commons Attribution-NonCommercial 4.0 International License](http://creativecommons.org/licenses/by-nc/4.0/). Send your pull requests! 14 | 15 | # Translations 16 | 17 | * [Chinese](https://web.archive.org/web/20170627153730/http://djchina.org/2016/07/12/bad_data_guide/) (complete) 18 | * [Chinese](http://cn.gijn.org/2016/01/10/quartz%E5%9D%8F%E6%95%B0%E6%8D%AE%E6%8C%87%E5%8D%97%E7%B2%BE%E9%80%89%EF%BC%9A%E5%A4%84%E7%90%86%E6%95%B0%E6%8D%AE%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%96%B9%E5%BC%8F%E4%B8%80%E8%A7%88/) (partial) 19 | * [Japanese](https://github.com/piyo-ko/bad-data-guide/blob/master/README_ja.md) 20 | * [Portuguese](http://escoladedados.org/2016/09/08/guia-quartz-para-limpeza-de-dados/) 21 | * [Spanish](http://es.schoolofdata.org/guia-quartz/) 22 | 23 | Want to translate this guide into your language? Go ahead! Email [Chris](mailto:chrisgroskopf@gmail.com) to have your translation added here. 24 | 25 | # Index 26 | 27 | ## Issues that your source should solve 28 | 29 | * [Values are missing](#values-are-missing) 30 | * [Zeros replace missing values](#zeros-replace-missing-values) 31 | * [Data are missing you know should be there](#data-are-missing-you-know-should-be-there) 32 | * [Rows or values are duplicated](#rows-or-values-are-duplicated) 33 | * [Spelling is inconsistent](#spelling-is-inconsistent) 34 | * [Name order is inconsistent](#name-order-is-inconsistent) 35 | * [Date formats are inconsistent](#date-formats-are-inconsistent) 36 | * [Units are not specified](#units-are-not-specified) 37 | * [Categories are badly chosen](#categories-are-badly-chosen) 38 | * [Field names are ambiguous](#field-names-are-ambiguous) 39 | * [Provenance is not documented](#provenance-is-not-documented) 40 | * [Suspicious values are present](#suspicious-values-are-present) 41 | * [Data are too coarse](#data-are-too-coarse) 42 | * [Totals differ from published aggregates](#totals-differ-from-published-aggregates) 43 | * [Spreadsheet has 65536 rows](#spreadsheet-has-65536-rows) 44 | * [Spreadsheet has 255 columns](#spreadsheet-has-255-columns) 45 | * [Spreadsheet has dates in 1900, 1904, 1969, or 1970](#spreadsheet-has-dates-in-1900-1904-1969-or-1970) 46 | * [Text has been converted to numbers](#text-has-been-converted-to-numbers) 47 | * [Numbers have been stored as text](#numbers-have-been-stored-as-text) 48 | 49 | ## Issues that you should solve 50 | 51 | * [Text is garbled](#text-is-garbled) 52 | * [Line endings are garbled](#line-endings-are-garbled) 53 | * [Data are in a PDF](#data-are-in-a-pdf) 54 | * [Data are too granular](#data-are-too-granular) 55 | * [Data were entered by humans](#data-were-entered-by-humans) 56 | * [Data are intermingled with formatting and annotations](#data-are-intermingled-with-formatting-and-annotations) 57 | * [Aggregations were computed on missing values](#aggregations-were-computed-on-missing-values) 58 | * [Sample is not random](#sample-is-not-random) 59 | * [Margin-of-error is too large](#margin-of-error-is-too-large) 60 | * [Margin-of-error is unknown](#margin-of-error-is-unknown) 61 | * [Sample is biased](#sample-is-biased) 62 | * [Data have been manually edited](#data-have-been-manually-edited) 63 | * [Inflation skews the data](#inflation-skews-the-data) 64 | * [Natural/seasonal variation skews the data](#naturalseasonal-variation-skews-the-data) 65 | * [Timeframe has been manipulated](#timeframe-has-been-manipulated) 66 | * [Frame of reference has been manipulated](#frame-of-reference-has-been-manipulated) 67 | 68 | ## Issues a third-party expert should help you solve 69 | 70 | * [Author is untrustworthy](#author-is-untrustworthy) 71 | * [Collection process is opaque](#collection-process-is-opaque) 72 | * [Data assert unrealistic precision](#data-assert-unrealistic-precision) 73 | * [There are inexplicable outliers](#there-are-inexplicable-outliers) 74 | * [An index masks underlying variation](#an-index-masks-underlying-variation) 75 | * [Results have been p-hacked](#results-have-been-p-hacked) 76 | * [Benford's Law fails](#benfords-law-fails) 77 | * [Too good to be true](#too-good-to-be-true) 78 | 79 | ## Issues a programmer should help you solve 80 | 81 | * [Data are aggregated to the wrong categories or geographies](#data-are-aggregated-to-the-wrong-categories-or-geographies) 82 | * [Data are in scanned documents](#data-are-in-scanned-documents) 83 | 84 | # Detailed list of all problems 85 | 86 | ## Issues that your source should solve 87 | 88 | ### Values are missing 89 | 90 | Beware blank or "null" values in any dataset unless you are certain you know what they mean. If the data are annual, was the value for that year never collected? If it is a survey, did a respondent refuse to answer the question? 91 | 92 | Any time you're working with data that has missing values you should ask yourself: "Do I know what the absence of this value means?" If the answer is no, you should ask your source. 93 | 94 | ### Zeros replace missing values 95 | 96 | Worse than a missing value is when an arbitrary value is used instead. This can be the result of a human not thinking through the implications or it can happen as the result of automated processes that simply don't know how to handle null values. In any case, if you see zeros in a series of numbers you should ask yourself if those values are really the number `0` or if they instead mean "nothing". (`-1` is also sometimes used this way.) If you aren't sure, ask your source. 97 | 98 | The same caution should be exercised for other non-numerical values where a `0` may be represented in another way. For example a false `0` value for a date is often displayed as `1970-01-01T00:00:00Z` or `1969-12-31T23:59:59Z` which is the [Unix epoch for timestamps](https://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number). A false `0` for a location might be represented as `0°00'00.0"N+0°00'00.0"E` or simply `0°N 0°E` which is a point in the Atlantic Ocean just south of Ghana often referred to as [Null Island](https://en.wikipedia.org/wiki/Null_Island). 99 | 100 | See also: 101 | 102 | * [Suspicious values are present](#suspicious-values-are-present) 103 | * [Spreadsheet has dates in 1900, 1904, 1969, or 1970](#spreadsheet-has-dates-in-1900-1904-1969-or-1970) 104 | 105 | ### Data are missing you know should be there 106 | 107 | Sometimes data are missing and you can't tell from the dataset itself, but you can still know because you know what the data purports to be about. If you have a dataset covering the United States then you can check to ensure all 50 states are represented. (And don't forget about [the territories](https://en.wikipedia.org/wiki/Territories_of_the_United_States)—50 isn't the right number if the dataset includes Puerto Rico.) If you're dealing with a dataset of baseball players make sure it has the number of teams you expect. Verify that a few players who you know are included. Trust your intuition if something seems to be missing and double-check with your source. The universe of your data might be smaller than you think. 108 | 109 | ### Rows or values are duplicated 110 | 111 | If the same row appears in your dataset more than once you should find out why. Sometimes it need not be a whole row. Some campaign finance data include "amendments" that use the same unique identifiers as the original transaction. If you didn't know that then any calculations you did with the data would be wrong. If something seems like it should be unique verify that it is. If you discover that it isn't, ask your source why. 112 | 113 | ### Spelling is inconsistent 114 | 115 | Spelling is one of the most obvious ways of telling if data have been compiled by hand. Don't just look at people's names—those are often the hardest place to detect spelling errors. Instead look for places where city names or states aren't consistent. (`Los Angelos` is one very common mistake.) If you find those, you can be pretty sure the data were compiled or edited by hand and that is always a reason to be skeptical of it. Data that have been edited by hand are the most likely to have mistakes. This doesn't mean you shouldn't use them but you may need to manually correct those mistakes or otherwise account for them in your reporting. 116 | 117 | [OpenRefine's](http://openrefine.org/) utility for [text clustering](https://github.com/OpenRefine/OpenRefine/wiki/Clustering) can help streamline the spelling correction process by suggesting close matches between inconsistent values within a column (for example, matching `Los Angelos` and `Los Angeles`). Be sure, however, to [document the changes you make](https://github.com/OpenRefine/OpenRefine/wiki/Exporters) so as to ensure [good data provenance](#provenance-is-not-documented). 118 | 119 | See also: 120 | 121 | * [Data were entered by humans](#data-were-entered-by-humans) 122 | 123 | ### Name order is inconsistent 124 | 125 | Does your data have Middle Eastern or East Asian names in it? Are you sure the surnames are always in the same place? Is it possible anyone in your dataset [uses a mononym](https://en.wikipedia.org/wiki/Indonesian_names#Indonesian_naming_system)? These are the sorts of things that data makers habitually get wrong. If you're working with a list of ethnically diverse names—which is any list of names—then you should do at least a cursory review before assuming that joining the `first_name` and `last_name` columns will give you something that is appropriate to publish. 126 | 127 | * [Data were entered by humans](#data-were-entered-by-humans) 128 | 129 | ### Date formats are inconsistent 130 | 131 | Which date is in September: 132 | 133 | * `10/9/15` 134 | * `9/10/15` 135 | 136 | If the first one was written by a European and the second one by an American [then they both are](https://en.wikipedia.org/wiki/Date_format_by_country). Without knowing the history of the data you can't know for sure. Know where your data came from and be sure that it was all created by folks from the same continent. 137 | 138 | * [Data were entered by humans](#data-were-entered-by-humans) 139 | * [Provenance is not documented](#provenance-is-not-documented) 140 | 141 | ### Units are not specified 142 | 143 | Neither `weight` nor `cost` conveys any information about the unit of measurement. Don't be too quick to assume that data produced within the United States are in units of pounds and dollars. Scientific data are often metric. Foreign prices may be specified in their local currency. If the data do not spell out their units, go back to your source and find out. Even if it does spell out its units always be wary of meanings that may have shifted over time. A dollar in 2010 is not a dollar today. And a [ton](https://en.wikipedia.org/wiki/Short_ton) is not a [ton](https://en.wikipedia.org/wiki/Long_ton) nor a [tonne](https://en.wikipedia.org/wiki/Tonne). 144 | 145 | See also: 146 | 147 | * [Field names are ambiguous](#field-names-are-ambiguous) 148 | * [Inflation skews the data](#inflation-skews-the-data) 149 | 150 | ### Categories are badly chosen 151 | 152 | Watch out for values which purport to be only `true` or `false`, but really aren't. This is often the case with surveys where `refused` or `no answer` are also valid—and meaningful—values. Another common problem is the usage of any kind of `other` category. If the categories in a dataset are a bunch of countries and an `other`, what does that mean? Does it mean that the person collecting the data didn't know the right answer? Were they in international waters? Expatriates? Refugees? 153 | 154 | Bad categories can also artificially exclude data. This frequently happens with crime statistics. The FBI has defined the crime of "rape" in a variety of different ways over time. In fact, they've done such a poor job of figuring out what rape is that many criminologists argue their statistics should not be used at all. A bad definition might mean a crime is counted in a different category than you expect or that it wasn't counted at all. Be exceptionally ware of this problem when working with topics where definitions tend to be arbitrary, such as `race` or `ethnicity`. 155 | 156 | ### Field names are ambiguous 157 | 158 | What is a `residence`? Is it where someone lives or where they pay taxes? Is it a city or a county? Field names in data are never as specific as we would like, but particular concern should be applied to those that could obviously mean two or more things. Even if you correctly infer what the values are supposed to mean, that ambiguity could have easily caused the person collecting the data to enter the wrong value. 159 | 160 | ### Provenance is not documented 161 | 162 | Data are created by a variety of kinds of individuals and organizations including businesses, governments, nonprofits and nut-job conspiracy theorists. Data are gathered in many different ways including surveys, sensors and satellites. It may be typed, tapped or scribbled. Knowing where your data came from can give you a huge amount of insight into its limitations. 163 | 164 | Survey data, for example, is rarely exhaustive. Sensors vary in their accuracy. Governments are often disinclined to give you unbiased information. Data from a war zone may have a strong geographical bias due to the danger of crossing battle lines. To make this situation worse, these different sources are often daisy-chained together. Policy analysts frequently redistribute data they got from the government. Data that were written by a doctor may be keyed by a nurse. Every stage in that chain is an opportunity for error. Know where your data came from. 165 | 166 | See also: 167 | 168 | * [Units are not specified](#units-are-not-specified) 169 | 170 | ### Suspicious values are present 171 | 172 | If you see any of these values in your data, treat them with an abundance of caution: 173 | 174 | Numbers: 175 | 176 | * [`65,535`](https://en.wikipedia.org/wiki/65535_%28number%29) 177 | * [`255`](https://en.wikipedia.org/wiki/255_%28number%29) 178 | * [`2,147,483,647`](https://en.wikipedia.org/wiki/2147483647_%28number%29) 179 | * [`4,294,967,295`](https://en.wikipedia.org/wiki/4294967295) 180 | * [`555-3485`](https://en.wikipedia.org/wiki/555_%28telephone_number%29) 181 | * `99999` (or any other long sequence of 9's) 182 | * `00000` (or any other sequence of 0's) 183 | 184 | Dates: 185 | 186 | * [`1970-01-01T00:00:00Z`](https://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number) 187 | * [`1969-12-31T23:59:59Z`](https://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number) 188 | * [`January 1st, 1900`](#spreadsheet-has-dates-in-1900-1904-1969-or-1970) 189 | * [`January 1st, 1904`](#spreadsheet-has-dates-in-1900-1904-1969-or-1970) 190 | 191 | Locations: 192 | 193 | * [`0°00'00.0"N+0°00'00.0"E`](https://en.wikipedia.org/wiki/Null_Island) or simply [`0°N 0°E`](https://en.wikipedia.org/wiki/Null_Island) 194 | * US zip code `12345` (Schenectady, New York) 195 | * US zip code `90210` (Beverly Hills, CA) 196 | 197 | Each of these numbers has an indication of a particular error made by either a human or a computer. If you see them, ensure they actually mean what you think they mean! 198 | 199 | See also: 200 | 201 | * [Spreadsheet has 65536 rows](#spreadsheet-has-65536-rows) 202 | * [Spreadsheet has 255 columns](#spreadsheet-has-255-columns) 203 | * [Spreadsheet has dates in 1900 or 1904](#spreadsheet-has-dates-in-1900-or-1904) 204 | 205 | ### Data are too coarse 206 | 207 | You've got states and you need counties. You've got employers and you need employees. They gave you years, but you want months. In many cases we get data that have been aggregated too much for our purposes. 208 | 209 | Data usually cannot be disaggregated once they have been merged together. If you're given data that are too coarse, you'll need to ask your source for something more specific. They may not have it. If they do have it they may not be able or willing to give it to you. There are many federal datasets that can't be accessed at the local level to protect the privacy of individuals who might be uniquely identified by them. (For example, a single Somali national living in western Texas.) All you can do is ask. 210 | 211 | One thing you should never ever do is divide a yearly value by 12 and call it the "average per month". Without knowing the distribution of the values, that number will be meaningless. (Maybe all instances occurred in one month or one season. Maybe the data follows an exponential trend instead of a linear one.) It's wrong. Don't do it. 212 | 213 | See also: 214 | 215 | * [Data are too granular](#data-are-too-granular) 216 | * [Data are aggregated to the wrong categories or geographies](#data-are-aggregated-to-the-wrong-categories-or-geographies) 217 | 218 | ### Totals differ from published aggregates 219 | 220 | Imagine that after a long FOIA fight you receive a "complete" list of incidents of police use-of-force. You open it up and discover it has 2,467 rows. Great, time to report it out. Not so fast. Before you publish anything from that dataset go find the last time that police chief went on the record about his department's use of force. You may find that in an interview six weeks earlier he said "less than 2,000 times" or that he named a specific number and it doesn't match your dataset. 221 | 222 | These sorts of discrepancies between published statistics and raw data can be a very great source of leads. Often the answer will be simple. For instance, the data you were given may not cover the same time period he was speaking about. But sometimes you'll catch them in a lie. Either way, you should make sure the published numbers match the totals for the data you're given. 223 | 224 | ### Spreadsheet has 65536 rows 225 | 226 | The maximum number of rows an old-fashioned Excel spreadsheet was allowed to have was 65,536. If you receive a dataset with that number of rows you have almost certainly been given truncated data. Go back and ask for the rest. Newer versions of Excel allowed for 1,048,576 rows, so it's less likely you'll be working with data that hits the limit. 227 | 228 | ### Spreadsheet has 255 columns 229 | 230 | Apple's Numbers app can only handle spreadsheets with 255 columns, and the app will truncate files that have more columns without warning the user. If you receive a dataset with exactly 255 columns, ask if the file was ever opened or converted with Numbers. 231 | 232 | ### Spreadsheet has dates in 1900, 1904, 1969, or 1970 233 | 234 | For reasons beyond obscure, Excel's default date from which it counts all other dates is `January 1st, 1900`, *unless* you're using Excel on a Mac, in which case it's `January 1st, 1904`. There are a variety of ways in which data in Excel can be entered or calculated incorrectly and end up as one of these two dates. If you spot them in your data, it's probably an issue. 235 | 236 | Many databases and applications will often generate a date of `1970-01-01T00:00:00Z` or `1969-12-31T23:59:59Z` which is the [Unix epoch for timestamps](https://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number). In other words this is what happens when a system tries to display an empty value or a `0` value as a date. 237 | 238 | ### Text has been converted to numbers 239 | 240 | Not all numerals are numbers. For instance, the US Census Bureau uses "FIPS codes" to identify every place in the United States. These codes are of various lengths and are numeric. However, they are *not* numbers. `037` is the FIPS code for Los Angeles County. It is not the number `37`. The numerals `37` are, however, a valid FIPS code: for North Carolina. Excel and other spreadsheets will often make the mistake of assuming numerals are numbers and stripping the leading zeros. This can cause all kinds of problems if you try to convert it to another file format or merge it with another dataset. Watch out for data where this has happened before it was given to you. 241 | 242 | ### Numbers have been stored as text 243 | 244 | When working with spreadsheets, numbers may be stored as text with unwanted formatting. This often happens when a spreadsheet is optimized for presenting data rather than making it available for re-use. For example, instead of representing a million dollars with the number "1000000" a cell might contain the string "1,000,000" or "1 000 000" or "USD 1,000,000" with the formatting of commas, units and spaces entered as characters. Excel can take care of some simple cases with built-in functions, but you'll often need to use formulas to strip out characters until cells are clean enough to be recognized as numbers. Good practice is to store numbers without formatting and to include supporting information in column names or metadata. 245 | 246 | ## Issues that you should solve 247 | 248 | ### Text is garbled 249 | 250 | All letters are represented by computers as numbers. Encoding problems are issues that arise when text is represented by a specific set of numbers (called an "encoding") and you don't know what it is. This leads to a phenomenon called [mojibake](https://en.wikipedia.org/wiki/Mojibake) where the text in your data looks like garbage, or like this: ���. 251 | 252 | In the vast majority of cases your text editor or spreadsheet application will figure out the correct encoding, however, if it screws it up you could be publishing somebody's name with a weird character in the middle. Your source should be able to tell you what encoding your data are in. In the event they can't there are ways of guessing that are about fairly reliable. Ask a programmer. 253 | 254 | ### Line endings are garbled 255 | 256 | All text and "text data" files, such as CSV, use invisible characters to represent the ends of lines. Windows, Mac and Linux computers have historically disagreed about what these line ending characters should be. Attempting to open a file saved on one operating system from another operating system can sometimes cause Excel or other applications to fail to properly identify the line breaks. 257 | 258 | Typically, this is easy to resolve by simply opening the file in any general-purpose text editor and re-saving it. If the file is exceptionally large you may need to consider using a command-line tool or enlisting the help of a programmer. You can read more about this issue [here](https://nicercode.github.io/blog/2013-04-30-excel-and-line-endings/). 259 | 260 | ### Data are in a PDF 261 | 262 | A tremendous amount of data—especially government data—are only available in PDF format. If you have real, textual data inside the PDF then there are several good options for extracting them. (If you've got [scanned documents](#data-are-in-scanned-documents) that's a different problem.) One excellent, free tool is [Tabula](http://tabula.technology/). However, if you have Adobe Creative Cloud then you also have access to Acrobat Pro, which has an excellent feature for exporting tables in PDFs to Excel. Either solution should be able to extract most tabular data from a PDF. 263 | 264 | See also: 265 | 266 | * [Data are in scanned documents](#data-are-in-scanned-documents) 267 | 268 | ### Data are too granular 269 | 270 | This is the opposite of [Data are too coarse](#data-are-too-coarse). In this case you've got counties, but you want states or you've got months but you want years. Fortunately this is usually pretty straightforward. 271 | 272 | Data can be aggregated by using the Pivot Table feature of Excel or Google Docs, by using a SQL database or by writing custom code. Pivot Tables are a fabulous tool that every reporter should learn, but they do have their limits. For exceptionally large datasets or aggregations to unusual groups you should ask a programmer and they can craft a solution that's easier to verify and reuse. 273 | 274 | See also: 275 | 276 | * [Data are too coarse](#data-are-too-coarse) 277 | * [Data are aggregated to the wrong categories or geographies](#data-are-aggregated-to-the-wrong-categories-or-geographies). 278 | 279 | ### Data were entered by humans 280 | 281 | Human data entry is such a common problem that symptoms of it are mentioned in at least 10 of the other issues described here. There is no worse way to screw up data than to let a single human type it in, without validation. For example, I once acquired the complete dog licensing database for Cook County, Illinois. Instead of requiring the person registering their dog to choose a breed from a list, the creators of the system had simply given them a text field to type into. As a result this database contained at least 250 spellings of `Chihuahua`. Even with the best tools available, data this messy can't be saved. They are effectively meaningless. This is not that important with dog data, but you don't want it happening with wounded soldiers or stock tickers. Beware human-entered data. 282 | 283 | ### Data are intermingled with formatting and annotations 284 | 285 | Complex representations of data such as HTML and XML allow for a clean separation between data and formatting, but this is not the case for common tabular representations of data such as a spreadsheet. Yet, people still try. A common problem with data provided as a spreadsheet is that the first few rows of data will actually be descriptions or notes about the data rather than column headings or data itself. A key or data dictionary may also be placed in the middle of the spreadsheet. Header rows may be repeated. Or the spreadsheet will include multiple tables (which may have different column headings) one after the other in the same sheet rather than separated into different sheets. 286 | 287 | In all of these cases the main solution is simply to identify the problem. Obviously trying to perform any analysis on a spreadsheet that has these kinds of problems will fail, sometimes for non-obvious reasons. When looking at new data for the first time it's always a good idea to ensure there aren't extra header rows or other formatting characters inserted amongst the data. 288 | 289 | ### Aggregations were computed on missing values 290 | 291 | Imagine a dataset with 100 rows and a column called `cost`. In 50 of the rows the `cost` column is blank. What is the average of that column? Is it `sum_of_cost / 50` or `sum_of_cost / 100`? There is no one definitive answer. In general, if you're going to compute aggregates on columns that are missing data, you can safely do so by filtering out the missing rows first, but be careful not to compare aggregates from two different columns where different rows were missing values! In some cases the missing values might also be legitimately interpreted as `0`. If you're not sure, ask an expert or just don't do it. 292 | 293 | This is an error you can make in your analysis, but it's also an error that others can make and pass on to you, so watch out for it if data comes to you with aggregates already computed. 294 | 295 | See also: 296 | 297 | * [Values are missing](#values-are-missing) 298 | * [Zeros replace missing values](#zeros-replace-missing-values) 299 | 300 | ### Sample is not random 301 | 302 | A non-random sampling error occurs when a survey or other sampled dataset either intentionally or accidentally fails to cover the entire population. This can happen for a variety of reasons ranging from time-of-day to the respondent's native language and is a common source of error in sociological research. It can also happen for less obvious reasons, such as when a researcher thinks they have a complete dataset and chooses to work with only part of it. If the original dataset was incomplete for any reason then any conclusions drawn from their sample will be incorrect. The only thing you can do to fix a non-random sample is avoid using that data. 303 | 304 | See also: 305 | 306 | * [Sample is biased](#sample-is-biased) 307 | 308 | ### Margin-of-error is too large 309 | 310 | I know of no other single issue that causes more reporting errors than the unreflective usage of numbers with very large margins-of-error. MOE is usually associated with survey data. The most likely place a reporter encounters it is when using polling data or the US Census Bureau's [American Community Survey](https://www.census.gov/programs-surveys/acs/) data. The MOE is a measure of the range of possible true values. It may be expressed as a number (`400 +/- 80`) or as a percentage of the whole (`400 +/- 20%`). The smaller the relevant population, the larger the MOE will be. For example, according to the 2014 5-year ACS estimates, the number of Asians living in New York is `1,106,989 +/- 3,526` (0.3%). The number of Filipinos is `71,969 +/- 3,088` (4.3%). The number of Samoans is `203 +/- 144` (71%). 311 | 312 | The first two numbers are safe to report. The third number should never be used in published reporting. There is no one rule about when a number is not accurate enough to use, but as a rule of thumb, you should be cautious about using any number with a MOE over 10%. 313 | 314 | See also: 315 | 316 | * [Margin-of-error is unknown](#margin-of-error-is-unknown) 317 | 318 | ### Margin-of-error is unknown 319 | 320 | Sometimes the problem isn't that the margin of error is [too large](#margin-of-error-is-too-large), it's that nobody ever bothered to figure out what it was in the first place. This is one problem with unscientific polls. Without computing a MOE, it is impossible to know how accurate the results are. As a general rule, anytime you have data that are from a survey you should ask for what the MOE is. If the source can't tell you, those data probably aren't worth using for any serious analysis. 321 | 322 | See also: 323 | 324 | * [Margin-of-error is too large](#margin-of-error-is-too-large) 325 | 326 | ### Sample is biased 327 | 328 | Like [a sample that is not random](#sample-is-not-random), a biased sample results from a lack of care with how the sampling is executed. Or, from willfully misrepresenting it. A sample might be biased because it was conducted on the internet and poorer people don't use the internet as frequently as the rich. Surveys must be carefully weighted to ensure they cover proportional segments of any population that could skew the results. It's almost impossible to do this perfectly so it is often done wrong. 329 | 330 | See also: 331 | 332 | * [Sample is not random](#sample-is-not-random) 333 | 334 | ### Data have been manually edited 335 | 336 | Manual editing is almost the same problem as [data being entered by humans](#data-were-entered-by-humans) except that it happens after the fact. In fact, data are often manually edited in an attempt to fix data that were originally entered by humans. Problems start to creep in when the person doing the editing doesn't have complete knowledge of the original data. I once saw someone spontaneously "correct" a name in a dataset from `Smit` to `Smith`. Was that person's name really `Smith`? I don't know, but I do know that value is now a problem. Without a record of that change, it's impossible to verify what it should be. 337 | 338 | Issues with manual editing are one reason why you always want to ensure your data have [well-documented provenance](#provenance-is-not-documented). A lack of provenance can be a good indication that someone may have monkeyed with it. Academics and policy analysts often get data from the government, monkey with them and then redistribute them to journalists. Without any record of their changes it's impossible to know if the changes they made were justified. Whenever feasible always try to get the *primary source* or at least the earliest version you can and then do your own analysis from that. 339 | 340 | See also: 341 | 342 | * [Provenance is not documented](#provenance-is-not-documented) 343 | * [Data were entered by humans](#data-were-entered-by-humans) 344 | 345 | ### Inflation skews the data 346 | 347 | Currency inflation means that over time money changes in value. There is no way to tell if numbers have been "inflation adjusted" just by looking at them. If you get data and you aren't sure if they have been adjusted then check with your source. If they haven't you'll likely want to perform the adjustment. This [inflation adjuster](http://inflation-adjust.herokuapp.com/) is a good place to start. 348 | 349 | See also: 350 | 351 | * [Natural/seasonal variation skews the data](#nationalseasonal-variation-skews-the-data) 352 | 353 | ### Natural/seasonal variation skews the data 354 | 355 | Many types of data fluctuate naturally due to some underlying forces. The best known example of this is employment fluctuating with the seasons. Economists have developed a variety of methods of compensating for this variation. The details of those methods aren't particularly important, but it is important that you know if the data you're using have been "seasonally adjusted". If they haven't and you want to compare employment from month to month you will probably want to get adjusted data from your source. (Adjusting them yourself is much harder than with inflation.) 356 | 357 | See also: 358 | 359 | * [Inflation skews the data](#inflation-skews-the-data) 360 | 361 | ### Timeframe has been manipulated 362 | 363 | A source can accidentally or intentionally misrepresent the world by giving you data that stops or starts at a specific time. For a potent example see 2015's widely reported "national crime wave". There was no crime wave. What there was was a series of spikes in particular cities when compared to just the last few years. Had journalists examined a wider timeframe they would have seen that violent crime was higher virtually everywhere in the US ten years before. And twenty years before it was nearly double. 364 | 365 | If you have data that covers a limited timeframe try to avoid starting your calculations with the very first time period you have data for. If you start a few years (or months or days) into the data you can have confidence that you aren't making a comparison which would be invalidated by having a single additional data point. 366 | 367 | See also: 368 | 369 | * [Frame of reference has been manipulated](#frame-of-reference-has-been-manipulated) 370 | 371 | ### Frame of reference has been manipulated 372 | 373 | Crime statistics are often manipulated for political purposes by comparing to a year when crime was very high. This can be expressed either as a change (down `60%` since 2004) or via an index (`40`, where 2004 = 100). In either of these cases, 2004 may or may not be an appropriate year for comparison. It could have been an unusually high crime year. 374 | 375 | This also happens when comparing places. If I want to make one country look bad, I simply express the data about it relative to whichever country is doing the best. 376 | 377 | This problem tends to crop up in subjects where people have a strong confirmation bias. ("Just as I thought, crime is up!") Whenever possible try comparing rates from several different starting points to see how the numbers shift. And whatever you do, *don't use this technique yourself* to make a point you think is important. That's inexcusable. 378 | 379 | See also: 380 | 381 | * [Timeframe has been manipulated](#timeframe-has-been-manipulated) 382 | 383 | ## Issues a third-party expert should help you solve 384 | 385 | ### Author is untrustworthy 386 | 387 | Sometimes the only data you have are from a source you would rather not rely on. In some situations that's just fine. The only people who know how many guns are made are gun manufacturers. However, if you have data from a questionable maker always check it with another expert. Better yet, check it with two or three. Don't publish data from a biased source unless you have substantial corroborating evidence. 388 | 389 | ### Collection process is opaque 390 | 391 | It's very easy for false assumptions, errors or outright falsehoods to be introduced into these data collection processes. For this reason it's important that methods used be transparent. It's rare that you'll know exactly how a dataset was gathered, but indications of a problem can include numbers that [assert unrealistic precision](#data-asserts-unrealistic-precision) and data that [are too good to be true](#too-good-to-be-true). 392 | 393 | Sometimes the origin story may just be fishy: did such-and-such academic really interview 50 active gang members from the south side of Chicago? If the way the data were gathered seems questionable and your source can't offer you [ironclad provenance](#provenance-is-not-documented) then you should always verify with another expert that the data could reasonably have been collected in the way that was described. 394 | 395 | See also: 396 | 397 | * [Provenance is not documented](#provenance-is-not-documented) 398 | * [Data assert unrealistic precision](#data-assert-unrealistic-precision) 399 | * [Too good to be true](#too-good-to-be-true) 400 | 401 | ### Data assert unrealistic precision 402 | 403 | Outside of hard science, few things are routinely measured with more than two decimal places of accuracy. If a dataset lands on your desk that purports to show a factory's emissions to the 7th decimal place that is a dead giveaway that it was estimated from other values. That in and of itself may not be a problem, but it's important to be transparent about estimates. They are often wrong. 404 | 405 | ### There are inexplicable outliers 406 | 407 | I recently created a dataset of how long it takes for messages to reach different destinations over the internet. All of the times were in the range from `0.05` to `0.8` seconds, except for three. The other three were all over `5,000` seconds. This is a major red flag that something has gone wrong in the production of the data. In this particular case an error in the code I wrote caused some failures to continue counting while all other messages were being sent and received. 408 | 409 | Outliers such as these can dramatically screw up your statistics—especially if you're using averages. (You should probably be using medians.) Whenever you have a new dataset it is a good idea to take a look at the largest and smallest values and ensure they are in a reasonable range. If the data justifies it you may also want to do a more statistically rigorous analysis using [standard deviations](https://en.wikipedia.org/wiki/Standard_deviation) or [median deviations](https://en.wikipedia.org/wiki/Median_absolute_deviation). 410 | 411 | As a side-benefit of doing this work, outliers are often a great way to find story leads. If there really was one country where it took 5,000 times as long to send a message over the internet, that would be a great story. 412 | 413 | ### An index masks underlying variation 414 | 415 | Analysts who want to follow the trend of an issue often create indices of various values to track progress. There is nothing intrinsically wrong with using an index. They can have great explanatory power. However, it's important to be cautious of indices that combine disparate measures. 416 | 417 | For example, the United Nations [Gender Inequality Index](http://hdr.undp.org/en/content/gender-inequality-index-gii) combines several measures related to women's progress toward equality. One of the measures used in the GII is "representation of women in parliament". Two countries in the world have laws mandating gender representation in their parliaments: China and Pakistan. As a result these two countries perform far better in the index than countries that are similar in all other ways. Is this fair? It doesn't really matter, because it is confusing to anyone who doesn't know about this factor. The GII and similar indices should always be used with careful analysis to ensure their underlying variables don't swing the index in unexpected ways. 418 | 419 | ### Results have been p-hacked 420 | 421 | P-hacking is intentionally altering the data, changing the statistical analysis, or selectively reporting results in order to have statistically significant findings. Examples of this include: stop collecting data once you have a significant result, remove observations to get a significant result, or perform many analyses and only report the few that are significant. There has been some [good reporting](http://fivethirtyeight.com/features/science-isnt-broken) on this problem. 422 | 423 | If you're going to publish the results of a study you need to understand what the p-value is, what that means and then make an educated decision about whether the results are worth using. Lots and lots of garbage study results make it into major publications because journalists don't understand p-values. 424 | 425 | See also: 426 | 427 | * [Margin-of-error is too large](#margin-of-error-is-too-large) 428 | 429 | ### Benford's Law fails 430 | 431 | [Benford's Law](https://en.wikipedia.org/wiki/Benford's_law) is a theory which states that small digits (1, 2, 3) appear at the beginning of numbers much more frequently than large digits (7, 8, 9). In theory Benford's Law can be used to detect anomalies in accounting practices or election results, though in practice it can easily be misapplied. If you suspect a dataset has been created or modified to deceive, Benford's Law is an excellent first test, but you should always verify your results with an expert before concluding your data have been manipulated. 432 | 433 | ### Too good to be true 434 | 435 | There is no global dataset of public opinion. Nobody knows the exact number of people living in Siberia. Crime statistics aren't comparable across borders. The US government is not going to tell you how much fissile material it keeps on hand. 436 | 437 | Beware any data that purport to represent something that you could not possibly know. It's not data. It's somebody's estimate and it's probably wrong. Then again...it could be a story, so ask an expert to check it out. 438 | 439 | ## Issues a programmer should help you solve 440 | 441 | ### Data are aggregated to the wrong categories or geographies 442 | 443 | Sometimes your data are at about the right level of detail (neither [too coarse](#data-are-too-coarse) nor [too granular](#data-are-too-granular)), but they have been aggregated to a different grouping than you want. The classic example of this is data that are aggregated by zip codes that you would prefer to have by city neighborhoods. In many cases this is an impossible problem to solve without getting more granular data from your source, but sometimes the data can be proportionally mapped from one group to another. This must be undertaken only with careful understanding of the [margin-of-error](#margin-of-error-is-too-large) that may be introduced in the process. If you've got data aggregated to the wrong groups, ask a programmer if it is possible to re-aggregate it. 444 | 445 | See also: 446 | 447 | * [Data are too coarse](#data-are-too-coarse) 448 | * [Data are too granular](#data-are-too-granular) 449 | * [Margin-of-error is too large](#margin-of-error-is-too-large) 450 | 451 | ### Data are in scanned documents 452 | 453 | Thanks to FOIA laws it is frequently the case that governments are required to give you data—even though they really don't want to. A very common tactic in these cases is for them to give you scans or photographs of the pages. These may be actual image files or, more likely, they will be gathered up into a PDF. 454 | 455 | It is possible to extract text from images and turn it back into data. This is done through a process called optical-character recognition (OCR). Modern OCR can often be almost 100% accurate, but it very much depends on the nature of the document. Anytime you use OCR to extract data you will want to have a process for validating the results match the original. 456 | 457 | There are many websites you can upload a document to for OCR, but there are also free tools that a programmer may be able to tune for your specific documents. Ask them what the best strategy is for the particular documents you have. 458 | 459 | See also: 460 | 461 | * [Data are in a PDF](#data-are-in-a-pdf) 462 | -------------------------------------------------------------------------------- /translations/français.md: -------------------------------------------------------------------------------- 1 | # Le guide de Quartz pour résoudre les problèmes de qualité des données 2 | 3 | **Une liste des problèmes pouvant être rencontrés dans des jeux de données et des suggestions pour les résoudre.** 4 | 5 | En tant que journaliste, vous êtes amenés à travailler de plus en plus avec des données. Mais celles-ci ne sont pas toujours d’une qualité suffisante pour être exploitées. Ce guide présente des descriptions détaillées des problèmes relatifs à la qualité des données et suggère des solutions pour résoudre une large part des problèmes rencontrés. 6 | 7 | La plupart de ces problèmes peuvent être résolus. Lorsque cela n’est pas possible, cela signifie que les données seront inutilisables. Dans certains cas, une solution est possible mais moyennant quelques précautions. De manière à tenir compte de ces ambigüités, ce guide est organisé en fonction de la personne la plus adéquate pour résoudre le problème : vous, votre source, un expert, etc. Vous trouverez également des suggestions sur ce qu’il est possible de faire lorsqu’il n’est pas possible de trouver une personne-ressource. 8 | 9 | C'est en vous familiarisant avec les types de problèmes que vous êtes susceptibles de rencontrer que vous aurez les meilleures chances de les identifier. Prévenir, c'est guérir ! 10 | 11 | Pour toute question à propos de ce guide ou proposer une traduction dans votre langue, contactez, en anglais, [Chris](mailto:chrisgroskopf@gmail.com). 12 | 13 | Ce document est sous licence [Creative Commons Attribution-Pas d'utilisation commerciale 4.0 License Internationale](http://creativecommons.org/licenses/by-nc/4.0/). Send your pull requests! 14 | 15 | # Traductions 16 | 17 | * [Anglais - version originale](https://github.com/Quartz/bad-data-guide) 18 | * [Chinois](http://djchina.org/2016/07/12/bad_data_guide/) (complet) 19 | * [Chinois](http://cn.gijn.org/2016/01/10/quartz%E5%9D%8F%E6%95%B0%E6%8D%AE%E6%8C%87%E5%8D%97%E7%B2%BE%E9%80%89%EF%BC%9A%E5%A4%84%E7%90%86%E6%95%B0%E6%8D%AE%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%96%B9%E5%BC%8F%E4%B8%80%E8%A7%88/) (partiel) 20 | * [Japonais](https://github.com/piyo-ko/bad-data-guide/blob/master/README_ja.md) 21 | * [Portugais](http://escoladedados.org/2016/09/08/guia-quartz-para-limpeza-de-dados/) 22 | * [Espagnol](http://es.schoolofdata.org/guia-quartz/) 23 | 24 | # Index 25 | 26 | ## Problèmes que vos sources peuvent vous aider à résoudre 27 | 28 | * [Valeurs manquantes](#valeurs-manquantes) 29 | * [Valeurs manquantes remplacées par zéro](#zeros-remplacent-valeurs-manquantes) 30 | * [Données manquantes mais existantes](#donnees-existantes-manquantes) 31 | * [Lignes ou valeurs dupliquées](#lignes-ou-valeurs-dupliquees) 32 | * [Incohérence orthographique](#incoherence-orthographique) 33 | * [Incohérence dans l'ordre des noms](#incoherence-ordre-des-noms) 34 | * [Incohérence des formats de date](#incoherence-formats-de-date) 35 | * [Type de valeur non spécifié](#type-de-valeur-non-specifie) 36 | * [Catégories mal choisies](#mauvais-choix-categorie) 37 | * [Etiquetage des colonnes ambigu](#etiquetage-ambigu) 38 | * [Provenance non documentée](#provenance-non-documentee) 39 | * [Présence de valeurs suspectes](#valeurs-suspectes) 40 | * [Données trop grossières](#donnees-grossieres) 41 | * [Les totaux diffèrent des agrégats publiés](#totaux-differents-agregats) 42 | * [La feuille de calcul comporte 65.536 lignes](#nombre-de-lignes-eleve) 43 | * [La feuille de calcul comporte 255 colonnes](#nombre-de-colonnes-eleve) 44 | * [La feuille de calcul comporte des dates en 1900 ou 1904](#ecarts-dates) 45 | * [Textes convertis en nombres](#textes-en-nombres) 46 | * [Numéros stockés en tant que texte](#nombres-en-textes) 47 | 48 | ## Problèmes que vous pouvez résoudre 49 | 50 | * [Problème d'encodage](#texte-confus) 51 | * [Les fins de ligne sont confuses/brouillées](#fin-de-lignes-confuses) 52 | * [Données au format PDF](#donnees-pdf) 53 | * [Données trop granulaires](#donnees-granulaires) 54 | * [Encodage humain des données](#encodage-humain) 55 | * [Données mélangées avec le formatage et les annotations](#donnees-melangees-formatage-annotations) 56 | * [Agrégations calculées avec des valeurs manquantes](#agregations-valeurs-manquantes) 57 | * [Echantillon non aléatoire](#echantillon-non-aleatoire) 58 | * [Marge d'erreur trop importante](#marge-d-erreur-trop-importante) 59 | * [Marge d'erreur inconnue](#marge-d-erreur-inconnue) 60 | * [Echantillon biaisé](#echantillon-biaise) 61 | * [Données éditées manuellement](#donnees-editees-manuellement) 62 | * [L'inflation fausse les données](#inflation-fausse-donnees) 63 | * [Des variations naturelles / saisonnières faussent les données](#donnees-saisonnieres-faussent-donnees) 64 | * [Manipulation des périodes de temps](#manipulation-periodes-temps) 65 | * [Manipulation du cadre de référence](#manipulation-cadre-reference) 66 | 67 | ## Problèmes qu'un expert peut vous aider à résoudre 68 | 69 | * [Source ou auteur non fiables](#auteur-non-fiable) 70 | * [Opacité du processus de collecte des données](#opacite-processus-collecte) 71 | * [Précision irréaliste des données](#assertions-irrealistes) 72 | * [Valeurs aberrantes inexplicables](#valeurs-aberrantes-inexplicables) 73 | * [Un index masque la variation sous-jacente](#variation-masquee) 74 | * [Résultats piratés](#resultats-pirates) 75 | * [Echec de la loi de Benford](#echec-loi-benford) 76 | * [Trop bon pour être vrai](#trop-bon-pour-etre-vrai) 77 | 78 | ## Problèmes qu'un développeur peut vous aider à résoudre 79 | 80 | * [Données agrégées dans une mauvaise catégorie ou zone géographique](#donnees-agregees-mauvaise-categorie) 81 | * [Données dans un document scanné](#donnees-dans-document-scanne) 82 | 83 | # Liste détaillée de tous les problèmes relatifs à la qualité des données 84 | 85 | ## Problèmes que vos sources peuvent vous aider à résoudre 86 | 87 | ### Valeurs manquantes 88 | 89 | Méfiez-vous des valeurs vides ou « nulles » dans un jeu de données, à moins que vous ne soyez certain de savoir ce qu'elles signifient. Si les données sont annuelles, la valeur de cette année n'a-t-elle jamais été collectée ? Si c'est un sondage, un répondant a-t-il refusé de répondre à la question ? 90 | 91 | Chaque fois que vous travaillez avec des jeux de données qui comportent des valeurs manquantes, vous devriez vous demander : « Est-ce que je sais ce que signifie l'absence de cette valeur ? » Si la réponse est non, vous devriez demander à votre source pourquoi ces valeurs sont manquantes. 92 | 93 | ### Valeurs manquantes remplacées par zéro 94 | 95 | Il y a pire qu’une valeur manquante : lorsque celle-ci est remplacée par une valeur arbitraire. Cela peut être le fait d’un humain qui n’a pas réfléchi aux implications de ce remplacement ou cela peut se produire dans le résultat d’un processus automatisé qui n’avait pas été paramétré pour gérer les valeurs nulles. Si vous voyez des valeurs « zéro » (ou nulles), demandez-vous si elles sont vraiment nulles ou ce qu’elles peuvent signifier. Si vous n’en n’êtes pas certain, interrogez la source des données (idéalement, le producteur plutôt que le diffuseur car il s’agit de la source primaire des données). 96 | 97 | La même prudence doit être de rigueur pour toute autre valeur non numérique où un « 0 » peut être représenté d'une autre manière. Par exemple, une valeur fausse '0' pour une date est souvent affichée en tant que' 1970-01-01T00: 00: 00Z' ou '1969-12-31T24: 59: 59Z' - ce format date de [l'époque Unix pour les horodatages] (https: //en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number). En matière de géolocalisation, cela peut conduire à la représentation de localisations erronées telles que "0 ° 00'00.0" N + 0 ° 00'00.0 "E" ou simplement "0 ° N 0 ° E" qui est un point qui se trouve dans l'océan Atlantique, au sud du Ghana aussi appelé [Null Island] (https://en.wikipedia.org/wiki/Null_Island). 98 | Voir aussi: 99 | 100 | * [Présence de valeurs suspectes](#valeurs-suspectes) 101 | * [La feuille de calcul comporte des dates en 1900 ou 1904](#ecarts-dates) 102 | 103 | ### Données manquantes mais existantes 104 | 105 | Des données sont parfois manquantes dans un jeu de données. Il est toutefois possible de vérifier la complétude d’un jeu de données : par exemple, vous disposez d’un jeu de données à propos des Etats-Unis, vous pouvez donc contrôler que les 50 états y sont représentés. Si vous traitez des jeux de données à propos d’équipes sportives, assurez-vous d’y trouver le nom de tous les joueurs ou de toutes les équipes attendues dans le jeu de données. Faites confiance à votre intuition si vous pensez que des données sont manquantes et vérifiez auprès de votre source. 106 | 107 | ### Lignes ou valeurs dupliquées 108 | 109 | Si la même ligne apparaît plus d'une fois dans votre jeu de données, vous devriez savoir pourquoi. Il peut s’agir de données dupliquées ou de lignes utilisant les mêmes identifiants uniques. Si vous n’en connaissez pas la raison, toute opération de calcul effectuée à partir de ces données sera erronée. Dans ce cas, demandez des précisions à votre source. 110 | 111 | ### Incohérence orthographique 112 | 113 | L'orthographe est l'un des moyens les plus évidents de savoir si les données ont été compilées à la main. Ne regardez pas seulement les noms des personnes, c'est souvent l'endroit le plus difficile pour détecter les fautes d'orthographe. Cherchez plutôt des endroits où les noms de villes ou les états ne sont pas cohérents. (« Los Angelos » est une erreur très commune.) Si vous les trouvez, vous pouvez être certain que les données ont été compilées ou éditées à la main : c’est donc une raison pour être sceptique. Les données qui ont été éditées à la main sont les plus susceptibles de comporter des erreurs. Cela ne signifie pas que vous ne devriez pas les utiliser mais que vous devriez peut-être corriger ces erreurs manuellement ou en tenir compte dans vos analyses. 114 | 115 | [OpenRefine](http://openrefine.org/) est utile pour le [clustering de texte (text clustering)] (https://github.com/OpenRefine/OpenRefine/wiki/Clustering) qui peut aider à rationaliser le processus de correction orthographique en suggérant des correspondances proches entre des valeurs incohérentes dans une colonne (par exemple, en associant « Los Angelos » à « Los Angeles »). Assurez-vous toutefois de [documenter les modifications que vous apportez] (https://github.com/OpenRefine/OpenRefine/wiki/Exporters) afin de documenter [la provenance des données] (# provenance-non-documenté). 116 | 117 | 118 | Voir aussi : 119 | 120 | * [Encodage humain des données](#encodage-humain) 121 | 122 | ### Incohérence dans l'ordre des noms 123 | 124 | Vos données comportent-elles des noms de pays du Moyen-Orient ou d'Asie de l'Est ? Etes-vous certain que les noms de famille se trouvent toujours au même endroit ? Les producteurs de données se trompent habituellement dans ce type de noms. Si vous travaillez avec une liste de noms étrangers, vous devriez au moins procéder à un examen superficiel avant de supposer que les colonnes « first_name » et « last_name », par exemple, vous donnera quelque chose d’approprié à publier. 125 | 126 | * [Encodage humain des données](#encodage-humain) 127 | 128 | ### Incohérence des formats de date 129 | 130 | Quelle est la bonne date pour le mois de septembre ? 131 | 132 | * '10/9/15' 133 | * '9/10/15' 134 | 135 | La permière date a été rédigée par un Européen et le seconde par un Américain : [les deux sont donc correctes] (https://en.wikipedia.org/wiki/Date_format_by_country). Mais sans connaître l'historique des données, vous ne pouvez pas en être certain à coup sûr. Sachez d'où proviennent vos données et assurez-vous qu'elles ont toutes été créées par des personnes du même continent. 136 | 137 | * [Encodage humain des données](#encodage-humain) 138 | * [Provenance non documentée](#provenance-non-documentee) 139 | 140 | ### Type de valeurs non spécifié 141 | 142 | Ni le terme « poids » ni le terme « coût » ne donnent d'informations sur l'unité de mesure utilisée dans un jeu de données. Ne soyez pas trop prompts à supposer que les données produites aux États-Unis sont en livres et en dollars. Les données scientifiques sont souvent métriques. Les prix étrangers peuvent être spécifiés dans leur monnaie locale. Si les données n'épellent pas leurs unités, revenez à votre source. Même si elle précise les unités utilisées, méfiez-vous toujours de significations qui ont pu évoluer dans le temps. Un dollar en 2010 n'est pas un dollar aujourd'hui. 143 | 144 | Voir aussi : 145 | 146 | * [Etiquetage des colonnes ambigu](#etiquetage-ambigu) 147 | * [L'inflation fausse les données](#inflation-fausse-donnees) 148 | 149 | ### Catégories mal choisies 150 | 151 | Méfiez-vous des valeurs qui prétendent être seulement vraies ou fausses mais qui ne le sont pas vraiment. C'est souvent le cas avec les enquêtes où les refus ou les non-réponses sont également des valeurs valables et significatives. Un autre problème consiste dans l'utilisation de n'importe quel type d'autre catégorie. Les mauvaises catégories peuvent également exclure artificiellement les données. Cela arrive souvent avec les statistiques de la criminalité. Le FBI a défini le crime de « viol » de différentes façons au fil du temps. En fait, ils ont fait un travail si médiocre pour déterminer ce qu'est le viol que de nombreux criminologues affirment que leurs statistiques ne devraient pas être utilisées du tout. Une mauvaise définition peut signifier qu'un crime est comptabilisé dans une catégorie différente de celle que vous attendiez ou qu'elle n'a pas été du tout prise en compte. Soyez à l'affût de ce type problème lorsque vous travaillez sur des sujets où les définitions ont tendance à être arbitraires, comme en matière d’origine ethnique. 152 | 153 | ### Etiquetage des colonnes ambigu 154 | 155 | Qu'est-ce qu'une résidence ? Est-ce là où quelqu'un vit ou où il paie ses impôts ? Les étiquettes des colonnes (intitulé des variables) ne sont jamais aussi précises que nous le souhaiterions. Même si vous déduisez correctement ce que les valeurs sont censées signifier, cette ambiguïté pourrait facilement amener la personne qui collecte les données à entrer une valeur erronée. 156 | 157 | ### Provenance non documentée 158 | 159 | Les jeux de données peuvent être créés par une variété de types d'individus et d'organisations, y compris les entreprises, les gouvernements, les organisations à but non lucratif et les théoriciens du complot. Les données sont recueillies de différentes façons, y compris via des enquêtes, des capteurs et des satellites. Le fait de savoir d'où proviennent vos données peut vous donner une bonne idée de leurs limites. 160 | 161 | Les données d'enquête, par exemple, sont rarement exhaustives. Les capteurs varient dans leur précision. Les gouvernements sont souvent réticents à vous donner des informations impartiales. Les données provenant d'une zone de guerre peuvent comporter un fort biais géographique en raison du danger de traverser les lignes de bataille. Les données qui ont été écrites par un médecin peuvent être saisies par une infirmière. Chaque étape de la chaîne de collecte des données peut donner lieu à des erreurs. Vous devez savoir d’où proviennent les données que vous utilisez. 162 | 163 | Voir aussi : 164 | 165 | * [Type de valeurs non spécifié](#type-de-valeur-non-specifie) 166 | 167 | ### Présence de valeurs suspectes 168 | 169 | Si vous voyez l'une de ces valeurs dans vos données, traitez-les avec beaucoup de prudence : 170 | 171 | Nombres : 172 | 173 | * ['65,535'](https://en.wikipedia.org/wiki/65535_%28number%29) 174 | * ['255'](https://en.wikipedia.org/wiki/255_%28number%29) 175 | * ['2,147,483,647'](https://en.wikipedia.org/wiki/2147483647_%28number%29) 176 | * ['4,294,967,295'](https://en.wikipedia.org/wiki/4294967295) 177 | * ['555-3485'](https://en.wikipedia.org/wiki/555_%28telephone_number%29) 178 | * '99999' (ou toute autre longue séquence de 9) 179 | * '00000' (ou toute autre séquence de 0) 180 | 181 | Dates : 182 | 183 | * ['1970-01-01T00:00:00Z'](https://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number) 184 | * ['1969-12-31T23:59:59Z'](https://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number) 185 | * ['1er janvier 1900'](#ecarts-dates) 186 | 187 | Localisations : 188 | 189 | * ['0°00'00.0"N+0°00'00.0"E'](https://en.wikipedia.org/wiki/Null_Island) or simply ['0°N 0°E'](https://en.wikipedia.org/wiki/Null_Island) 190 | 191 | Chacun de ces nombres donne l'indice d'une erreur particulière émanant d'un humain ou d'une machine. Si vous les voyez, assurez-vous qu'ils signifient réellement ce que vous pensez qu'ils veulent dire ! 192 | 193 | Pour en savoir plus sur la standardisation des formats de dates ou données de géolocalisation, consultez le blog de la traductrice de ce guide (@ohmyshambles) : [Qualité des données : standardiser, pourquoi et comment] (http://www.ohmybox.info/qualite-des-donnees-standardiser-pourquoi-et-comment/) 194 | 195 | Voir aussi : 196 | 197 | * [La feuille de calcul comporte 65.536 lignes](#nombre-de-lignes-eleve) 198 | * [La feuille de calcul comporte 255 colonnes](#nombre-de-colonnes-eleve) 199 | * [La feuille de calcul comporte des dates en 1900 ou 1904](#ecarts-dates) 200 | 201 | ### Données trop grossières 202 | 203 | Les données dont vous disposez vous proposent des états et vous avez besoin de régions. Vous disposez d’une liste d’employeurs alors que vous avez besoins de celle des employés. Vos données sont ventilées par année mais vous auriez préféré par mois. Dans de nombreux cas, les données ne rencontrent pas nos objectifs. Si vous recevez des données trop grossières, vous devriez demander à votre source des données plus spécifiques. 204 | 205 | Par ailleurs, vous ne devriez jamais diviser une valeur annuelle par 12 puis la nommer « moyenne par mois ». Sans connaître la distribution des valeurs, ce chiffre n'aura aucun sens. 206 | 207 | Voir aussi : 208 | 209 | * [Données trop granulaires](#donnees-granulaires) 210 | * [Données agrégées dans une mauvaise catégorie ou zone géographique](#donnees-agregees-mauvaise-categorie) 211 | 212 | ### Les totaux diffèrent des agrégats publiés 213 | 214 | Imaginez que vous obteniez, après un long combat, une liste « complète » d’incidents liés à l’utilisation de la force par la police. Vous ouvrez le fichier et découvrez 2.467 lignes. Mais pas si vite ! Avant de publier quoi que ce soit à partir de ce jeu de données, essayez de retrouver la dernière fois où le chef de la police a parlé du recours à la force par son ministère. Peut-être que dans une interview accordée six semaines plus tôt, il a parlé de « moins de 2.000 fois » ou qu'il a donné un nombre spécifique qui ne correspond pas à votre jeu de données. 215 | 216 | Ces types de divergence entre les statistiques publiées et les données brutes peut s’avérer une source d’informations importante. Souvent, la réponse expliquant cette divergence sera simple. Par exemple, les données que vous avez reçues ne couvrent peut-être pas la même période dont il parlait. Mais parfois vous les rattraperez dans leur mensonge. Dans les deux cas, vous devez vous assurer que les chiffres publiés correspondent aux totaux des données qui vous ont été fournies. 217 | 218 | ### La feuille de calcul comporte 65.536 lignes 219 | 220 | Le nombre maximal de lignes autorisées dans une feuille de calcul d’une ancienne version d’Excel était de 65 536. Si vous recevez un jeu de données avec ce nombre de lignes, vous avez probablement reçu un jeu de données incomplet. Les nouvelles versions d'Excel permettent 1.048.576 lignes, donc il est moins probable que vous utilisiez des jeux de données qui atteignent cette limite. 221 | 222 | ### La feuille de calcul comporte 255 colonnes 223 | 224 | L'application Numbers d'Apple ne peut gérer que des feuilles de calcul contenant 255 colonnes et elle tronque les fichiers comportant davantage de colonnes sans avertir l'utilisateur. Si vous recevez un jeu de données avec exactement 255 colonnes, demandez si le fichier a été ouvert ou converti avec Numbers. 225 | 226 | ### La feuille de calcul comporte des dates en 1900 ou 1904 227 | 228 | Pour d’obscures raisons, la date par défaut d’Excel à partir de laquelle le logiciel compte toutes les autres dates est le 1er janvier 1900. Mais si vous utilisez Excel pour Mac, ce sera le 1er janvier 1904. Si vous repérez ces dates dans vos données, il s’agit probablement d’un problème. 229 | 230 | ### Textes convertis en nombres 231 | 232 | Tous les chiffres ne sont pas des nombres. Par exemple, un code peut être utilisé sans qu’il soit pour autant un nombre et qu’il signifie donc toute autre chose. Essayer de convertir ce type de données en nombres peut entraîner toute une série de problèmes, y compris si vous essayez de les convertir dans un autre format de fichier ou de les fusionner avec d’autres jeux de données. 233 | 234 | ### Numéros stockés en tant que texte 235 | 236 | Lorsque vous travaillez avec des feuilles de calcul, les numéros peuvent être stockés sous forme de texte avec un formatage indésirable. Cela arrive souvent lorsqu'une feuille de calcul est optimisée pour présenter des données plutôt que de les rendre disponibles pour une réutilisation. Par exemple, au lieu de représenter un million de dollars avec le nombre "1000000", une cellule peut contenir la chaîne "1,000,000" ou "1 000 000" ou "USD 1 000 000" avec le formatage des virgules, unités et espaces. Excel peut prendre en charge certains cas simples mais vous devrez souvent utiliser des formules pour supprimer les caractères indésirables, jusqu'à ce que les cellules soient suffisamment propres pour être reconnues comme des nombres. Une bonne pratique consiste à stocker des numéros sans formatage et à inclure des informations de contexte dans les étiquettes de colonnes ou les métadonnées. 237 | 238 | ## Problèmes que vous pouvez résoudre 239 | 240 | ### Problème d'encodage 241 | 242 | Toutes les lettres sont représentées par des ordinateurs sous la forme de nombres. Les problèmes d'encodage sont des problèmes qui surviennent lorsque le texte est représenté par un ensemble spécifique de nombres (appelé "encodage"). Cela peut donner lieu à du texte illisible, parsemé de caractères spéciaux incompréhensible. Votre source devrait être en mesure de vous indiquer le type d’encodage du jeu de données. 243 | 244 | ### Les fins de ligne sont confuses/brouillées 245 | 246 | Tous les fichiers de textes et de « données de texte », tels qu’au format CSV, utilisent des caractères invisibles pour représenter les extrémités des lignes. Les ordinateurs Windows, Mac et Linux sont historiquement en désaccord sur ce que devraient être ces caractères de fin de ligne. La tentative d'ouverture d'un fichier enregistré sur un système d'exploitation à partir d'un autre système d'exploitation peut parfois empêcher Excel ou d'autres applications d'identifier correctement les sauts de ligne. 247 | 248 | En règle générale, il est facile de résoudre ce problème en ouvrant simplement le fichier dans un éditeur de texte général et en le réenregistrant. Si le fichier est exceptionnellement volumineux, vous devrez peut-être envisager d'utiliser un outil de ligne de commande ou d'obtenir l'aide d'un développeur. 249 | 250 | ### Données au format PDF 251 | 252 | Un nombre important de jeux de données n’est disponible qu’au seul format PDF. Pour extraire les données d’un document PDF, il existe plusieurs outils dont Tabula (gratuit). Toutefois, si vous disposez d'Adobe Creative Cloud, vous avez normalement accès à Acrobat Pro, qui dispose d'une fonctionnalité permettant d’exporter des tableaux vers Excel. L'une ou l'autre solution devrait être capable d'extraire la plupart des données tabulaires d'un PDF. 253 | 254 | Voir aussi : 255 | 256 | * [Données dans un document scanné](#donnees-dans-document-scanne) 257 | 258 | ### Données trop granulaires 259 | 260 | C'est le contraire des données trop grossières. Dans ce cas vous avez des régions, mais vous voulez des états ou vous avez des mois mais vous voulez des années. 261 | 262 | Les données peuvent être agrégées en utilisant la fonction de tableau croisé dynamique d'Excel ou de Google Docs, en utilisant une base de données SQL ou en écrivant du code personnalisé. Les tableaux croisés dynamiques sont un outil fabuleux que tous les journalistes devraient apprendre, mais ils ont leurs limites. Pour les jeux de données exceptionnellement volumineux, il est préférable de solliciter un développeur. 263 | 264 | Voir aussi : 265 | 266 | * [Données trop grossières](#donnees-grossieres) 267 | * [Données agrégées dans une mauvaise catégorie ou zone géographique](#donnees-agregees-mauvaise-categorie). 268 | 269 | ### Encodage humain des données 270 | 271 | La saisie de données par des humains est un problème si courant que ses symptômes sont mentionnés dans au moins 10 des autres problèmes décrits dans ce document. Les erreurs sont humaines et sans procédure stricte de validation, des problèmes de toutes natures peuvent se poser. Surtout, méfiez-vous des données encodées par les utilisateurs qui n’ont sans doute pas la moindre idée de ce à quoi peut se rapporter le concept de qualité des données. 272 | 273 | ### Données mélangées avec le formatage et les annotations 274 | 275 | Les représentations complexes de données telles que HTML et XML permettent une séparation nette entre les données et leur mise en forme mais ce n'est pas le cas pour les formats tabulaires. Un des problèmes courants consiste à annoter ou décrire les données dans l’étiquetage des colonnes. Des lignes en tête de fichier peuvent être dupliquées ou le fichier peut comporter plusieurs feuilles qui comporteront plusieurs tables, lesquelles peuvent présenter un étiquetage différent. 276 | 277 | Dans tous les cas, la solution consiste simplement à identifier le problème. 278 | 279 | ### Agrégations calculées avec des valeurs manquantes 280 | 281 | Imaginez un jeu de données avec 100 lignes et une colonne appelée « coût ». Dans 50 lignes, la colonne des coûts est vide. Quelle est la moyenne de cette colonne ? Est-ce sum_of_cost / 50 ou sum_of_cost / 100 ? Il n'y a pas de réponse définitive. En général, si vous voulez calculer des agrégats sur des colonnes qui ne sont pas complètes, vous pouvez le faire en filtrant les lignes manquantes. Dans certains cas, la valeur manquante pourra être légitimement interprétée comme égale à zéro. SI vous n’en êtes pas certain, demandez à un expert. Sinon, cela peut conduire à une erreur d’analyse, une erreur que d’autres peuvent reprendre et ensuite transmettre. 282 | 283 | Voir aussi : 284 | 285 | * [Valeurs manquantes](#valeurs-manquantes) 286 | * [Valeurs manquantes remplacées par zéro](#zeros-remplacent-valeurs-manquantes) 287 | 288 | ### Echantillon non aléatoire 289 | 290 | Une erreur d'échantillonnage non aléatoire se produit lorsqu'une enquête ou tout autre jeu de données échantillonnées échoue intentionnellement ou accidentellement à couvrir l'ensemble de la population. Cela peut se produire pour une variété de raisons allant de l'heure de la journée à la langue maternelle du répondant. C’est une source fréquente d'erreur dans la recherche en sociologie. Cela peut aussi se produire pour des raisons moins évidentes, par exemple lorsqu'un chercheur pense avoir un ensemble de données complet et qu’il choisit de ne travailler qu'avec une partie de celui-ci. Si le jeu de données original était incomplet pour une raison quelconque, les conclusions tirées de leur échantillon seront incorrectes. La seule chose que vous pouvez faire pour corriger un échantillon non aléatoire est d'éviter d'utiliser ces données. 291 | 292 | Voir aussi : 293 | 294 | * [Echantillon biaisé](#echantillon-biaise) 295 | 296 | ### Marge d'erreur trop importante 297 | 298 | La marge d’erreur est généralement associée aux données d’enquêtes. En règle générale, vous devriez être prudent dans l’utilisation de ce type de données, surtout si la marge d’erreur dépasse les 10%. 299 | 300 | Voir aussi : 301 | 302 | * [Marge d'erreur inconnue](#margin-of-error-is-unknown) 303 | 304 | ### Marge d'erreur inconnue 305 | 306 | Parfois, le problème n'est pas que la marge d'erreur soit trop grande, c'est que personne n'a jamais pris la peine de la comprendre. C'est un problème récurrent dans les sondages non-scientifiques. Sans calculer une marge d’erreur, il est impossible de savoir si les résultats sont exacts. En règle générale, chaque fois que vous avez des données provenant d'un sondage, vous devriez vous posez la question de la marge d’erreur. Si votre source ne peut pas vous le dire, ces données ne valent probablement pas la peine d'être utilisées pour une analyse sérieuse. 307 | 308 | Voir aussi : 309 | 310 | * [Marge d'erreur trop importante](#marge-d-erreur-trop-importante) 311 | 312 | ### Echantillon biaisé 313 | 314 | A l’instar [d’un échantillon qui n'est pas aléatoire] (# echantillon-non-aleatoire), un échantillon biaisé résulte d'un manque de soin dans la façon dont l'échantillonnage a été exécuté (ou d’une volonté de le déformer). Un échantillon pourrait être biaisé parce que le sondage a été réalisé sur Internet et que les personnes les plus pauvres n'utilisent pas Internet aussi fréquemment que les riches. Les enquêtes doivent être soigneusement pondérées pour s'assurer qu'elles couvrent des segments proportionnels de toute population qui pourraient fausser les résultats. Il est presque impossible de le faire parfaitement… 315 | Voir aussi : 316 | 317 | * [Echantillon non aléatoire](#echantillon-non-aleatoire) 318 | 319 | ### Données éditées manuellement 320 | 321 | L'édition manuelle de données donne lieu quasi aux mêmes problèmes qu’un [encodage humain des données] (# encodage-humain) sauf que cela arrive après coup. En fait, les données sont souvent éditées manuellement dans le but de les corriger. 322 | 323 | Les problèmes d'édition manuelle sont une des raisons pour lesquelles vous devez toujours vous assurer que la provenance de vos données soit bien documentée. Dans la mesure du possible, essayez d’obtenir le jeu de données original ou tout au moins sa version la plus ancienne. 324 | 325 | Voir aussi : 326 | 327 | * [Provenance non documentée](#provenance-non-documentee) 328 | * [Encodage humain des données](#encodage-humain) 329 | 330 | ### L'inflation fausse les données 331 | 332 | L'inflation monétaire signifie que l'argent change de valeur dans le temps. Il n'y a aucun moyen de dire si les chiffres ont été ajustés en fonction de l'inflation. Si vous obtenez des données et que vous n'êtes pas sûr qu'elles aient été ajustées, vérifiez auprès de votre source. Si ce n'est pas le cas, vous voudrez probablement effectuer cet ajustement. 333 | 334 | Voir aussi : 335 | 336 | * [Des variations naturelles / saisonnières faussent les données](#nationalseasonal-variation-skews-the-data) 337 | 338 | ### Des variations naturelles / saisonnières faussent les données 339 | 340 | De nombreux types de données fluctuent naturellement en raison de certaines forces sous-jacentes. L'exemple le plus connu est celui de l'emploi fluctuant avec les saisons. Les économistes ont développé une variété de méthodes pour compenser cette variation. Les détails de ces méthodes ne sont pas particulièrement importants, mais il est important que vous sachiez si les données que vous utilisez ont été "désaisonnalisées". Si ce n'est pas le cas et que vous voulez comparer le volume de l'emploi d'un mois à l'autre, vous voudrez probablement obtenir des données ajustées auprès de votre source (il est ici beaucoup plus difficile de les ajuster soi-même, contrairement à l’inflation). 341 | 342 | Voir aussi : 343 | 344 | * [L'inflation fausse les données](#inflation-fausse-donnees) 345 | 346 | ### Manipulation des périodes de temps 347 | 348 | Une source peut accidentellement ou intentionnellement déformer la réalité en fournissant des données qui démarrent ou s’arrêtent à un moment précis. Par exemple, les données relatives à une « vague de criminalité nationale », qui furent diffusées en 2015, auraient dû être analysées sur une période plus longue : les journalistes auraient vu que les crimes violents étaient plus élevés aux Etats-Unis dix ans auparavant. 349 | 350 | Si vous disposez de données qui couvrent une période limitée, essayez d'éviter de commencer vos calculs dès la toute première période à laquelle commence le jeu de données. 351 | 352 | Voir aussi : 353 | 354 | * [Manipulation du cadre de référence](#manipulation-cadre-reference) 355 | 356 | ### Manipulation du cadre de référence 357 | 358 | Les statistiques criminelles sont souvent manipulées à des fins politiques en les comparant à une année où le crime était très élevé. Cela peut être exprimé soit comme un changement (en baisse de 60% depuis 2004) ou via un indice (40, où 2004 = 100). Dans l'un ou l'autre de ces cas, 2004 peut ou non être une année appropriée pour la comparaison. Cela aurait pu être une année de criminalité anormalement élevée. 359 | 360 | Dans la mesure du possible, essayez de comparer les taux de plusieurs points de départ différents pour voir comment les chiffres changent. 361 | 362 | Voir aussi : 363 | 364 | * [Manipulation des périodes de temps](#manipulation-periodes-temps) 365 | 366 | ## Problèmes qu'un expert peut vous aider à résoudre 367 | 368 | ### Source ou auteur non fiables 369 | 370 | Parfois, les seules données dont vous disposez proviennent d'une source à propos de laquelle il est raisonnable de douter. Dans certaines situations, c'est très bien. Les seules personnes qui savent combien d'armes sont fabriquées sont les fabricants d'armes à feu. Cependant, si vous ces données proviennent d'un fabricant d’armes douteux, vérifiez toujours avec un autre expert. Mieux encore, vérifiez vos données avec deux ou trois experts. Ne publiez pas de données provenant d'une source biaisée à moins d'avoir des preuves permettant de les corroborer de manière substantielle. 371 | 372 | ### Opacité du processus de collecte des données 373 | 374 | Il est très facile d'introduire de fausses suppositions ou des erreurs dans les processus de collecte des données. Pour cette raison, il est important que les méthodes utilisées soient transparentes. Il est rare que vous sachiez exactement comment un jeu de données a été recueilli mais les indications d'un problème peuvent inclure des nombres qui [affirment une précision irréaliste] (# data-asserts-unrealistic-precision) ou des données qui sont trop bonnes pour être vraies. # trop-bon-pour-etre-vrai). 375 | 376 | Parfois, l'histoire d'origine peut être louche : est-ce que tel ou tel universitaire a vraiment interviewé 50 membres de gangs actifs du côté sud de Chicago ? Si la façon dont les données ont été recueillies semble douteuse et que votre source ne peut vous founir des données documentées, vous devriez toujours vérifier auprès d'un autre expert que les données auraient pu raisonnablement être collectées de la manière décrite. 377 | 378 | Voir aussi : 379 | 380 | * [Provenance non documentée](#provenance-non-documentee) 381 | * [Précision irréaliste des données](#assertions-irrealistes) 382 | * [Trop bon pour être vrai](#trop-bon-pour-etre-vrai) 383 | 384 | ### Précision irréaliste des données 385 | 386 | En dehors des sciences dures, peu de choses sont mesurées de manière routinière avec plus de deux décimales. Si un jeu de données prétend montrer les émissions d'une usine à la 7e décimale. Cela ne constitue peut-être pas un problème en soi mais il est important d'être transparent au sujet des estimations. 387 | 388 | ### Valeurs aberrantes inexplicables 389 | 390 | Les valeurs aberrantes donnent lieu à des erreurs statistiques, notamment lorsque des moyennes sont utilisées. Un bon réflexe est d’examiner chaque nouveau jeu de données pour déterminer les valeurs les plus grandes et les plus petites, et vous assurer que celles-ci se trouvent dans une fourchette raisonnable. Si les données le justifient, vous pouvez également effectuer une analyse plus rigoureuse sur le plan statistique. 391 | 392 | ### Un index masque la variation sous-jacente 393 | 394 | Les analystes qui veulent suivre la tendance d'un problème créent souvent des indices de diverses valeurs pour en suivre l’évolution. Il n'y a rien d’intrinsèquement mauvais dans l'utilisation d'un index. Ils peuvent avoir un grand pouvoir explicatif. Cependant, il est important de se méfier des indices qui combinent des mesures disparates. Par exemple, l'indice des inégalités de genre des Nations Unies combine plusieurs mesures liées aux progrès des femmes vers l'égalité. L'une des mesures utilisées est la « représentation des femmes au parlement ». Deux pays dans le monde ont des lois qui imposent la représentation des deux sexes dans leurs parlements : la Chine et le Pakistan. En conséquence, ces deux pays obtiennent de bien meilleurs résultats grâce à cet indice. 395 | 396 | ### Résultats piratés 397 | 398 | Le piratage peut consister dans la modification intentionnelle des données ou de l'analyse statistique, ou encore dans le signalement d’une sélection de résultats statistiquement significatifs. Si vous tombez sur ce type de cas, il faut arrêter de collecter des données une fois que vous avez obtenu un résultat significatif, supprimer des observations pour obtenir un résultat significatif, ou effectuer de nombreuses analyses et ne rapporter que celles qui seront les plus significatives. Quelques [bonnes informations ici] (http://fivethirtyeight.com/features/science-isnt-broken) à propos de ce problème. 399 | 400 | Si vous souhaitez publier les résultats d'une étude, vous devez comprendre ce qu'est la valeur P, ce qu’elle signifie puis prendre une décision éclairée quant à la pertinence de l'utilisation des résultats. 401 | 402 | Voir aussi : 403 | 404 | * [Marge d'erreur trop importante](#marge-d-erreur-trop-importante) 405 | 406 | ### Echec de la loi de Benford 407 | 408 | [La loi de Benford](https://fr.wikipedia.org/wiki/Loi_de_Benford) est une théorie qui dispose que les petits chiffres (1, 2, 3) apparaissent beaucoup plus fréquemment au début des nombres que les grands chiffres (7, 8, 9). En théorie, la loi de Benford peut être utilisée pour détecter des anomalies dans des pratiques comptables ou des résultats d’élections même si, dans la pratique, elle peut facilement être mal appliquée. Si vous pensez qu'un jeu de données a été créé ou modifié pour tromper, la loi de Benford est un excellent premier test, mais vous devriez toujours vérifier vos résultats avec un expert avant de conclure que vos données ont été manipulées. 409 | 410 | ### Trop bon pour être vrai 411 | 412 | Il n'existe pas de jeu de données global relatif à l'opinion publique. Personne ne connaît le nombre exact de personnes vivant en Sibérie. Les statistiques de la criminalité ne sont pas comparables d’un pays à l’autre. 413 | 414 | Méfiez-vous des données qui prétendent représenter quelque chose que vous ne pourriez pas parvenir à connaître. Ce ne sont pas des données. Il s’agit de l'estimation de quelqu'un et elle est probablement fausse. Mais aussi... cela pourrait être une bonne histoire : demandez à un expert de vérifier pour vous. 415 | 416 | ## Problèmes qu'un développeur peut vous aider à résoudre 417 | 418 | ### Données agrégées dans une mauvaise catégorie ou zone géographique 419 | 420 | Parfois, vos données présentent un bon niveau de détail (ni [trop grossier] (# donnees-grossieres) ni [trop granulaire] (# donnees-granulaires)), mais elles ont été agrégées dans un groupe différent de celui que vous souhaitiez. L'exemple classique est celui des données agrégées via des codes postaux que vous préfériez obtenir par quartier. Dans de nombreux cas, il s'agit d'un problème impossible à résoudre sans obtenir de votre source des données plus granulaires, mais parfois les données peuvent être mappées proportionnellement d'un groupe à l'autre. Cela ne doit être entrepris qu'avec une compréhension minutieuse de la [marge d'erreur] (#marge-d-erreur-trop-importante) qui peut être introduite dans le processus. Si vous avez agrégé des données dans des mauvais groupes, demandez à un développeur s'il est possible de les regrouper. 421 | Voir aussi : 422 | 423 | * [Données trop grossières](#donnees-grossieres) 424 | * [Données trop granulaires](#donnees-granulaires) 425 | * [Marge d'erreur trop importante](#marge-d-erreur-trop-importante) 426 | 427 | ### Données dans un document scanné 428 | 429 | Grâce aux législations réglementant l’accès aux données publiques, il est fréquent que les autorités soient obligées de vous fournir des données, même si elles ne le souhaitent pas vraiment. Une technique courante consiste alors à vous fournir des scans ou des photographies des pages de données. Il peut s'agir d’un fichier image (JPG, par exemple) ou, plus probablement, d'un fichier PDF. 430 | 431 | Il est possible d'extraire du texte à partir d'images et de le restituer en données via un processus de reconnaissance optique des caractères (OCR ou OCR-isation). Si cette technique permet la précision dans la plupart des cas, cela va dépendre aussi de la nature du document. Chaque fois que vous utiliserez OCR pour extraire des données, vous devrez mettre en place une procédure permettant de valider la correspondance des données avec le fichier original. 432 | 433 | De nombreux sites web proposent logiciels de conversion. Il existe également des outils gratuits qu’un développeur pourra adapter à des documents spécifiques. Si vous en avez un sous la main, demandez-lui la meilleure stratégie à adopter pour le document dont vous disposez. 434 | 435 | Voir aussi : 436 | 437 | * [Données au format PDF](#donnees-pdf) 438 | --------------------------------------------------------------------------------