Тестирование обогащения данных об исходном операторе на выборке из вашей CRM

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

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

Выберите решение для CRM и репрезентативную выборку

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

Продукт CarrierLookup для определения исходного оператора сообщает оператора, которому диапазон номеров был выделен изначально, а также тип номера и географию распределения, если они доступны. Он не отслеживает текущую обслуживающую сеть после переноса номера. Для небольшого пилотного проекта используйте документированные REST-запросы для одного или нескольких номеров, а не подготовку файла производственного объема. Выберите строки CRM, которые вы уполномочены обрабатывать, сохраняя внутренний ID строки и исходное значение телефона. Нормализуйте рабочую копию к формату E.164 для API в реальном времени и учитывайте отклоненные или нечитаемые входные данные в знаменателе пилотного проекта.

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

Создайте эталон исходного распределения перед оценкой

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

Рецензент должен отметить, для каких полей есть согласованный эталон: исходный оператор, базовый оператор (где применимо), тип номера, код страны, регион и город. В документации API они перечислены как поля результата оператора; необязательные значения могут быть пустыми. Сохраняйте источник и дату проверки для каждого эталона, так как таблицы распределения и собственные метаданные CRM могут использовать разные названия или уровни детализации. Определите правило нормализации для названий операторов перед вычислением совпадений. В противном случае различия в написании или псевдонимы материнских брендов будут засчитаны как неверные данные без существенных разногласий.

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

Используйте оценочную таблицу по полям с честными знаменателями

Для каждой входной строки записывайте статус форматирования, статус запроса, статус завершенной проверки, возвращенные значения полей, наличие эталона и решение рецензента. Отклоненный ввод E.164 — это не ошибка оператора. Тайм-аут передачи — это не пустой результат завершенной проверки. Успешный ответ с кодом 0 и пустыми необязательными полями оператора — это завершенная проверка с недоступными значениями; она все равно может быть тарифицирована. Для синхронных проверок нескольких номеров элемент без нормального результата должен оставаться отличным от интерпретации «Не определено».

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

Выберите критерии приемлемости, связанные с бизнес-действием

Прежде чем увидеть оценочную таблицу, решите, что является достаточным для предполагаемого использования в CRM. Если данные отображаются только как контекст, команда может допустить отсутствие необязательных полей, если они четко помечены как недоступные. Если правило должно автоматически маршрутизировать записи на основе типа номера, изучите показатели расхождений и «Не определено» для этого конкретного поля и предусмотрите путь для ручной обработки исключений. Устанавливайте пороговые значения исходя из вашей рабочей нагрузки и последствий ошибки, а не из общего эталона. Обсуждение эталонов B2B-обогащения также предупреждает, что за широкими заявлениями стоят различия в сегментах и полях; его цифры не являются показателями производительности CarrierLookup.

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

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

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

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

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