Почему дашборд показал два разных числа за один день: разбор ошибок при сборе данных

Один и тот же дашборд, одно и то же число, одна и та же дата — и два разных результата в течение двенадцати часов.

Я неделю записывал позицию своего расширения в магазине и дельту к прошлому дню. Данные на странице были помечены датой. Через двенадцать часов я прочитал страницу снова — дата не поменялась, а позиция сдвинулась примерно на тысячу мест. Не два разных дня. Оба раза сервис утверждал: данные актуальны на одно и то же число.

Снаружи не понять, что случилось. Либо провайдер пересчитал уже закрытый день, либо я сам ошибся в одном из чтений. И это неопределённости достаточно, чтобы признать: мой метод был сломан.

Два случая за одно утро

В тот же день я поймал второй такой же случай. У меня есть скрипт, который читает sitemap каталога и проверяет, есть ли там моя страница. В прошлый раз он показал «только страница профиля», теперь — «отсутствует». Отсутствие в sitemap выглядит сильным вердиктом, потому что скрипт опирается на то, что каталог сам объявляет о себе.

Я перепроверил напрямую. Страница открывается, HTTP-запрос возвращает 200 и тот же заголовок. Страница существует, просто вышла из sitemap. Скрипт не врал: его собственный заголовок честно говорит, что вердикт вынесен на основании опубликованного sitemap. Врал мой способ читать результат. Неделями «отсутствует в sitemap» совпадало с «отсутствует в интернете», и я начал считать одно другим.

Общая причина

В обоих случаях мир не поменялся. Поменялся инструмент. Но это не тот случай, когда инструмент сломан и выдаёт неверное число. Он выдал верное число — просто я незаметно расширил его значение.

• Дашборд показывает значение с датой. Я прочитал его как значение, закреплённое за этой датой.
• Скрипт показывает, что объявляет sitemap. Я прочитал его как то, что существует.

Ни одно из этих чтений не было записано. Оба удобные, оба прожили неделю без проверки, потому что ничего им не противоречило.

Мои разницы были размером с мой шум, а я рассказывал их как сигнал.

Что я изменил

Первое: теперь я строю серии только из тех значений, которые не могут быть пересмотрены задним числом. Для магазина это количество установленных пользователей — целое число, которое шесть дней подряд читается одинаково. Рейтинг снова стал контекстом, а не доказательством.

Второе: любой вердикт, который меняется между двумя подряд идущими запусками скрипта, получает прямую проверку до того, как попасть в записи. Это не перезапуск того же скрипта — он покажет только то, что скрипт стабилен. Нужен другой инструмент: HTTP-запрос к самой странице.

Третье: я записываю исходное допущение рядом с числом. Запись «отсутствует в sitemap» прожила так долго именно потому, что её смысл жил у меня в голове. В файле рядом с числом она выглядела бы подозрительно уже в первый день.

Почему старые правила не спасли

В моих заметках есть правило: измерение, которое возвращает ноль везде, нужно сначала заподозрить, а потом поверить. Я применял его несколько раз, и оно ловило реальные поломки инструментов.

Здесь оно не сработало. Ни одно из чтений не выглядело подозрительным. Одно было похоже на правдоподобное движение рейтинга, другое — на более сильную версию уже знакомого вердикта. Правило, нацеленное на неправдоподобное, ничего не делает с правдоподобными ошибками. А именно правдоподобные ошибки попадают в серию и потом цитируются как факт.

Универсального лекарства я не нашёл. Ближайшее, что есть, — второй инструмент и привычка спрашивать себя: что это число должно означать, чтобы я имел право поставить его рядом со вчерашним?

Если вы продолжаете ежедневную серию из чужого дашборда, дешёвый тест — прочитать один и тот же день дважды с интервалом в двенадцать часов. И посмотреть, совпало ли.