Базы телефонов для Казахстана обычно собирают из нескольких источников, поэтому в них встречаются повторные записи, разные варианты написания одного номера, устаревшие контакты и неверная разбивка по сегментам. Особенно это заметно в выборках по страхованию, микрофинансированию, доставке еды, торговле, образованию и ставкам: один и тот же мобильный номер может попасть в разные списки, хотя канал связи и актуальность остаются неизвестными.
Проверка базы на дубликаты и битые номера нужна, чтобы точно отделить пригодные контакты от технического шума. Она включает нормализацию, дедупликацию, проверку принадлежности и доступности, а затем документирование решений. Результат помогает корректно считать охват и не отправлять повторные сообщения одному и тому же контакту.
Дубликат — не просто две строки с одинаковыми цифрами. Записи могут различаться пробелами, скобками, кодом оператора, городом или служебными пометками, хотя относятся к одному контакту. Одновременно существуют легальные совпадения: два человека используют один офисный телефон, а у клиента бывает несколько SIM-карт. Их нельзя автоматически объединять.
Битный номер может быть неверным по формату, отключённым, несуществующим или просто недоступным во время проверки. Эти причины требуют разных действий: исправления, архивирования, повторной проверки или осторожного использования. Сравнение обычно выглядит следующим образом.
| Критерий | Что обнаружить | Как поступить |
|---|---|---|
| Полное совпадение | Одинаковые цифры в нескольких строках | Объединить метаданные, сохранить один экземпляр |
| Совпадение после нормализации | Разное написание одного номера | Сопоставить по единому формату и проверить источник |
| Ошибка формата | Неверная длина, лишние символы, недопустимый префикс | Очистить или отклонить запись |
| Неактивность по данным оператора | Номер отключён или не существует | Архивировать с датой проверки |
| Неизвестный статус | Нет достоверного ответа о доступности | Не считать номер гарантированно активным |
Географическая метка не подтверждает место проживания. Номер с кодом Алматы может использоваться в Астане, а городской телефон — принимать мобильные звонки. Если в базе указан город, его стоит проверять как поле сегментации, не выводя из него актуальность или принадлежность абонента.
При выборе данных из каталога клиентских баз полезно уточнять доступные фильтры по городу, району и профилю клиента, а также дату выгрузки. Исходный файл стоит сохранять до очистки: только так можно отследить, какие решения были приняты и какие контакты вернулись после ручной сверки.
Сначала приведите телефоны к единому представлению. Для казахстанского мобильного удобно использовать международный формат с кодом +7, без пробелов и служебных символов; исходное значение при этом не перезаписывайте. Начальную цифру 8 обычно заменяют на 7, но код +7 нельзя добавлять к номерам из других стран. Добавочные номера и комментарии лучше вынести в отдельные поля.
После нормализации ищите совпадения. Точное совпадение означает, что две записи содержат один и тот же номер. Совпадение после очистки может выявить старый формат, добавление кода города или опечатку в одной строке. Для каждой группы сохраняйте источник, дату сбора и историю контактов: иногда повторная строка содержит более свежие сведения, которые нельзя потерять.
На этапе группировки учитывайте другие идентификаторы: имя, компанию и источник записи. Объединение одинаковых нормализованных номеров позволяет собрать сведения о клиенте в одном месте, не стирая историю отдельных строк. Если же совпадение обнаружено из-за ошибки сегментации, это следует исправить вместе с первичными данными.
Близкие, но разные номера требуют осторожности. Алгоритм нечёткого совпадения способен обнаружить опечатку в одной цифре, однако два соседних номера могут принадлежать разным людям. Автоматически объединяйте только записи с подтверждённым совпадением; сомнительные пары отправляйте на ручную сверку. Не удаляйте повтор, если он относится к отдельной кампании: сначала устраните дублирование внутри исходной выгрузки, а затем учитывайте контакт в журнале отправок.
Синтаксическая проверка отсеивает невозможные длины и префиксы, но не подтверждает, что SIM-карта активна. Для более точной оценки применяют HLR-запрос, который возвращает сведения оператора и текущий статус номера. Справочник может быть неполным или устаревшим, поэтому его ответ нужно считать подтверждением доступности лишь на момент запроса.
Статус меняется: номер могли отключить, перевыпустить или временно заблокировать. Поэтому дата проверки — обязательная часть результата. Данные, полученные несколько месяцев назад, полезно перепроверять перед новой крупной кампанией, особенно для чувствительных сегментов.
Звонок или тестовое SMS помогают проверить канал на практике. Делать такие проверки следует только в рамках законных целей обработки данных и с учётом согласия на контакт. Недоступный во время теста номер не всегда отключён: абонент может не брать трубку, временно не иметь сети или использовать другую SIM-карту. Для общения через WhatsApp и Telegram нужна отдельная проверка регистрации аккаунта; наличие мобильного номера этого не гарантирует.
Для международной выборки нельзя применять казахстанские правила без проверки страны происхождения. В отдельном контуре существует маскирование португальских номеров; такая обработка не заменяет валидацию казахстанских телефонов. Если база смешанная, храните код страны и локальный номер отдельно, иначе разные международные контакты могут ошибочно выглядеть как повторы.
Оценивайте качество по нескольким независимым показателям. Технический дефект, неактивный номер и неизвестный статус имеют разную ценность для менеджера, который планирует звонок или рассылку. Поэтому сводку лучше строить по каналам, а не смешивать все записи в один общий процент «годных» контактов.
Что измерять перед очисткой
Что сохранять в журнале
Отчёт удобно строить по датам: старые и новые выгрузки сравниваются по объёму, доле повторов и числу неактивных записей. Так видно, улучшается ли источник и не растёт ли нагрузка на повторные сообщения.
Процент отбраковки сам по себе не показывает качество источника. Много повторов может объясняться повторной загрузкой одного набора, а много неизвестных статусов — устаревшим операторским справочником. Отдельный отчёт по сегментам помогает заметить проблему в конкретном городе, отрасли или диапазоне номеров и принять решение без затрагивания всей базы.
Сначала зафиксируйте состав исходной выгрузки и создайте её резервную копию. Затем преобразуйте номера в единый формат, удалите технические символы и сформируйте группы совпадений. Только после этого переходите к проверке статуса и доступности в нужном канале: так платные внешние запросы не выполняются для заведомо ошибочных или повторных записей.
Проверку полезно повторять по расписанию, а не только при импорте. Для быстро устаревающих контактов задают более частый цикл, для стабильных сегментов — реже. Каждое обновление журнала должно сохранять историю: иначе невозможно понять, улучшился ли контакт или сменился его статус.
Массовую отправку стоит начинать с очищенного сегмента и сверять его с журналом проверки. Номера с неизвестным статусом можно держать в отдельной очереди для повторной проверки, а отказы и запреты исключать из дальнейших коммуникаций. Наличие телефона само по себе не означает согласие на звонок или рекламную рассылку, поэтому основание для контакта должно сохраняться вместе с записью.
Готовый к применению сегмент состоит из уникальных в пределах выгрузки нормализованных номеров с подтверждённой доступностью в выбранном канале и зафиксированным основанием для контакта. Остальные записи остаются в прозрачном архиве с датой, методом проверки и причиной отбраковки — именно этот порядок даёт надёжный результат без повторных обращений и искажения статистики.