Un scraper puede funcionar y dejar al equipo arreglando columnas, pidiendo exportaciones o preguntando si el dato sigue vigente. Antes de construir la salida, yo empezaría por una pregunta: ¿qué tiene que hacer la persona o el sistema que recibe los datos?
CSV, API y dashboard pueden compartir una misma base de datos aprobados. Elegiría primero el canal que resuelve el trabajo actual. Añadir los tres desde el inicio también añade permisos, pruebas y mantenimiento que deben tener una razón concreta.
CSV, API o dashboard: compara el uso real
| Canal | Cuándo encaja | Qué acordar | Coste que suele quedar fuera |
|---|---|---|---|
| CSV | Un analista revisa un lote y lo importa en una herramienta conocida. | Columnas, formato, fecha del lote e instrucciones de importación. | Correcciones manuales, reparto de archivos y control de versiones. |
| API | Otro sistema consulta datos de forma recurrente y hay un responsable de integrarlo. | Esquema, acceso, paginación, frecuencia y cambios compatibles. | Cliente consumidor, monitorización y soporte de versiones. |
| Dashboard | Una persona compara, filtra y revisa excepciones antes de decidir. | Filtros, definición de métricas, roles y acceso a evidencia. | Diseño de vistas, formación y mantenimiento de permisos. |
Un archivo programado puede alimentar otro sistema sin intervención manual. Una API tampoco convierte una captura antigua en información en tiempo real. La decisión depende de la frecuencia de captura, del retraso aceptable y de las capacidades del destino; el formato por sí solo no garantiza ninguna de ellas.
La muestra y el contrato de datos antes del desarrollo
Pediría una muestra ficticia o sanitizada y la probaría con quien va a consumirla. A partir de ella, dejaría por escrito estos acuerdos:
- Significado de los campos: nombre, tipo, unidad, moneda si aplica y diferencia entre valor vacío, cero y dato desconocido.
- Identidad y estado: identificador estable, revisión y estados aprobado, pendiente o rechazado. Solo se entregan los estados incluidos en el alcance.
- Tiempo: captura, última validación y generación de la entrega, con zona horaria. Un archivo generado hoy puede contener observaciones antiguas.
- Cobertura: fuentes previstas, fuentes realmente procesadas, registros aceptados y exclusiones. Una ejecución parcial debe verse como parcial.
- Correcciones: cómo se publica una nueva revisión y quién avisa al consumidor. Distinguir un lote completo de una entrega de cambios.
- Acceso y conservación: destinatarios, campos visibles, caducidad de accesos y responsable de retirar datos. La revisión del uso de las fuentes se resuelve antes de entregar.
El contrato debe decir cómo interpretar una ausencia: que una fila no aparezca en un lote parcial no demuestra que el registro deba borrarse. Para actualizar un CRM, las reglas sobre conflictos y reintentos pertenecen al diseño del pipeline de scraping a CRM.
Qué comprobar en cada canal
CSV: importar sin corregir a mano
Acordaría codificación, separador, comillas, saltos de línea y formato de fechas. Los teléfonos e identificadores deben conservarse como texto en la importación. Microsoft documenta las conversiones de Excel que pueden eliminar ceros iniciales; probaría el archivo en la versión y configuración del destinatario, no solo en un editor de texto.
El lote necesita un identificador, una revisión y un resumen de lo incluido y excluido. Una corrección debe distinguirse del archivo anterior para que nadie reutilice por error una exportación obsoleta.
API: consultar un conjunto definido
Concretaría qué filtros y campos necesita el consumidor, cómo recorrer todas las páginas y qué sucede si los datos cambian durante la consulta. Para una entrega por lotes, una revisión fija permite comprobar el mismo conjunto durante toda la lectura. Los límites de uso, errores y cambios de esquema deben estar documentados y probados con el sistema receptor.
Dashboard: decidir con contexto
Definiría cada métrica, los filtros activos y la antigüedad de los datos visibles. El usuario debe poder distinguir cero resultados, datos pendientes y una fuente fallida. Si hay exportación, probaría que respeta los mismos filtros y permisos que la vista; ver un panel no debería conceder acceso a campos ocultos en el archivo.
Ejemplo hipotético: seguimiento de un catálogo
Imagina un equipo que revisa periódicamente precios de un catálogo autorizado. Compras necesita comparar una muestra y anotar discrepancias. Empezaría probando un CSV con identificador, precio, moneda, URL de fuente, fecha de captura y estado de revisión.
Si el trabajo pasa a repartir excepciones entre varias personas, evaluaría una vista con filtros y responsables. Si una aplicación necesita consumir los registros aprobados de forma recurrente, evaluaría la API. Son posibles siguientes pasos; el ejemplo no presupone que haya que construirlos todos.
Excluiría del primer alcance la modificación automática de precios y la escritura en otros sistemas salvo que formen parte del problema acordado. Las comprobaría como funciones separadas antes de ampliar el proyecto.
Pruebas para aceptar la entrega de datos
Propondría estas comprobaciones con datos ficticios. Son criterios de aceptación, no resultados de un proyecto realizado:
- Valores difíciles: importar tildes, ceros iniciales, comillas, saltos de línea, fechas y campos vacíos; comparar el resultado con la muestra acordada.
- Cobertura parcial: simular una fuente sin datos; mostrar la ausencia y conservar las fechas reales sin presentar el lote como completo.
- Revisión consistente: recorrer todas las páginas de la API sobre el mismo lote; comprobar identificadores y recuentos sin omisiones ni repeticiones.
- Permisos: usar perfiles autorizados y restringidos; verificar campos visibles, descarga y acceso a evidencia por cada canal contratado.
- Corrección: sustituir un valor aprobado por una nueva revisión y demostrar cómo el consumidor reconoce la versión vigente.
- Uso operativo: pedir al destinatario que complete su tarea con la entrega y registrar los pasos manuales que siguen siendo necesarios.
Para aceptar el trabajo, acordaría qué evidencia se guarda, quién la revisa y qué fallos bloquean la puesta en marcha. Si el equipo sigue reconstruyendo datos fuera del flujo acordado, revisaría el alcance antes de dar la entrega por resuelta.
Presupuesto y mantenimiento de la entrega
Separaría extracción, preparación de datos, canal de entrega e integración en destino. Más campos, fuentes, roles, frecuencia o histórico pueden cambiar el esfuerzo. Un dashboard con aprobaciones tiene un alcance distinto de una pantalla de consulta; una API necesita también un consumidor que funcione.
La checklist para comparar presupuestos ayuda a pedir los mismos entregables a cada proveedor. Incluiría muestra validada, diccionario de campos, instrucciones de uso, pruebas y responsable del soporte; no asignaría un precio sin conocer esas condiciones.
Separaría también el mantenimiento del scraper de la monitorización de entregas y alertas. Una captura correcta no demuestra que el destinatario haya recibido información utilizable.
El caso Adslyfy muestra paneles, estados de ejecución y capturas para revisar monitorización de anuncios. Sirve como referencia de visibilidad operativa; no acredita resultados del ejemplo de catálogo ni una entrega CSV o API.
Qué preparar antes de contratar la integración
Si los archivos ya resuelven el proceso sin correcciones recurrentes, puede bastar con documentarlos y comprobar su entrega. Si faltan reglas, permisos o una conexión estable, puedo ayudarte desde el servicio de plataformas internas e integraciones. Cuando la decisión afecta a varios equipos y proveedores, también puede requerir dirección técnica.
Cuéntame cómo necesitas usar los datos: herramienta de destino, persona responsable, frecuencia, retraso tolerable y un ejemplo ficticio de entrada y salida. Con esa base puedo revisar contigo el canal y definir una primera entrega comprobable.