Consulta del operador, HLR o validación de formato: elija los datos telefónicos que necesita
Elija comprobaciones de formato, datos del operador original, información de red tipo HLR o verificación de posesión según la pregunta de su flujo de trabajo.
Una guía basada en tareas para elegir datos telefónicos sin confundir la asignación, la estructura, el estado de la red y la posesión por parte del usuario.
Utilice una comprobación de formato para preparar un número de teléfono plausible, una consulta del operador original para enriquecerlo con el contexto de asignación, un servicio de datos de red adecuado para una pregunta sobre la red actual y un flujo de verificación activa cuando necesite evidencia de que un usuario controla el número. Estas respuestas son diferentes; ningún resultado de CarrierLookup demuestra la capacidad de recepción o la posesión.
Comience con la decisión que debe tomar
Un equipo de datos puede preguntar si una cadena puede enviarse a una API, qué operador recibió originalmente su rango de numeración, si una red móvil puede prestarle servicio actualmente o si un cliente la controla. Llamar a las cuatro tareas "validación telefónica" oculta la diferencia entre una comprobación local, un registro de asignación, una consulta de red y una interacción con una persona. Elija primero la pregunta y, a continuación, compre o cree la comprobación que la responda.
| Decisión en su flujo de trabajo | Comprobación adecuada | Lo que la respuesta no puede establecer |
|---|---|---|
| ¿Podemos normalizar esta entrada y enviarla en el formato requerido? | Análisis local y comprobaciones de formato | Que un suscriptor exista o pueda recibir un mensaje |
| ¿Qué operador poseía originalmente este rango y qué atributos de asignación están disponibles? | Consulta del operador original | El operador que presta servicio tras la portabilidad, el estado en vivo o la contactabilidad |
| ¿Necesitamos información actual de red o enrutamiento? | Un proveedor que documente explícitamente la señal requerida de red actual o derivada de HLR | Que una persona en particular sea propietaria del número o haya dado su consentimiento |
| ¿Debemos saber si este usuario puede recibir un desafío ahora? | Un flujo de posesión activa, como un código entregado a través de un canal adecuado | La asignación histórica o la propiedad permanente |
Las dos últimas filas requieren una evaluación de servicio por separado. Los proveedores de HLR difieren en sus definiciones de campo, cobertura geográfica y actualización. Un desafío de posesión depende de la interacción exitosa del usuario. Ninguna de estas capacidades forma parte del servicio de asignación original publicado por CarrierLookup.
Lo que puede hacer una comprobación de formato local
Comience conservando el valor original y un candidato normalizado por separado. Un analizador puede comprobar si el código de país y la estructura del número se ajustan a sus metadatos de numeración y puede producir un valor al estilo E.164. Esto detecta códigos de país faltantes, puntuación errónea y algunas formas imposibles antes de realizar una consulta externa. Una expresión regular por sí sola es un sustituto débil de los metadatos del plan de numeración, especialmente entre diferentes países.
Para la API en tiempo real de CarrierLookup, el identificador enviado debe incluir un signo más inicial, el código de país y el número de suscriptor sin espacios ni separadores. Un formato rechazado es un problema de entrada, no una evidencia de que el número carezca de operador. Por el contrario, una cadena E.164 sintácticamente plausible no demuestra que el número haya sido asignado a un suscriptor, que esté activo, que reciba SMS o que pertenezca a la persona que lo introdujo. Almacene estos estados por separado en un CRM: format_ready es un indicador de preparación, no un veredicto de contactabilidad.
Lo que añade una consulta del operador original
La Consulta del operador original de CarrierLookup devuelve el operador al que se asignó originalmente el rango de numeración. Cuando está disponible, también devuelve el operador subyacente, el tipo de número, el código de país y los campos de asignación de región y ciudad. La región y la ciudad describen la geografía de asignación del rango de numeración, no la ubicación actual del usuario o dispositivo. El campo del operador es un contexto de asignación histórica, incluso cuando un número ha sido portado posteriormente.
El servicio admite una solicitud única en tiempo real, solicitudes múltiples síncronas para 1–100 números y un servicio de archivos asíncrono independiente para listas grandes preparadas. "En tiempo real" describe la rapidez con la que la solicitud devuelve el resultado en el flujo de trabajo; no significa una sonda de red en vivo. La documentación de la API distingue estas rutas y sus estructuras de resultados. Para un proceso de enriquecimiento, mantenga el valor telefónico original, la entrada normalizada, el resultado de la consulta y los campos de asignación en columnas distintas. No sobrescriba un campo llamado current_carrier con el carrier de una respuesta de asignación original.
Un campo de operador vacío requiere un manejo cuidadoso. Una consulta completada con code=0 puede devolver campos de asignación vacíos; eso sigue siendo una consulta completada, no una prueba de que el número sea inválido o esté desconectado. Un error de aplicación de tipo Indeterminado es otro resultado posible. En los resultados múltiples síncronos, exists=false significa que no hay un resultado normal para ese elemento, no un hallazgo negativo sobre el estado de la red. Estas distinciones evitan que un valor de datos faltante se convierta en una etiqueta de "inalcanzable" no respaldada.
Cuando una pregunta de red o posesión requiere otra fuente
Un número puede conservar su registro de asignación original después de que la portabilidad cambie la red de servicio. Si la decisión real depende del enrutamiento, la clasificación de la red actual o una señal de estado de red, evalúe a un proveedor que documente exactamente esa señal y sus límites. Las comparaciones de la industria discuten las consultas tipo HLR para obtener información de redes móviles; no convierten cada consulta de operador en una comprobación HLR. Por ejemplo, Tata Communications explica la consulta HLR en un contexto de mensajería, mientras que Didit contrasta HLR y SMS OTP para decisiones de verificación. Sus productos y afirmaciones deben evaluarse según su propia documentación, no trasladarse a CarrierLookup.
Si la decisión comercial es "¿recibió y respondió este usuario a un desafío?", utilice un flujo de verificación activa adecuado. Un resultado de datos de red no es la respuesta de la persona. Incluso completar con éxito un desafío es evidencia de control en esa interacción, no un registro permanente de identidad o consentimiento. Mantenga los eventos de verificación, sus marcas de tiempo y cualquier registro de consentimiento separados del enriquecimiento de asignación.
Una pequeña prueba de comprador que evita una compra incorrecta
Antes de adquirir un plan amplio de datos telefónicos, anote la acción que desencadenará cada respuesta. Para un ejercicio de segmentación de CRM, tal vez la acción sea agrupar registros por operador original y tipo de línea. Para una ruta de mensajería, podría depender de un campo de red actual con una base de actualización documentada. Para el acceso a una cuenta, podría requerir un desafío activo. Estas son tres pruebas de aceptación diferentes.
Utilice una muestra autorizada que incluya entradas limpias y mal formadas, números con historial de portabilidad conocido cuando esté disponible y registros con valores de asignación faltantes. Mantenga una referencia para cada afirmación: metadatos de numeración para el formato, una fuente de asignación confiable para la asignación original, el resultado documentado del proveedor de red para su pregunta sobre el estado actual y un desafío de usuario completado para la posesión. Compare elementos comparables. Un número portado no debe contar como un error de consulta de asignación original simplemente porque su red actual difiera.
En el cuadro de mando, informe los denominadores por separado: entradas rechazadas antes de la consulta, consultas completadas con campos poblados, consultas completadas con campos vacíos, resultados de tipo Indeterminado y cualquier resultado de red o verificación de proveedores separados. Luego, inspeccione las falsas suposiciones en las reglas posteriores. Una fila de muestra con carrier poblado solo debe calificar para la agrupación basada en la asignación; no debe pasar automáticamente una regla de entrega de SMS o de verificación de usuario. Este cuadro de mando basado en tareas es más útil que un porcentaje único de "precisión de validación telefónica" que combina preguntas incompatibles.
Elija un siguiente paso defendible
Si su necesidad inmediata es el contexto del operador original y el tipo de línea para una lista preparada, inspeccione los campos documentados y las rutas de solicitud de CarrierLookup, luego pruebe una pequeña muestra autorizada frente a un cuadro de mando específico de asignación. Si necesita el estado de la red actual o una prueba de control del usuario, documente ese requisito explícitamente y evalúe el servicio separado o el flujo de verificación adecuado. Mantenga cada respuesta etiquetada según lo que realmente mide antes de que llegue a una regla de CRM.
Más información
Elija la información del producto que se ajuste al siguiente paso de su flujo de trabajo.