Определение оператора, HLR или проверка формата: выберите нужные данные о телефонных номерах

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

Используйте проверку формата для подготовки корректного номера, определение исходного оператора для получения контекста распределения, специализированные сервисы сетевых данных для вопросов о текущей сети и активную верификацию, если вам нужно доказательство того, что пользователь контролирует номер. Это разные задачи; ни один результат CarrierLookup не подтверждает доступность номера или владение им.

Начните с решения, которое вам необходимо принять

Команда по работе с данными может задаться вопросом, можно ли отправить строку в API, какой оператор изначально получил диапазон этого номера, может ли мобильная сеть обслуживать его в данный момент или контролирует ли его клиент. Объединение всех четырех задач под общим названием «проверка телефона» скрывает различия между локальной проверкой, записью о распределении, сетевым запросом и взаимодействием с человеком. Сначала определите вопрос, а затем приобретите или создайте проверку, которая на него отвечает.

Последние две строки требуют оценки отдельных сервисов. Провайдеры HLR различаются по определениям полей, географическому покрытию и актуальности данных. Проверка владения зависит от успешного взаимодействия с пользователем. Ни одна из этих возможностей не является частью сервиса определения исходного распределения CarrierLookup.

Что может сделать локальная проверка формата

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

Для API CarrierLookup в реальном времени идентификатор должен содержать знак «плюс», код страны и номер абонента без пробелов и разделителей. Отклоненный формат — это проблема ввода, а не доказательство отсутствия оператора у номера. И наоборот, синтаксически корректная строка E.164 не доказывает, что номер был назначен абоненту, активен, может принимать SMS или принадлежит человеку, который его ввел. Сохраняйте эти состояния в CRM отдельно: format_ready — это флаг подготовки, а не вердикт о возможности связи.

Что дает определение исходного оператора

Определение исходного оператора от CarrierLookup возвращает оператора, которому изначально был выделен диапазон номеров. Там, где это доступно, сервис также возвращает данные об основном операторе, типе номера, коде страны, регионе и городе распределения. Регион и город описывают географию распределения диапазона номеров, а не текущее местоположение пользователя или устройства. Поле оператора является историческим контекстом распределения, даже если номер был впоследствии перенесен.

Сервис поддерживает одиночные запросы в реальном времени, синхронные мультизапросы для 1–100 номеров и отдельный асинхронный файловый сервис для больших списков. Термин «в реальном времени» описывает скорость возврата ответа в рабочем процессе; это не означает зондирование сети в реальном времени. Документация API различает эти маршруты и структуру их результатов. Для конвейера обогащения данных храните исходное значение телефона, нормализованный ввод, результат проверки и поля распределения в отдельных столбцах. Не перезаписывайте поле current_carrier значением carrier из ответа об исходном распределении.

Пустое поле оператора требует осторожного обращения. Завершенный запрос с code=0 может вернуть пустые поля распределения; это все равно завершенный запрос, а не доказательство того, что номер недействителен или отключен. Неопределенная ошибка приложения — это другой результат. В результатах синхронных мультизапросов exists=false означает отсутствие нормального результата для этого элемента, а не отрицательный статус сети. Эти различия предотвращают превращение отсутствующего значения данных в необоснованную метку «недоступен».

Когда вопрос о сети или владении требует другого источника

Номер может сохранять запись об исходном распределении после того, как переносимость (MNP) изменила обслуживающую сеть. Если решение зависит от маршрутизации, классификации текущей сети или сигнала состояния сети, оцените провайдера, который документирует именно этот сигнал и его ограничения. Отраслевые сравнения обсуждают запросы типа HLR для получения информации о мобильной сети; они не делают каждое определение оператора проверкой HLR. Например, Tata Communications объясняет HLR lookup в контексте обмена сообщениями, а Didit сравнивает HLR и SMS OTP для принятия решений о верификации. Их продукты и заявления следует оценивать на основе их собственной документации, а не переносить на CarrierLookup.

Если бизнес-решение звучит как «получил ли пользователь проверочный код и ввел ли его?», используйте подходящий процесс активной верификации. Результат сетевых данных не является ответом человека. Даже успешное завершение проверки является доказательством контроля в рамках этого взаимодействия, а не постоянной записью об идентичности или согласии. Храните события верификации, их временные метки и любые записи о согласии отдельно от обогащения данных о распределении.

Небольшой тест для покупателя, предотвращающий неверную покупку

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

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

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

Выберите обоснованный следующий шаг

Если ваша непосредственная потребность — контекст исходного оператора и типа линии для подготовленного списка, изучите задокументированные поля и маршруты запросов CarrierLookup, а затем протестируйте небольшую авторизованную выборку по оценочному листу, специфичному для распределения. Если вам нужен статус текущей сети или доказательство контроля пользователя, четко задокументируйте это требование и оцените соответствующий отдельный сервис или процесс верификации. Маркируйте каждый ответ тем, что он измеряет на самом деле, прежде чем он попадет в правила CRM.

Узнайте больше

Выберите информацию о продукте, которая соответствует следующему шагу в вашем рабочем процессе.

• Посмотреть документацию по продукту →
• Связаться с командой →