¶ Как CRM-система проверяет телефон на валидность
Номера телефонов в CRM приходят в специальное поле с типом данных "Телефон". К этому полю встроена проверка на валидность значения номера телефона.
Проверка осуществляется через Google библиотеку https://libphonenumber.appspot.com/
¶ Как работает проверка по библиотеке
Вы можете вручную сделать то же самое.
- Откройте ссылку выше
- Введите номер телефона и двухбуквенный код страны и нажмите Submit
После этого вы получите страницу с результатом валидации. В ней обратите внимание на блок "Validation Results" и особенно на третью строчку. Если вы видите знаете true, значит номер валидный.
Теперь посмотрите, как выглядит результат для невалидного номера.
Можно внести номер телефона и код страны по главной ссылке или просто заменить значение номера в URL
Библиотека показала, что номер телефона невалидный.
Не путайте невалидный номер - с номером без кода, без плюса, введенным в локальном варианте и тд. То есть факт ввода номера телефона с плюсом или без, с кодом или без, с нулем впереди (стандарт для ввода в локальном формате) или без нуля не делает номер невалидным. Невалидный номер - это именно несуществующий номер.
На данном этапе возникает много вопросов от клиентов CRM-системы:
- CRM не сохранит заказ с невалидным номером?
- я хочу видеть все свои заказы, даже невалидные
- как убрать встроенную валидацию?
- как сделать свою собственную валидацию?
- поймет ли CRM-система, по какой стране проверять номер телефона, если продажи идут в разных странах?
И другое. Ниже мы привели ваши часто задаваемые вопросы и ответы на них.
¶ Придет ли в CRM заказ с невалидным номером телефона?
Зависит от того, как настроен ваш сайт.
У нас есть 2 типа API (API CRM и API CPA)
API CRM - это более широкое API, его еще называют админским. С этим API можно сделать всё, как будто у вас есть доступ к CRM-системе. В нем можно установить запреты, для этого нужно создать специальную роль для API-токена, установив куда ему можно и куда нельзя. Это API не сохраняет заказ с невалидным номером телефона, то есть такой заказ не поступит CRM-систему.
API CPA - это API только для добавления заказов, его называют вебмастерским. С ним можно создавать заказы и получать информацию об их статусах. Это API дает сохраняет заказ с невалидным номером телефона, но записывает номер телефона не в специальное поле с телефоном, а в поле "Ошибки.
То есть все заказы с невалидными номерами телефона попадают в CRM, если интеграция сделана по API CPA. Если сайт настраиваем вам мы, то обычно мы делаем настройку именно по этому API.
Чтобы проверить, как именно сделано у вас, сделайте тестовый заказ с вашего сайта с невалидным номером телефона, указав "1234" и если заказ поступит, то значит все невалидные номера у вас фиксируются. Если не поступит, значит интеграция сделана по API CRM.
¶ А что если я хочу видеть все свои заказы, даже с невалидными номерами телефонов
Напишите в нашу службу поддержки, мы поможем перенастроить интеграцию с вашим сайтом на API CPA и вы начнете получать все заказы.
Напомним, что невалидные номера телефонов все равно будут отображаться лишь в поле "Ошибки", но не в поле "Телефон". Это логично, ведь по этому значению все равно нельзя позвонить.
Однако вы можете попытаться угадать корректный валидный номер и сохранить его в поле "Телефон".
¶ Как убрать встроенную валидацию?
Убрать встроенную валидацию нельзя.
Тип поля "Телефон" имеет свою логику: по нему можно делать звонки, писать сообщения, определить код страны если вы работаете с несколькими странами, настраивать маски под автоматическую ротацию провайдеров телефонии.
Весь этот функционал доступен только для валидных номеров телефона, поэтому каждый номер телефона валидируется, перед тем как сохраниться в этом поле. Отключить встроенную валидацию в CRM-системе по Google библиотеке нельзя.
¶ Как настроить свою валидацию?
Вы можете корректировать номера телефонов триггерами (правилами автоматизации) или настроить валидатор на проверку номеров телефона или настроить систему определения дублей. Но заменить нашу встроенную валидацию никак нельзя, она первична.
Если у вас есть вопросы, более конкретно опишите их в нашу техподдержку.
¶ Если на сайте вводят номер без кода, это будет считаться невалидным номером телефона?
Если посетитель сайта внес свой номер телефона без кода, CRM-система сама подставит код страны.
Наша CRM-система не посчитает номер телефона невалидным, если он внесен в местном формате. Вы можете лично убедиться в этом по ссылке Google библиотеки. Вносите номер в местном формате и проверьте результат.
¶ Если ввели номер без кода, а я работаю на несколько стран, как CRM поймет, код какой страны вводить?
В настройках поля "Телефон" есть выбор стран, в которых вы работаете.
Когда поступает заказ без кода, с номером телефона в местном формате (часто начинается с 0), то CRM-система проверяет поступивший номер на валидность каждой страны и подставит наиболее подходящий.
Если у вас возникла ситуация, что номер телефона существует для разных стран одновременно, то вам нужно:
- либо при передаче заказа по API передавать приоритетную страну в поле country, например для Индии
"country": "IN" - либо передавать номер телефона уже с кодом страны
¶ У меня на лендинге установлена маска, значит клиент ввел все точно корректно. А в CRM номер телефона попадает в "ошибки". Как такое может быть?
Под маской обычно понимают ввод по трафарету, когда посетитель сайта кликает в поле телефона и там уже автоматически подставляется код страны, далее он может ввести продолжение, которое четко ограничено по количеству символов.
Если у вас на сайте стоит маска, то возникают такие проблемы:
-
Клиент начинает вводить свой номер в местном формате (чаще всего с нулем вначале), и дальше с вашей лид-формы к нам приходит и код с плюсом, и ноль. Это несовместимо вместе. Как видите, номер становится невалидным.
-
В масках часто вшито ограничение символов, и если клиент вводит свой номер с нулем, то на последнюю цифру номера у него не хватает свободных символов. Он не замечает этого и вы получаете невалидный номер с нулем после кода и недостающей последней цифрой.
Маска - это хороший инструмент, но им нужно пользоваться правильно. Возможно, лучше переложить валидацию на CRM. Если же вы все равно хотите помочь клиенту оставить свой номер на сайте, то рекомендуем делать простую подсказку (когда клиент наводит на поле "Телефон", то вверху поля видит подсказку, как вводить, например с нулем или без нуля)
¶ Номер телефона точно валидный, но попал в "Ошибки"
Если номер телефона попал в "Ошибки", а по Google библиотеке вы убедились, что он валидный, возможно в настройках вы случайно убрали один параметр, или же изначально он не включился (хотя включаетс автоматически). Речь о настройке в режиме Управление - CPA - Офферы - соответствие полей.
Для "Phone1" должно быть обязательно выбрано соответствующее значение:
На скриншоте видны поля с адресом и именем. Они тоже должны быть выбраны, иначе и сам адрес, и имя могут попасть в поле "Ошибки". Если вы сначала создали эти поля, а потом добавите оффер, то при добавлении оффера это соответствие проставится автоматически. Если же сначала вы создали оффер, а потом поля, то соответствие нужно будет проставить потом.
В любом случае, поле "Телефон" всегда создано у вас по умолчанию, поэтому в оффере оно должно быть выбрано автоматически и номер телефона не должен попадать в "Ошибки"
¶ Я на своей стороне ставлю код с плюсом. Далее идет номер телефона, который ввел клиент. Но CRM не понимает, что нужно удалить нолик после кода и номер телефона попадает в "Ошибки". Почему?
Дело в том, что если вы передали номер телефона уже с + и с кодом, то CRM-система проверяет номер на валидность и не корректирует его. Запомнить легко: если вы передали номер в завершенном виде (с +), то CRM не может вмешиваться в середину номера и удалять оттуда какие-то цифры.
Поэтому если на вашей стороне работает какой-то валидатор номеров, который добавляет + и код, то обязательно убедитесь, что номер соответствует валидному формату.
¶ Номера Германии приходят с дублированием 49 в коде
Номера с двойным 49 создаются из-за особенности работы библиотеки libphonenumber, которую мы используем для валидации.
В Германии код страны 49 совпадает с началом многих местных кодов городов. Из-за этого библиотека не может понять, является ли 49 в начале строки кодом страны или частью локального номера.
Чтобы избежать ошибок и потери данных, она добавляет код страны к уже имеющемуся коду в результате чего вы получаете номера +4949.
Это официальное поведение библиотеки, подтвержденное разработчиками в их документации https://github.com/google/libphonenumber/blob/master/FAQ.md#why-wasnt-the-country-code-removed-when-parsing
Чтобы номера корректно передавались, нужно передавать их с кодом и плюсом. Если CRM получит номер в таком виде "+4917630600201", то библиотека уже будет понимать, что 49 в данном случае код страны и не будет добавлять ещё раз 49.
С радостью поможем вам, если у вас остались вопросы по встроенной валидации номеров телефона в нашей CRM-системе.