Normalización de números de teléfono a E.164 en BigQuery para consultas
Normalice números de teléfono a E.164 en BigQuery antes de una consulta de operador: conserve la columna original, elimine caracteres y valide el código de país.
Para normalizar números de teléfono a E.164 en BigQuery antes de una consulta de operador, conserve la columna original, elimine los caracteres de presentación en una columna de trabajo y añada un código de país solo cuando un campo de país autorizado respalde esa elección. Mantenga un signo más inicial para las solicitudes en tiempo real de CarrierLookup. Para una tarea de archivo de un solo país, exporte los dígitos con código de país y concilie el CSV devuelto utilizando una clave estable.
Conserve el número original y su evidencia de país
No sobrescriba la única copia de un número de teléfono durante la limpieza. Cree columnas separadas para el valor original, el país de origen, el candidato normalizado y un motivo de rechazo o revisión manual. Una fuente puede contener un prefijo de marcación nacional, un formato local o un código de país escrito de forma inconsistente. Una expresión regular puede eliminar la puntuación, pero no puede decidir a qué país pertenece un número. Esa decisión requiere un campo de país confiable u otra evidencia de fuente autorizada.
La ITU E.164 recommendation define la estructura de numeración internacional. Las comprobaciones en tiempo real de CarrierLookup requieren un + inicial, un código de país y un número de suscriptor sin espacios ni separadores. Un candidato que simplemente parece tener dígitos no es automáticamente un número válido. Mantenga los valores inciertos fuera del conjunto de consulta hasta que una persona o una regla de numeración validada los resuelva.
Planifique la forma de la exportación desde el principio. Las solicitudes múltiples en tiempo real pueden incluir números de diferentes países y devolverse en el orden de entrada. La tarea de archivo masivo de CarrierLookup acepta números de un solo país seleccionado. Divida un conjunto de datos de varios países mediante una asignación de país confiable antes de preparar los archivos; no elija un país basándose únicamente en los primeros dígitos.
Utilice funciones de BigQuery para la limpieza mecánica
La referencia de funciones de cadena de BigQuery de Google documenta REGEXP_REPLACE, REGEXP_CONTAINS y funciones relacionadas. Úselas para transformaciones mecánicas como eliminar espacios, paréntesis y guiones de una copia del valor de origen. Una expresión simple como REGEXP_REPLACE(raw_phone, r'[^0-9+]', '') puede crear un candidato de inspección, pero también puede conservar un signo más interno inesperado. Siga esto con una prueba de formato y una ruta de cuarentena en lugar de enviar cada resultado a la API.
Para los datos ya almacenados con un signo más inicial y un código de país confiables, una expresión candidata puede eliminar los separadores mientras conserva ese signo más. Para números locales, utilice una regla de normalización específica del país revisada según la guía de numeración actual. Una regla genérica de "anteponer el código de país del CRM" es arriesgada cuando el valor original ya incluye un código de país o un prefijo troncal. Documente la transformación específica aplicada a cada tipo de fuente y tome una muestra de la salida antes de la exportación.
Una tabla de preparación práctica contiene raw_phone, country_source, normalized_e164, normalization_rule y review_status. Construya la entrada de consulta solo a partir de las filas marcadas como listas. Esto evita que un formato rechazado se confunda con un resultado de "sin operador" y hace que las correcciones sean reversibles.
Prepare la ruta múltiple en tiempo real
Para un conjunto pequeño listo, exporte cadenas E.164 como + seguido de dígitos con código de país al flujo de trabajo múltiple REST. El punto final POST /api/v1/batch-check acepta de 1 a 100 números y devuelve un resultado síncrono ordenado. Almacene una asignación posicional desde el elemento de solicitud hasta la clave de fila de origen antes de enviar la llamada. No confíe únicamente en valores telefónicos idénticos cuando el CRM contenga duplicados.
Lea el identifier y el estado exists de cada elemento devuelto. exists=false significa que el elemento no tiene un resultado normal; no es una declaración de que el número esté desconectado. Un resultado exitoso puede contener el operador, el operador subyacente, el tipo de número, el código de país, la región y la ciudad, con campos opcionales vacíos. Mantenga la hora de comprobación y la asociación de entrada de cada resultado en la tabla de preparación.
La comprobación única utiliza la misma forma E.164 cuando un operador necesita inspeccionar un registro. Autentíquese desde un servidor confiable utilizando el encabezado X-API-Key documentado. Este flujo de trabajo ofrece a los equipos de datos una forma de probar la normalización en una muestra antes de enviar una lista preparada mucho más grande.
Prepare tareas de archivo de un solo país
Para una lista grande, cree un TXT o CSV de una columna con un número con código de país por línea y seleccione el país ISO correspondiente para la tarea masiva. La entrada documentada debe pertenecer a ese país seleccionado. En la presentación de varias partes, el campo de país debe preceder al archivo. La preparación masiva elimina filas no válidas, duplicados, filas sin código de país y números fuera del país seleccionado. Inspeccione los conteos de preparación antes de tratar la exportación de origen como completamente procesada.
La tarea masiva es asíncrona: envíela con POST /api/v1/bulk-tasks, guarde el ID de la tarea y consulte GET /api/v1/bulk-tasks/{id} no más de una vez cada 30 segundos. Una tarea exitosa proporciona un CSV. Informa el identificador como dígitos simples con código de país sin un signo más. Eso difiere de la forma de solicitud en tiempo real, por lo que no debe unir el resultado a un campo de teléfono original mediante la igualdad directa de cadenas.
Construya una clave de unión normalizada solo de dígitos a partir de cada candidato E.164 aceptado y conserve la clave de fila de origen por separado. Si la entrada contiene números duplicados, la preparación masiva puede colapsarlos; decida si un resultado debe asociarse con varios registros de origen. Concilie las filas de origen no coincidentes, no válidas y duplicadas fuera del CSV de resultados.
Revise los datos unidos antes de las actualizaciones del CRM
El operador resultante describe la asignación original, no el operador que presta servicio actualmente después de la portabilidad. La región y la ciudad son geografía de asignación en lugar de ubicación en vivo. Coloque estas descripciones en el diccionario de datos para que los analistas no confundan un nombre de campo con una prueba de dónde se encuentra una persona ahora. Un resultado en tiempo real completado con code=0 puede tener campos de operador opcionales vacíos; mantenga los vacíos como no disponibles en lugar de generar una etiqueta negativa.
Tome muestras de filas unidas de varios sistemas de origen y países. Compruebe que el número original, la forma E.164 normalizada, la clave de dígitos simples y el identificador de resultado se refieran a la misma entrada. Investigue las discrepancias en la tabla de preparación antes de escribir valores en el CRM. Mantenga la marca de tiempo de la consulta, ya que el contexto de asignación puede revisarse más adelante y el registro de origen en sí puede cambiar.
Este proceso separa tres trabajos: BigQuery limpia una representación conocida, CarrierLookup proporciona campos de asignación documentados y el equipo de CRM decide si actualizar el contacto y cómo hacerlo. Esa división hace que los errores sean visibles y mantiene el resultado del operador dentro de su significado adecuado.
Preguntas frecuentes
¿Cómo pueden los equipos eliminar los separadores de teléfono en BigQuery?
Utilice una copia de trabajo y funciones de cadena documentadas como REGEXP_REPLACE, luego valide el candidato contra la forma E.164 esperada.
¿Cómo pueden los equipos asignar un código de país a un número local?
Utilice un campo de país confiable y una regla específica del país revisada. Ponga en cuarentena las filas cuyo país o forma de marcación sea ambiguo.
¿Cómo pueden los equipos unir un CSV masivo a una entrada E.164?
Cree una clave estable de solo dígitos a partir de los candidatos E.164 aceptados y concílela con el identificador del CSV masivo, mientras conserva los ID de fila de origen.
¿Cómo pueden los equipos manejar una lista de varios países?
Utilice solicitudes múltiples en tiempo real para un conjunto pequeño de varios países o divida archivos grandes por asignación de país confiable antes de la presentación masiva.
Más información
Elija la información del producto que se ajuste al siguiente paso de su flujo de trabajo.