esedark
Menú
Volver a las notas

scraping / contactos / calidad de datos / integración

Extracción de contactos: cómo comprobar la calidad

Un email con formato correcto puede no pertenecer al anunciante. Antes de contratar una extracción, hay que comprobar qué recoge, qué omite y qué puede demostrar cada registro.

Cuando reviso un proyecto de extracción de contactos, empiezo por la decisión que necesita tomar el equipo con esos datos. El volumen descargado dice poco si después hay que abrir cada anuncio para averiguar de dónde salió el teléfono.

Esta guía se centra en extraer emails y teléfonos públicos de anuncios con calidad verificable. El recorrido completo de captación, enriquecimiento y revisión está en la guía de lead generation técnica. Aquí la pregunta es más concreta: ¿qué tendría que demostrar la primera muestra para aceptar la extracción?

Define qué contacto buscas y en qué fuentes

Antes de programar, acordaría los tipos de anuncio, campos permitidos, países, frecuencia y uso previsto. Primero comprobaría si existe una API o exportación autorizada que cubra la necesidad. Un teléfono del soporte del portal no es el contacto del anunciante, aunque aparezca en la misma página.

La muestra debe incluir anuncios con contacto, sin contacto, con varios valores y con formatos distintos. Los campos ocultos, restringidos o enmascarados quedan fuera de la extracción acordada; no los rellenaría con una suposición. También definiría quién aprueba las fuentes y el uso posterior, cuánto se conserva y cómo se corrige o retira un dato.

Distingue dato ausente, ambiguo y fallo de extracción

Un campo vacío no explica qué ocurrió. Propongo estos estados para que operaciones sepa cuándo revisar y cuándo pedir una corrección técnica. Son criterios de diseño, no resultados de un proyecto real.

Estados para revisar una muestra de contactos
SituaciónEstado propuestoQué hacer
Valor visible y atribuible al anuncianteExtraídoGuardar origen y ejecutar las validaciones pactadas.
No hay contacto en el campo revisadoNo publicadoConservar la ausencia; no inventar un valor.
Varios contactos sin destinatario claroAmbiguoEnviar a revisión con el contexto disponible.
Página inaccesible o estructura no reconocidaError de extracciónRegistrar el fallo; no contarlo como ausencia de contacto.
Dato pendiente de comprobar otra vezRevisión de vigenciaAplicar la frecuencia acordada antes de reutilizarlo.

La aprobación de calidad es otro campo. Un valor extraído puede seguir pendiente de revisión. Tampoco equivale a una aprobación para enviar mensajes: esa decisión pertenece al proceso comercial acordado.

Qué demuestra la validación de emails y teléfonos

Conservaría el valor original junto al normalizado y la regla aplicada. Para teléfonos, registraría el contexto de país cuando esté respaldado por la fuente; si falta y cambia la interpretación, lo enviaría a revisión. Para emails, documentaría las transformaciones sin reescribir partes de la dirección por intuición.

Un formato plausible no demuestra que el contacto siga activo o pertenezca a esa empresa. La documentación de libphonenumber aclara que validar un rango telefónico no confirma que el número esté asignado a una persona ni que sea alcanzable. La aceptación debe indicar exactamente qué se ha comprobado.

Si el mismo contacto aparece en varios anuncios, conservaría las referencias de origen antes de decidir si representan la misma entidad. Las reglas de deduplicación y fusión se acuerdan aparte; no conviene resolver identidad eliminando filas a ciegas.

Guarda evidencia por campo y por ejecución

Una ficha mínima debería relacionar URL, identificador del anuncio, campo de origen, fecha de captura, valor original, valor normalizado, estado de extracción, regla de validación y versión del parser. Añadiría motivo y responsable de revisión cuando intervenga una persona. Guardaría solo la evidencia necesaria dentro de la retención acordada.

Ejemplo hipotético: un directorio muestra el email del portal en el pie y el del anunciante en una sección propia. Un extractor de patrones devuelve ambos con formato correcto. La prueba útil es verificar que cada valor pertenece al campo esperado; aumentar la puntuación de confianza no corrige esa confusión.

Separar descarga, interpretación y validación permite localizar el fallo. La arquitectura de scraping con colas y reintentos desarrolla esa separación. El caso Adslyfy muestra ejecuciones y capturas de monitorización de anuncios; sirve como evidencia de visibilidad operativa, no como prueba de extracción o validación de contactos.

Cómo aceptar una muestra antes de contratar el despliegue

Acordaría con la persona que revisará los datos un conjunto de ejemplos autorizados o anonimizados y su resultado esperado. Debe cubrir las variantes de fuente, no solo los anuncios más fáciles. Estas seis pruebas ayudan a delimitar la primera entrega:

  1. Atribución: un contacto del pie del portal no se asigna al anunciante.
  2. Ausencia: un anuncio sin teléfono queda marcado como no publicado, sin completar cifras.
  3. Ambigüedad: varios valores sin contexto llegan a revisión y conservan su procedencia.
  4. Formato: la normalización es explicable y nunca destruye el valor original.
  5. Cambio de fuente: una plantilla desconocida produce un fallo visible en lugar de contactos vacíos aparentemente válidos.
  6. Vigencia: un cambio o retirada del dato sigue la regla de revisión acordada y queda registrado.

Mediría por separado los valores correctos entre los extraídos, los contactos visibles recuperados en la muestra y los minutos de revisión. Un extractor puede devolver solo unos pocos valores correctos y omitir muchos otros. Los umbrales se acuerdan según el coste del error; no propondría un porcentaje universal ni confundiría calidad de extracción con conversión comercial.

Presupuesta también revisión y mantenimiento

Influyen las fuentes y sus variantes, los campos, la frecuencia, el historial necesario y las excepciones. Separaría construcción, infraestructura, revisión humana y mantenimiento del parser. El presupuesto debe indicar quién atiende los cambios de estructura, qué requiere un nuevo alcance y cuándo se pausa una fuente.

Para comparar propuestas, usa la lista de alcance y aceptación del presupuesto. Después importa una muestra ficticia en el destino: las pruebas de entrega CSV, API o dashboard comprueban que valores y estados llegan intactos. Validar la extracción y validar la entrega son pruebas distintas.

Qué preparar para revisar tu extracción de contactos

Mis servicios de plataformas internas e integraciones cubren el diseño del recorrido de datos y sus fallos. Para valorar un encargo, necesito las fuentes acordadas, los campos, la herramienta de destino, la frecuencia y quién revisará las excepciones.

Cuéntame dónde pierde calidad tu extracción y prepara ejemplos ficticios o anonimizados de un dato correcto, uno ausente y uno ambiguo. Puedo revisar contigo el alcance y definir qué debe demostrar una primera entrega antes de ampliar el volumen.