Данные в нашей CRM неполные и с дублями: не будет ли прогноз мусорным?
Идеальных баз данных не бывает. Разбираем, почему первые 30% проекта уходят на аудит и очистку, и как модель находит устойчивые закономерности даже в шумных массивах.
Спрос на предиктивную аналитику по клиентской базе растёт, и первый вопрос заказчика теперь не про алгоритм, а про качество исходных данных
Вопрос, который нам задают почти на каждом первом созвоне про предиктивную аналитику: «У нас в CRM бардак - дубли контактов, половина полей пустая, менеджеры пишут кто во что горазд. Вы прогоните это через дорогой алгоритм и получите такой же мусор на выходе, только за наши деньги. Разве нет?»
Опасение честное, и мы его уважаем. Но за ним стоит одно неверное допущение: будто для аналитики нужна чистая база. Чистой базы не существует ни у кого. Разберём, что реально происходит с грязными данными и где проходит граница между «шумно, но рабочее» и «действительно мусор».
Идеальных данных не бывает
За годы работы мы не видели ни одной корпоративной базы, которая была бы полной и непротиворечивой. Дубли контактов, разные написания одной компании, пустые поля, суммы сделок с опечаткой в разряде, даты из будущего - это норма, а не признак того, что у вас что-то запущено сильнее обычного. Если бы условием запуска была чистая CRM, предиктивная аналитика не работала бы нигде.
Поэтому первые примерно 30% времени любого проекта уходят не на модель, а на данные. Это не накладные расходы, которые хочется сократить, это фундамент, без которого остальные 70% бессмысленны.
Что происходит в эти 30%
Работа с сырыми данными разбивается на несколько понятных шагов.
Дедупликация. Схлопывание дублей - первое, с чего начинаем. Один и тот же клиент, заведённый тремя менеджерами как три записи, ломает любую статистику по клиенту. Сведение таких записей в одну - отдельная задача, и решается она не вручную, а правилами сопоставления по совокупности полей.
Нормализация. «ООО Ромашка», «Ромашка ООО» и «romashka» - это одна компания. Приведение к единому виду названий, телефонов, адресов делает поля пригодными для сравнения.
Фильтрация аномалий. Сделка на сумму в тысячу раз больше средней, возраст клиента 200 лет, дата регистрации позже даты последней покупки - это выбросы, которые надо либо исправить, либо исключить из обучения, иначе они утянут модель за собой.
Работа с пропусками. Пустое поле - это тоже информация. Иногда пропуск заполняется по смыслу, иногда сам факт пропуска становится полезным признаком. Что важно: мы не выдумываем данные, которых нет.
Почему шум - это не приговор
Ключевое, что снимает исходный страх: модель ищет не отдельные записи, а устойчивые закономерности в массе. Одна опечатка или один дубль не сдвигают прогноз, потому что решение принимается по тысячам примеров, а не по одному. Статистическая модель по своей природе терпима к случайному шуму - он усредняется.
Опасен не случайный шум, а систематическая ошибка. Если менеджеры полгода не заполняли поле «причина отказа», модель не сможет опереться на этот признак - но она честно покажет, что признака нет, а не подставит выдумку. Разница между грамотным проектом и «мусорным прогнозом» ровно здесь: в первом случае мы знаем пределы данных и не обещаем того, что они не выдержат, во втором - гонят сырую базу в модель без аудита и верят цифре на выходе.
Где реальная граница
Честно про то, когда данные действительно не тянут прогноз:
- Признака, который нужен для задачи, в данных нет вообще и взять его неоткуда. Тогда мы говорим об этом сразу, а не делаем модель, которая делает вид, что предсказывает.
- Данных слишком мало. Полсотни сделок - это не выборка для обучения, это повод сначала накопить историю.
- Данные систематически смещены. Если в базе только успешные сделки, модель не научится отличать их от неуспешных.
Во всех трёх случаях проблема не в грязи, а в отсутствии сигнала. Это выясняется на аудите, до того как заказчик потратил бюджет на моделирование.
Итого
Грязная CRM - это не препятствие для аналитики, а нормальная стартовая точка. Мусорный прогноз получается не из-за несовершенства данных, а из-за пропущенного этапа их аудита и очистки. Мы этот этап не пропускаем и не прячем: первые 30% проекта прозрачны, и по их итогам видно, что данные реально могут, а что нет.
С этого и стоит начинать - с аудита фактического состояния данных, а не с выбора алгоритма. Он и покажет, насколько ваша база готова к прогнозам и что нужно поправить в первую очередь.