Фильтруй, но проверяй: или дело о пропавших из отчетов клиентах 😱

В одной компании, где я раньше работала, существовал скрипт, который:
1️⃣ перебирал всех зарегистрировавшихся в сервисе клиентов
2️⃣ по ряду признаков помечал их либо как целевых (1), либо как нецелевых (0)
3️⃣ записывал в таблицу с этим признаком

Источники под всеми отчетами в компании дополнительно соединялись с этой таблицей, чтобы исключить нецелевые регистрации и не просаживать конверсии

В какой-то момент мы стали замечать, что некоторых клиентов, которые должны были попадать в один важный отчет, там нет. Я откопала скрипт, посмотрела на его логику и увидела проблему в одной коварной строчке… 🙂

К нецелевым регистрациям в том числе относились тестовые аккаунты, поэтому одной из строк была:

LOWER(name) NOT LIKE '%test%'

Т.е. имя (name) в нижнем регистре не содержит вхождение подстроки test. Это отсекало всех Test, testtest, TEST, Name Test и другие похожие варианты

Но с желанием вычистить тестовые аккаунты таким способом, были также исключены аккаунты со словами Latest, Greatest, Contest и так далее 🤓

Когда мы пишем условие для исключения значений по какому-то паттерну через NOT LIKE, мы не видим, что именно отсеклось. Мы видим только готовый чистенький результат

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

LOWER(name) LIKE '%test%'

Если бы автор скрипта сделал подобную проверку, то сразу заметил бы проблему

А вы сталкивались с пропажей данных из-за некорректных условий в запросе?

#sql_анна_в_данных