Как восстановить клиентские данные, в которых достоверной нельзя было считать ни одну строку? Специалисты компании Loginom разработали 19 стратегий дедупликации и очистили проблемный массив объемом 5.7 млн записей.
Заказчик — один из крупнейших ритейлеров в России.
Компания планировала запустить программу лояльности. Для этого требовалась клиентская база, которая позволяла бы идентифицировать участников программы и обращаться к ним адресно.
Объем основного массива клиентских данных — более 90 млн записей.
Из-за ошибки в одном из регистров хранения часть клиентской базы оказалась «перемешана».
Проблемный массив содержал около 20 полей: ФИО участника программы лояльности, электронную почту, мобильный и городской телефоны, дату рождения, сведения о регистрации, картах, покупках и другие атрибуты.
Одно и то же значение могло встречаться в большом количестве записей. Например, один номер мобильного телефона был указан в 2–80 разных строках. Аналогичная ситуация наблюдалась с адресами электронной почты и другими атрибутами.
В проблемном массив было 5.7 млн записей. Выделить хотя бы одну строку, данные в которой можно было бы считать достоверными, было невозможно.
Простое удаление дублей неминуемо привело бы к потере большей части данных. Перед специалистами компании Loginom стояла задача выяснить, какие записи относятся к одному клиенту, а затем объединить их таким образом, чтобы сохранить максимально возможное количество достоверной информации.
У заказчика и команды партнера было предложение по решению. Оно предполагало использование относительно простых правил, в том числе сопоставление по номеру мобильного телефона.
Специалисты Loginom предложили другой подход: сначала расширить набор используемых атрибутов, а затем с помощью нескольких стратегий дедупликации нормализовать данные.
После очистки отдельных атрибутов могли появляться совпадения, которых не было видно в исходных данных. Ошибки в номере телефона или других полях могли мешать обнаружить записи одного клиента.
Изначально специалисты Loginom предложили 12 стратегий дедупликации. Их планировали последовательно применять к массиву, чтобы на каждой стадии находить новые потенциальные совпадения.
В процессе работы выяснилось, что этого недостаточно. В итоговом варианте решения использовали 19 стратегий. Они позволили выделить группы записей, относящихся к одному клиенту.
Важно, что дедупликация в данном случае — не простое объединение строк, а именно поиск кандидатов на слияние. После формирования таких групп требовалось определить, каким образом объединять найденные записи.
Следующим этапом стало формирование эталонной записи — в нее должна была попасть информация из остальных строк группы.
Совместно с командой заказчика специалисты Loginom сформировали набор правил для определения мастер-записи и применили его ко всему массиву.
Одним из ключевых критериев стал статус карт клиента. Карты имели разные статусы, и более высокий повышал вероятность того, что соответствующая запись должна стать мастер-записью.
После определения мастер-записей требовалось решить, какие значения из остальных полей переносить в них.
Для этого сформировали отдельные правила обогащения данных. Они определяли, как сравнивать значения в мастер-записи и остальных записях и какое значение считать приоритетным для каждого поля.
В результате для каждого атрибута был определен набор правил, по которым в итоговую запись переносилась наиболее достоверная информация из объединяемой группы.
В результате обработки 5.7 млн исходных записей были объединены в 1.2 млн. При этом небольшое количество записей не удалось объединить с другими.
Окончательная проверка качества данных выполнялась на стороне заказчика. После проверки очищенного массива заказчик подтвердил качество результатов и произвел оплату по договору.
Очистка проблемного массива была первой задачей проекта. Далее необходимо было нормализовать 90 млн записей клиентской базы. Основным вызовом стал объем данных и необходимость выполнить обработку за разумное время. Loginom позволяет эффективно работать с такими объемами данных.
Дополнительную сложность создавал способ формирования клиентской базы. Участники программы лояльности самостоятельно вводили сведения на сайте, в приложении или сообщали их сотрудникам магазина. Поэтому в исходных данных встречались пропуски, некорректные значения и текст, не соответствующий содержимому отдельных полей.
Эти данные также очистили и нормализовали для дальнейшей работы. При этом был сохранен максимально возможный объем информации.
Проект оказался необычным прежде всего из-за проблемного массива. В обычной ситуации можно определить ключевые поля и использовать их для поиска дублей. Здесь такой возможности не было: ошибки затрагивали практически все атрибуты, а одно и то же значение могло встречаться у множества клиентов.
Поэтому решение не основывалось на одном идентификаторе: для поиска совпадений последовательно применяли несколько стратегий дедупликации.
В результате очистка превратилась в комплексную процедуру восстановления клиентских записей, в которой требовалось учитывать как особенности самих данных, так и специфику программы лояльности заказчика.
Другие материалы по теме:
Как быстро и без программистов реформировать пополнение e-commerce. Кейс SUNLIGHT
Запись вебинара «Как потратить бюджет на ИИ и не добиться ничего»
