Як працювати з цифрами в журналістиці: корисні поради

Знайте питання, на які хочете отримати відповідь

Розглянемо як приклад дані про місцеву злочинність. Припустимо, що ви хочете написати статтю, яка розглядає типові закономірності злочинів у вашому місті, і твердження, які ви хочете зробити, включають дані про час доби та день тижня, у який найчастіше трапляються різні види злочинів, так само як і те, які райони міста є «гарячими зонами» щодо різних категорій злочинів.

Ви усвідомите, що ваш запит про дані повинен включати в себе дату та час повідомлення про злочин, вид злочину (вбивство, крадіжка, пограбування тощо), а також адресу місця скоєння злочину. Тож, Дата, Час, Категорія злочину та Адреса – це той мінімальний обсяг змінних, які потрібні вам, щоб отримати відповіді на ваші запитання.

Але майте на увазі, що є набір потенційно цікавих запитань, на які ваш набір даних із чотирьох змінних НЕ МОЖЕ ВІДПОВІСТИ, такі як раса та стать постраждалих, повна вартість вкраденого майна, або які офіцери поліції здійснюють найбільше арештів. Ви також, можливо, отримаєте записи лише щодо певного періоду часу, наприклад, за останні три роки, і це означатиме, що ви нічого не зможете сказати про те, чи змінювалися типові закономірності скоєння злочинів протягом довшого періоду часу. Ці запитання можуть не входити до «поля зору» вашої статті, і тоді все гаразд. Але вам навряд чи захочеться зануритися в аналіз даних і раптово вирішити, що вам потрібно знати, який відсоток злочинів у різних частинах міста закінчується арештом.

Звідси урок: часто виглядає гарною ідеєю робити запит про ВСІ змінні та записи в базі даних, а не про витяг з неї, який може дати відповіді до вашої поточної статті (насправді отримання всіх даних є дешевшим, ніж отримання вибірки, якщо вам доведеться платити агенції за програмування, пов’язане з вилученням цієї вибірки). Ви завжди можете отримати вибірку даних самостійно, а маючи доступ до повного набору даних, зможете знайти відповідь на нові запитання, які можуть постати під час вашої роботи над матеріалом, і навіть згенерувати нові ідеї для статей-продовжень. Може статися так, що деякі конфіденційні дані, такі, як імена жертв чи таємних інформантів поліції, за законом заборонено оприлюднювати. Але навіть часткова база даних значно краща, ніж ніякої бази даних взагалі, принаймні доти, доки ви розумієте, на які запитання ця відредагована база даних може дати відповідь, а на які ні.

Очистка невпорядкованих даних

Наприклад, основна функція бази даних системи кримінального правосуддя – це подбати, щоб обвинувачуваного Джонса доправили з в’язниці до судді Сміта у час розгляду справи. Для цієї мети не має великого значення те, що дата народження Джонса вказана неточно, що в назві вулиці помилка, або навіть те, що ініціали по батькові наведені невірно. Загалом система може використовувати навіть ці неідеальні дані, щоб доправити Джонса до суду під головуванням Сміта у призначений час.

