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