Введение
Качество и валидность телефонных номеров — незаметная, но постоянная проблема электронной коммерции. Номера, собранные при оформлении заказа, часто некорректно сформированы, непоследовательно отформатированы или принадлежат линиям, которые не могут получать SMS, и обычно вы узнаёте об этом только когда уведомление о доставке не доставляется.
В этой статье объясняется, как выполнить очистку данных телефонных номеров с помощью инсайта format (нормализовать каждый номер в формат E.164), а затем провести валидацию с помощью инсайта current_carrier (подтвердить, что номер является мобильным и может обычно получать SMS). Vonage Identity Insights API возвращает и очищенный номер, и подтверждение возможности приёма SMS в одном вызове API. Совместное использование инсайтов format и current_carrier из Identity Insights API даёт вам способ очистить каждый номер до формата E.164 до того, как он попадёт в вашу базу данных, и подтвердить, что он мобильный, прежде чем полагаться на него для коммуникаций о доставке.
Сбои очистки и валидации
Типичный бэкенд-сценарий: покупатель, заполняя форму оформления заказа, вводит свой номер телефона в том формате, который ему естественно приходит в голову, и подтверждает размещение заказа. HTML5-поле ввода типа telephone принимает его. Серверное регулярное выражение подтверждает, что в нём десять цифр. Заказ записывается в базу данных, отправляется подтверждающее письмо и выполняется отправка SMS о доставке.
Затем ничего не происходит: не регистрируется ошибка, не запускается повторная попытка, не срабатывает оповещение. Через несколько дней покупатель открывает обращение в поддержку с вопросом, где его заказ. Звонок WISMO (Где мой заказ?) стоит вашей команде реального времени и денег, и его можно было полностью избежать. У сбоя есть две скрытые причины:
- Сбой очистки: номер был сохранён в национальном формате (4155551234) вместо E.164 (+14155551234).
Сбой очистки: номер был сохранён в национальном формате (4155551234) вместо E.164 (+14155551234).
- Сбой валидации: даже если формат правильный, номер принадлежит стационарной линии или номеру, который когда-то был мобильным и в прошлом месяце был перенесён оператору стационарной связи. Ваше регулярное выражение видит десять цифр и пропускает его. Статическая таблица поиска видит первоначальное распределение оператора и говорит «мобильный». SMS о доставке ставится в очередь и возвращается, так и не достигая телефона покупателя.
Сбой валидации: даже если формат правильный, номер принадлежит стационарной линии или номеру, который когда-то был мобильным и в прошлом месяце был перенесён оператору стационарной связи. Ваше регулярное выражение видит десять цифр и пропускает его. Статическая таблица поиска видит первоначальное распределение оператора и говорит «мобильный». SMS о доставке ставится в очередь и возвращается, так и не достигая телефона покупателя.
Валидация телефонных номеров
Валидация телефонного номера означает подтверждение того, что строка цифр является реальным, доступным телефонным номером, на который придёт SMS или голосовой вызов. Узнайте о валидности телефонных номеров.
Регулярное выражение выявляет неправильную длину номера, нецифровые символы, отсутствующий код города. Регулярное выражение не различает мобильный и стационарный номер, виртуальные/VoIP номера.
Поиск оператора и ответы Identity Insights API
Поиск оператора — это запрос к актуальному графу маршрутизации мобильной сети: какой оператор в данный момент владеет этим номером и к какому типу линии он относится? Вы можете обратиться к справочнику Identity Insights API, чтобы узнать о ключевых полях, возвращаемых вызовами Identity Insights API. Успешный ответ выглядит так:
Примечание: в отличие от сетевых инсайтов, таких как SIM Swap или Location Verification, инсайты format и current_carrier не требуют одобрения Network Registry. Они доступны по всему миру без дополнительного подключения операторов.
Примечание: в отличие от сетевых инсайтов, таких как SIM Swap или Location Verification, инсайты format и current_carrier не требуют одобрения Network Registry. Они доступны по всему миру без дополнительного подключения операторов.
Начало работы с Identity Insights API
Самый быстрый способ увидеть это в действии — учебное руководство Начало работы с Identity Insights в панели управления Vonage. Введите любой номер телефона, выберите format и current_carrier и посмотрите ответ в реальном времени. Также есть демонстрационный режим с предопределёнными номерами, если вы хотите поэкспериментировать без использования реального номера и увидеть ответ в реальном времени. Также есть демонстрационный режим с предопределёнными номерами, если вы хотите поэкспериментировать без использования реального номера.
Начало работы с Identity Insights
Настройка Identity Insights в проекте Node.js
Вы можете применить на практике теорию, которую узнали сегодня: нормализовать номер в формат E.164, подтвердить, что номер мобильный, перед постановкой SMS о доставке в очередь, и интегрировать шаг валидации в маршрут экспресс-оформления заказа. У нас есть Vonage Identity Insights SDK for Node.js. См. документацию Vonage Identity Insights API и Identity Insights SDK for Node.js для полного справочника SDK.
Часто задаваемые вопросы
Вопрос 1. Как аутентифицироваться в Identity Insights API?
Identity Insights API использует JWT-аутентификацию через приложение Vonage. Создайте приложение в Vonage Dashboard, скачайте закрытый ключ и инициализируйте SDK с вашим applicationId и путём к файлу private.key. Это отличается от паттерна API-ключа/секрета, используемого более старыми API Vonage.
Вопрос 2. Почему Identity Insights API возвращает другого оператора, чем моя существующая библиотека валидации телефонных номеров?
Identity Insights API запрашивает актуальные данные маршрутизации операторов, а не статическую таблицу распределения номерных диапазонов. Если покупатель перенёс свой номер от оператора стационарной связи к мобильному оператору после последнего обновления вашей статической библиотеки, Identity Insights API вернёт текущего оператора, а статическая библиотека — исходного. Для перенесённых номеров current_carrier всегда является авторитетным ответом.
Вопрос 3. Можно ли использовать Identity Insights API для валидации международных телефонных номеров при оформлении заказа?
Да. Identity Insights API охватывает номера по всему миру. Передавайте номер в формате E.164 (с префиксом + и кодом страны) для наилучших результатов. Поле format.number_international в ответе даёт вам нормализованную версию E.164 независимо от того, как покупатель ввёл номер при оформлении заказа.
Вопрос 4. Замедляет ли вызов Identity Insights API при оформлении заказа отправку формы заказа?
Типичный вызов выполняется за 200–500 мс. Запускайте его на стороне сервера после того, как покупатель нажмёт «Отправить», и до записи в базу данных. Кэшируйте результат в сессии, чтобы не вызывать API дважды, если покупатель повторно введёт тот же номер телефона в той же сессии. Добавьте корректный тайм-аут и запасной вариант, позволяющий завершить оформление заказа, даже если сервис временно недоступен.
Заключение
Многое может случиться с командами электронной коммерции, если телефонные номера не очищаются и не валидируются должным образом. Звонки в поддержку WISMO (Где мой заказ?) могут резко возрасти, а возвраты платежей увеличиваются, когда номера телефонов, сохранённые при оформлении заказа, содержат ошибки или стационарные номера выдают себя за мобильные.
При работе с API Vonage убедитесь, что ваш конвейер оформления заказа нормализует номер телефона в формат E.164 и проверяет оператора с помощью текущего оператора перед передачей его в Vonage Messages API для доставки SMS. Если вам нужно перейти к проверке на основе OTP для заказов с высоким риском, Vonage Verify API станет естественным дополнением к тому же конвейеру оформления заказа.
