Нормализация адресов и телефонов: сравниваем подходы

Нормализация — не то же самое, что поиск дублей

Номера «8 (916) 123-45-67» и «+7 916 123-45-67» можно привести к одному виду, но это не доказывает, что перед вами один и тот же клиент. А две записи «ул. Ленина, 5» могут относиться к разным городам. Если свести очистку формата и определение личности к одной операции, система либо пропустит дубли, либо объединит чужие записи.

Для телефонов есть международный ориентир — E.164. Для адресов единого универсального формата, который одинаково подходит всем странам и задачам, нет. Поэтому выбирайте не «самую умную нормализацию», а уровень обработки, соразмерный цене ошибки. Ниже — сравнение подходов для прикладных систем; команды и API конкретной библиотеки не рассматриваем. Версии телефонных метаданных и адресных справочников нужно фиксировать отдельно: они могут обновляться независимо от приложения.

Три подхода и их цена

1. Очистить написание

Минимальный вариант: убрать лишние пробелы, привести Unicode-текст к согласованной форме, унифицировать регистр там, где это безопасно, и убрать некоторые разделители. Телефон можно хранить только цифрами для поиска по введённому значению, сохраняя исходную строку отдельно.

Это быстро, дёшево и подходит для отображения или простого поиска. Но одинаковая строка не становится надёжным ключом: у телефонного номера теряется контекст страны, а у адреса — различие между названием улицы, населённым пунктом и корпусом. Удалять все знаки препинания подряд опасно: символы могут разделять значимые части номера или адреса.

2. Разбирать на поля и хранить каноническое представление

Телефон хранится как исходный ввод, разобранный номер с контекстом страны и представление в международном формате, если разбор успешен. Добавочный номер — отдельное поле: он не входит в международный номер E.164. Для такой обработки обычно используют телефонную библиотеку с актуальными метаданными; номер, который выглядит правдоподобно, всё равно не подтверждает, что он действующий или принадлежит указанному человеку.

Адрес разбирают на компоненты: страна, регион, город или населённый пункт, улица, дом, корпус, квартира и индекс — набор зависит от страны. Исходную строку сохраняют, а разобранные значения и результат проверки адресным справочником не подменяют друг другом. Справочник помогает сверить написание и существование объекта, но сам по себе не подтверждает, что человек там живёт.

Такой подход дороже: нужны поля, обработка неполного ввода и обновление справочников или метаданных. Зато система может искать по отдельным компонентам и объяснять, где разбор не удался.

3. Сопоставлять записи нечётко

Если нужно находить вероятные дубли, сравнивают не только итоговую строку. Для телефона учитывают международный номер и добавочный; для адреса — совпадение страны, населённого пункта, улицы и дома, а также варианты написания. Алгоритм возвращает кандидатов и оценку сходства, а не объявляет записи одной сущностью автоматически.

Этот вариант лучше справляется с опечатками и разным порядком компонентов, но требует настройки на ваших данных. Ошибочное объединение часто обходится дороже дубля: заказ, уведомление или история обращений могут оказаться привязаны не к той записи. Поэтому порог автоматического объединения должен зависеть от последствий, а пограничные случаи — уходить на проверку.

Нормализованное значение удобно сравнивать. Но оно не является доказательством, что две записи описывают одного человека или один адрес.

Как хранить данные, чтобы не потерять исходное

Не заменяйте исходный ввод результатом нормализации. Храните его рядом с разобранными полями — так можно повторить обработку после обновления правил, исправить ошибку парсера или разобраться, что именно ввёл пользователь.

• Исходное значение. Строка ровно в том виде, в котором она пришла от пользователя или интеграции.
• Нормализованное представление. Например, телефон в международном формате или отдельные компоненты адреса. Не записывайте сюда значения, полученные догадкой, как будто пользователь их подтвердил.
• Контекст разбора. Для телефона — страна, использованная при разборе; для адреса — страна и версия подключённого справочника, если он применялся.
• Статус и источник. Отмечайте, удалось ли разобрать значение, откуда пришла проверка и когда её выполняли. «Разобрано» и «подтверждено владельцем» — разные состояния.

Версионируйте не только код, но и данные, от которых зависит результат: телефонные метаданные, адресные справочники и правила сопоставления. Иначе после обновления один и тот же ввод может получить другой результат, а воспроизвести старое объединение будет трудно.

Когда какой подход выбирать

Нужен поиск, а не автоматическое объединение

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

Запись влияет на доставку или обслуживание

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

Нужно объединить накопленные дубли

Сначала запускайте сопоставление в режиме предложений: система выдаёт пары-кандидаты, человек подтверждает или отклоняет их. Измеряйте долю подтверждённых совпадений и долю пропущенных дублей на размеченной выборке из ваших данных. Пока вы не знаете цену ошибок на этой выборке, автоматическое слияние — не экономия времени, а перенос риска в продакшен.

Что ломается на практике

• Телефон без страны. Последовательность цифр может разбираться по-разному в зависимости от региона. Не подставляйте страну молча: сохраните источник контекста и отметьте, что он использован.
• Добавочный номер склеен с основным. Это затрудняет сравнение и может привести к неверному международному представлению. Храните добавочный отдельно.
• Пробелы и пунктуация удалены без разбора. Формат становится единообразным, но компоненты адреса теряются. Сначала определите структуру полей и правила для конкретных стран.
• Справочник принят за истину. Отсутствие адреса в базе не всегда означает, что адрес неверен. Показывайте источник и дату проверки, оставляйте путь для ручного подтверждения.
• Сходство превратилось в автоматическое слияние. Похожие адреса могут относиться к соседним квартирам, а номер телефона мог сменить владельца. Настройте пороги отдельно для поиска кандидатов и для любых необратимых действий.

Каноническое представление — согласованный формат значения для хранения или сравнения. Оно упрощает обработку, но не гарантирует, что само значение верно или уникально.

Что делать дальше

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