Але такі помилки можуть спотворити спроби журналіста знайти певні узагальнення в цій базі даних. Через це найперша велика справа, яку вам слід зробити, отримавши нову базу даних, - це перевірка, наскільки впорядкованими є дані в ній, і виправлення цих даних. Гарний швидкий спосіб знаходити ці невпорядкованості – це створити таблицю частот категоріальних змінних, тих, які, як очікується, матимуть порівняно невелику кількість відмінних значень (використовуючи Excel, наприклад, це можна зробити за допомогою функцій Filter чи Pivot Tables по кожній із категоріальних змінних.

Розглянемо поле бази даних «Стать», це легкий приклад. Ви можете виявити, що ваше поле «Стать» містить будь-який із перелічених варіантів значень: наприклад, Чоловіча, Жіноча, Ч, Ж, 1, 0, ЧОЛОВІЧА, ЖІНОЧА тощо, включно з помилковим написанням, напр. «жиноча». Інша відома база даних, де спостерігаються подібні проблеми, - це записи фінансування виборчих кампаній в США. Тут у полі «Фах» може стояти «Юрист», «Адвокат», «Адв», «Правник» та аналогічне розмаїття варіацій та помилок правопису; знову ж таки, весь сенс у тому, щоб стандартизувати назви фаху, привівши їх до коротшого списку варіацій.

Очистка даних стає навіть більш проблематичною, коли справа доходить до імен. Чи є «Джозеф Т. Сміт», «Джозеф Сміт», «Т.Дж. Сміт», «Джоз. Сміт» та «Джо Сміт» однією й тією ж особою? Можливо, вам доведеться переглянути інші змінні, такі як адреса чи дата народження, або навіть провести глибше дослідження інших записів бази даних, щоб це з’ясувати. Але інструменти на зразок Google Refine можуть зробити завдання з очистки та стандартизації більш швидким та менш марудним.

Дані можуть містити незадокументовані особливості

Інший ключовий елемент словника даних – це пояснення усіх кодів, застосованих для певних полів. Наприклад, поле «Стать» може бути закодованим так, що 1 означає «Чоловіча», 0 – «Жіноча». Злочини можуть бути закодовані відповідно до статей кримінального кодексу по кожному виду злочину. Записи в базі даних лікарні можуть використовувати сотні 5-символьних цифрових кодів, що вказують на діагнози пацієнта, який проходив курс лікування. Без словника даних ці набори даних важко або навіть неможливо аналізувати належним чином.

Але навіть якщо словник даних у вас під рукою, можуть виникнути проблеми. Подібне сталося з репортерами флоридської газети Miami Herald кілька років тому, коли вони проводили аналіз відмінностей у важкості покарань, які різні судді призначали особам, заарештованим за водіння під дією алкоголю чи наркотиків. Журналісти отримали записи про покарання від судової установи та аналізували цифри за трьома полями із словника даних: тривалість тюремного присуду, тривалість попереднього ув’язнення та розмір штрафу. Ці цифри суттєво відрізнялися в різних суддів, даючи репортерам фактаж для статті про те, що деякі судді є суворими, а деякі – поблажливими.

Втім, близько 1-2 відсотків справ у кожного судді не містили записів про тюремний термін, тривалість попереднього ув’язнення чи штраф. Тож у діаграму, яка наводила співвідношення покарань по кожному судді, увійшла дуже незначна кількість справ, відмічених як «Покарання не призначено». Коли статтю та діаграму було опубліковано, судді буквально завили від обурення, заявивши, що Miami Herald звинуватила їх у порушенні закону штату, який вимагав, щоб кожна особа, визнана винною у водінні в нетверезому стані, повинна бути покарана.

Тож репортери знову повернулися до клерка з судової установи, який надав їм файл даних, і запитали, що було причиною цієї помилки. Їм пояснили, що «сумнівні» справи стосувалися незаможних підзахисних, заарештованих уперше. Зазвичай їм присуджувався б штраф, але в них не було грошей. Тож судді присуджували їх до громадських робіт, таких як прибирання сміття вздовж доріг. Як виявилося, закон, що вимагав покарання, був прийнятий вже після того, як створили структуру бази даних. Тож усі клерки в суді знали, що в їхніх даних нулі в усіх трьох полях «тюрма», «попереднє ув’язнення», «штраф» означали громадські роботи. Але це НЕ БУЛО позначено в словнику даних, і через це Miami Herald була змушена вносити виправлення до статті.

Урок із цієї ситуації: завжди запитуйте установу, яка надає вам дані, чи нема в цих даних якихось незадокументованих елементів: чи це новостворені коди, які не ввійшли до словника даних, зміна у форматуванні файлу чи будь-що інше. Крім цього, завжди переглядайте результати свого аналізу й запитуйте себе: «А чи має це сенс?» Репортери з Miami Herald створювали діаграму в умовах браку часу і були так зосереджені на визначенні середнього рівня суворості покарань у кожного з суддів, що не звернули уваги на кілька випадків, де покарань, здавалося, не було взагалі. Їм треба було запитати себе, чи таке взагалі можливе, що всі судді порушують закон штату, хай навіть у крихітних обсягах.