Обогащение данных о телефонных номерах: добавление контекста об исходном операторе в записи контактов

Обогащайте записи контактов четко обозначенными полями распределения, используя документированный маршрут поиска и явную обработку пустых результатов.

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

Определите поля обогащения телефонных номеров перед поиском записей

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

Решите, как CRM будет представлять три различных состояния: завершенный результат со значением, завершенный результат с пустым необязательным значением и запрос, который не привел к нормальному результату. Пустая ячейка оператора должна оставаться недоступными данными. Она не должна вызывать метку no carrier, invalid phone или safe to message. Сохраняйте неизменную копию записи контакта и канонический номер, использованный для запроса. Это позволит выполнить сверку позже, если пользователь изменит поле телефона во время процесса обогащения.

Небольшой анализ схемы предотвращает ситуацию, когда аналитики ошибочно превращают контекст распределения в показатель возможности связи. Документируйте значение рядом с каждым полем, включайте дату сбора в экспорт и делайте данные о происхождении доступными в дашбордах. На странице продукта Определение исходного оператора описан сервис реального времени; API документация является справочником по поведению интеграции.

Используйте проверки в реальном времени для новых и недавно измененных номеров контактов

При поступлении новой записи сначала нормализуйте введенный номер телефона до формата E.164 с кодом страны, знаком «плюс» в начале и без пробелов или разделителей. Сохраняйте исходный ввод пользователя отдельно, если он необходим для поддержки. Отклонение формата относится к очереди исправления ввода, а не к той же категории, что и завершенный поиск с пустыми полями оператора. Единый REST-маршрут принимает один номер. Синхронный мульти-запрос принимает упорядоченный набор номеров, включая номера из разных стран. В дашборде также есть рабочий процесс пакетной обработки в реальном времени. Выбирайте подходящий метод в зависимости от пути ввода команды, а не предполагайте, что каждый пакет означает загрузку файла.

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

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

Используйте файловую задачу для подготовленного каталога

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

Сервис пакетного определения оператора принимает одностолбцовый TXT или CSV файл с номерами в формате кода страны и выбранным ISO-кодом страны. Подготовьте файл, который по сути предназначен для этой выбранной страны. Сервис исключает недействительные, дублирующиеся, некодированные и зарубежные строки во время предварительной обработки; эти исключения не должны записываться как отрицательные ответы об операторе. Задача может завершиться неудачей во время подготовки, если условия принятия не соблюдены. Проверяйте текущие документированные лимиты ввода и файлов перед созданием каждой задачи, вместо того чтобы заполнять файл несвязанными записями.

Задача выполняется асинхронно. Храните ссылку на задачу в журнале заданий команды, опрашивайте статус с документированным интервалом и дождитесь успеха перед загрузкой единственного CSV-файла. Сопоставьте выходной идентификатор, представленный цифрами с кодом страны без знака «плюс», с каноническим номером во вспомогательной таблице. Сравните количество отправленных, исключенных, возвращенных и несопоставленных записей. Затем разверните каждый успешный результат поиска обратно к исходным ID строк CRM. Этот шаг позволяет избежать потери дубликатов контактов или ошибочного присвоения одного результата не той записи.

Проверяйте обогащенные записи перед использованием сегментов

Создайте отчет о приемке перед записью в рабочую среду. Выберите строки с заполненными полями, строки со всеми пустыми необязательными полями оператора и строки без нормального результата. Убедитесь, что результат поиска и дата сбора сохранились после импорта. Убедитесь, что поле CRM с названием carrier четко помечено как исходное распределение, а регион и город не отображаются под заголовком «местоположение человека». Если номер изменился в исходной записи, направьте этот конфликт на проверку.

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

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

Часто задаваемые вопросы

Как команды могут сохранить завершенный поиск без названия оператора?

Сохраните результат поиска и время проверки, а необязательное поле оператора оставьте недоступным. Завершенный результат может иметь пустые сведения об операторе. Не превращайте пустое значение в вердикт о том, что номер недействителен или не имеет оператора. Если бизнес-процесс требует наличия известного оператора, поместите строку в явную группу проверки, вместо того чтобы молча отфильтровывать ее.

Как команды могут обогатить дублирующиеся номера телефонов в контактах?

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

Может ли обогащение доказать, что контакт получит сообщение?

Нет. Исходный оператор, тип линии и география распределения — это контекст диапазона номеров. Они не показывают, активна ли сеть, может ли быть доставлено сообщение или дал ли контакт согласие. Рассматривайте их как вспомогательные метаданные для сегментации и проверки. Решения о доставке и разрешениях требуют собственных средств контроля и доказательств вне этого поиска.

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

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

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