Почему номера телефонов потенциальных клиентов из инструментов обработки данных часто неточны
Неточные номера телефонов часто связаны с проблемами обработки данных: отсутствием кода страны, неверным форматом или устаревшими записями.
Неточные номера телефонов потенциальных клиентов часто отражают проблему обработки данных, а не характеристики самого человека: отсутствие контекста страны, неверный формат, устаревшие контактные записи или путаницу между мобильными и стационарными линиями.
Неточные номера телефонов потенциальных клиентов часто отражают проблему обработки данных, а не характеристики самого человека: отсутствие контекста страны, неверный формат, устаревшие контактные записи или путаницу между мобильными и стационарными линиями. Определение исходного оператора может добавить контекст распределения номеров в очередь на проверку. Оно не может подтвердить, что потенциальный клиент в настоящее время использует этот номер, владеет им или может получать на него сообщения.
Отделяйте качество данных от идентификации контакта
Отдел продаж может импортировать номера из различных инструментов обработки контактных данных, форм CRM и старых электронных таблиц. Некоторые значения представляют собой локальные строки набора без кода страны. Другие содержат пробелы, префиксы или метки, которые были потеряны при экспорте. Контактная запись также может быть устаревшей или привязанной не к той организации. Прежде чем обвинять сервис проверки в несоответствии, сравните сохраненное исходное поле с оригинальной записью и страной, заявленной источником.
Первый полезный вопрос заключается в том, представлен ли номер в формате, который команда может интерпретировать единообразно. E.164 предоставляет международную структуру нумерации с кодом страны и национальным номером; рекомендация ITU является основным справочным материалом. Для ввода в реальном времени в CarrierLookup используйте ведущий знак «плюс», код страны и номер абонента без пробелов или разделителей. Отклоненный формат не означает, что у номера нет оператора.
Сохраняйте происхождение каждого импортированного поля телефона. Записывайте источник, дату, заявленную страну и любой этап нормализации. Это помогает аналитикам отличить ошибку преобразования от реального несоответствия в исходном наборе данных. Номер не следует молча перезаписывать с использованием угаданного кода страны, особенно когда набор данных охватывает несколько рынков.
Используйте поля распределения как контекст, а не как подтверждение личности
CarrierLookup предоставляет данные об исходном операторе, базовом операторе, типе номера, коде страны, регионе и городе распределения, если они доступны. Эти поля описывают контекст распределения диапазона номеров. Поле оператора указывает на компанию, которой диапазон был выделен изначально. Это не обязательно тот оператор, который обслуживает номер в настоящее время после переноса. Регион и город описывают географию распределения, а не текущее местоположение человека или устройства.
Для списка потенциальных клиентов эти поля могут помочь найти записи, требующие проверки человеком. Номер, помеченный в CRM как мобильный, но возвращенный с другим типом, может нуждаться в исправлении источника. Код страны, отличающийся от целевого рынка команды, может указывать на то, что поле страны в CRM устарело. Пустое необязательное поле следует записывать как недоступное, а не превращать в отрицательный вердикт. Завершенная проверка с кодом code=0 все равно может иметь пустые поля оператора.
Проверка не сообщает, активен ли номер, доступен ли он для голосовой связи или SMS, а также связан ли он с указанным потенциальным клиентом. Эти вопросы требуют других авторизованных методов. Результат по оператору может помочь в вопросе качества данных: стоит ли контекст распределения того, чтобы перепроверить импортированное поле перед использованием?
Создайте последовательность проверки для подозрительных строк
Начните с небольшой выборки подозрительных записей. Проверьте исходное значение и страну-источник, нормализуйте копию до документированного формата реального времени, а затем выполните одиночную проверку или синхронную мультипроверку. Мульти-эндпоинт API принимает от 1 до 100 номеров E.164 и возвращает результаты в порядке ввода. Сохраняйте этот порядок и исходный ключ строки CRM, чтобы результат не был привязан к неверному контакту.
Отмечайте три типа проблем отдельно. Проблема формата означает, что отправленная строка требует исправления перед проверкой. Несоответствие распределения означает, что возвращенный контекст отличается от метки CRM и заслуживает проверки. Неопределенный или неудачный результат проверки означает, что нет нормального результата для интерпретации. В мультирезультатах exists=false означает отсутствие нормального результата для этого элемента, а не то, что номер недействителен или отключен. Это разделение предотвращает превращение технической проблемы или проблемы форматирования в утверждение о потенциальном клиенте.
Когда проверяющий видит несоответствие, вернитесь к исходной записи. Можно ли установить страну из доверенных метаданных учетной записи? Удалил ли экспортер ведущий знак «плюс»? Был ли стационарный номер ошибочно принят за мобильный? Если источник не позволяет внести исправление, пометьте запись как нерешенную, а не выдумывайте новый номер.
Выбирайте путь обработки в зависимости от размера списка
Несколько записей подходят для одиночных или мультизапросов в реальном времени. Панель управления поддерживает проверку в реальном времени до 500 номеров, в то время как REST мульти-эндпоинт принимает до 100 номеров за запрос. Для большого подготовленного списка из одной выбранной страны асинхронная файловая задача carrier_batch принимает файл TXT или CSV с одним номером с кодом страны в строке. Пакетная подготовка исключает недействительные строки, дубликаты, номера без кода страны и номера вне выбранной страны, поэтому команде следует сверять исключенные строки отдельно.
Не смешивайте форматы идентификаторов реального времени и пакетной обработки при объединении результатов. Ввод в реальном времени использует ведущий знак «плюс». Идентификатор в CSV-файле пакетного результата — это обычные цифры с кодом страны без знака «плюс» или пробелов. Нормализуйте данные до стабильного внутреннего ключа для сопоставления, сохраните исходный ввод и проведите аудит дубликатов перед перезаписью полей CRM.
Завершенная проверка может быть оплачена, даже если необязательные поля оператора пусты. Это еще одна причина определить цель проверки и выбрать выборку перед запуском большого списка. Решение должно касаться того, как поля распределения улучшают обработку контактных данных, а не предположения, что каждая строка создаст полный профиль.
Вносите исправленную запись в CRM консервативно
После проверки сохраняйте исходный номер источника и любое нормализованное значение как отдельные поля, если это позволяет CRM. Храните время проверки и поля распределения, которые команда действительно использует. Если идентичность страны-источника остается неопределенной, не исправляйте ее на основе слабых улик. Если команда меняет номер контакта, записывайте, кто внес изменение и почему. Аудиторский след полезнее, чем молчаливая перезапись данных.
Создайте внутреннюю метку, такую как «требуется проверка формата номера» или «контекст распределения отличается от типа в CRM». Такие метки описывают работу с качеством данных, а не суждение о человеке. Затем команда может попросить потенциального клиента через обычный канал связи подтвердить предпочтительный номер, если это уместно. Избегайте использования поля оператора как разрешения на отправку сообщения.
Данные о телефонах потенциальных клиентов становятся более полезными, когда формат, происхождение и контекст распределения рассматриваются как отдельные элементы. CarrierLookup может предоставить последнее из них; команда остается ответственной за контактную запись и любое решение об аутриче.
Часто задаваемые вопросы
Как команды могут определить, отформатирован ли номер потенциального клиента для проверки?
Используйте документированный формат E.164 для реального времени: ведущий знак «плюс», код страны и номер абонента без разделителей. Сохраняйте исходное значение для сравнения.
Как команды могут интерпретировать другое имя оператора?
Рассматривайте его как контекст исходного распределения. Переносимость номеров может привести к тому, что текущий обслуживающий оператор будет отличаться, поэтому вернитесь к источнику CRM перед изменением контактной записи.
Как команды могут обрабатывать пустое поле оператора?
Оставляйте его как недоступное. Завершенная проверка с пустыми необязательными полями по-прежнему является завершенным результатом и ничего не говорит о владении или доступности.
Как команды могут обработать большой список по конкретной стране?
Подготовьте документированную задачу для файла TXT или CSV по одной стране и сверьте исключенные строки и CSV-файл с результатами одиночных проверок с исходным списком.
Узнать больше
Выберите информацию о продукте, которая соответствует следующему шагу в вашем рабочем процессе.