Caso de Éxito · Motor propio de rastreo web

El rastreador que sabía frenar

Un comercio con miles de referencias no sabe a qué precio vende su competencia. Puede mirar a mano media docena de productos estrella; el resto del catálogo es una nube. Nicole fue el motor que recorría el mercado entero cada noche para contestar, cada mañana, una sola pregunta: en qué productos ganamos y en cuáles perdemos.

El reto

Rastrear la web ajena es fácil de hacer mal. Lo difícil no es sacar los datos: es sacarlos sin convertirte en un problema para quien te los da.

El encargo tenía tres obstáculos, y solo uno era el evidente. Recorrer catálogos ajenos de forma sostenible, sin castigar los servidores de nadie y sin esconderse. Saber que dos fichas de dos tiendas distintas son el mismo producto, cuando cada tienda le pone su propio código, su propio título y su propia foto. Y sostener un trabajo que no cabe en una máquina y que no termina nunca.

Qué construimos

Tres piezas encadenadas

Una recorría, otra reconocía y la tercera comparaba. Ninguna servía sin las otras dos.

Recorrer
El rastreador

Descubría los catálogos entrando por la puerta que cada sitio publica para los buscadores, y volvía sobre ellos con su propio calendario.

  • Descubrimiento por los sitemaps declarados
  • Bot identificado con nombre y documentación
  • Ritmo configurable sitio por sitio
  • Rastreo contenido dentro del dominio
Reconocer
El extractor

Leía de cada ficha los datos que la propia tienda publica en abierto para que los buscadores la entiendan, con varios formatos de respaldo.

  • Datos estructurados de Schema.org
  • Microdatos y etiquetas sociales como respaldo
  • Precio, disponibilidad, marca y variantes
  • Extractores a medida cuando no bastaba
Comparar
El comparador

Cruzaba el catálogo propio con el del mercado y emitía cada mañana el informe que justificaba todo lo anterior.

  • Homologación por código de barras
  • Posición de precio producto a producto
  • Movimientos de la competencia con su porcentaje
  • Cobertura y frescura de cada sitio vigilado
Por qué importa

Tres decisiones que definieron el proyecto

Se frenaba cuando molestaba

Cuando un sitio respondía con el código que significa «vas demasiado rápido», el sistema no reintentaba ni cambiaba de identidad: aumentaba su propia espera para ese sitio y se detenía cinco minutos. El ajuste quedaba guardado, así que la siguiente vez ya empezaba más despacio.

El código de barras como llave

Comparar precios cotejando títulos a ojo no funciona. El número que hay bajo el código de barras lo asigna el fabricante, no el vendedor, así que es el mismo en todas las tiendas del mundo. Esa fue la llave que hizo posible la comparación.

La flota se gobernaba desde una tabla

Arrancar, parar y repartir el trabajo entre varias máquinas no se hacía entrando en cada una: se hacía cambiando un renglón en la base de datos. Cada servidor consultaba qué le tocaba y obedecía.

Bajo el capó

Los problemas difíciles

Cuatro cosas que decidían si el sistema podía funcionar durante meses o se quemaba en la primera semana.

01

Recorrer sitios ajenos sin volverse un problema

Un rastreador mal educado tumba servidores, acaba bloqueado y deja a su dueño en una conversación incómoda. La tentación es esconderse y seguir. Aquí se hizo lo contrario, y esa decisión es la que permite contar este caso.

Entrar por la puerta publicada

El sistema no adivinaba direcciones: leía el archivo que cada sitio publica para los buscadores, sacaba de ahí los mapas del catálogo y seguía lo que el propio comercio había puesto ahí para ser encontrado.

Decir quién eres

El rastreador se presentaba con el nombre del robot, su versión y una dirección donde se explicaba qué hacía. Quien recibiera la visita sabía quién era y a quién reclamar.

Frenar ante la señal de freno

Al recibir el código que indica exceso de peticiones, el robot aumentaba su espera para ese sitio y se detenía. Aprendía el ritmo que cada servidor toleraba, y no lo olvidaba.

No repetir trabajo hecho

Los mapas del catálogo indican cuándo cambió cada sección. El sistema los respetaba y no volvía a descargar lo que seguía igual: menos carga para el otro y menos tiempo para nosotros.

Un rastreador que se identifica, entra por donde debe y se frena cuando molesta es un vecino. Uno que se disfraza y machaca es un problema.

02

Saber que dos fichas son el mismo producto

Cada tienda inventa su propio código interno, redacta su propio título y hace su propia foto. Dos fichas del mismo objeto pueden no compartir ni una palabra. Sin resolver esto, no hay comparación posible y todo lo demás sobra.

Un identificador que nadie inventa

El número del código de barras lo asigna el fabricante del producto, no quien lo vende. Es el único dato de una ficha que significa lo mismo en todas las tiendas.

Sacarlo de lo que ya está publicado

Las tiendas lo publican en sus datos estructurados para que los buscadores las entiendan. El sistema lo leía de ahí, junto con marca, modelo, condición y disponibilidad.

Cascada de respaldo

No todas las tiendas etiquetan igual. Si no había datos estructurados se intentaba con microdatos, y si tampoco, con las etiquetas sociales de la página. Cada formato cubría los huecos del anterior.

Regla de admisión

Una ficha solo entraba en el índice como producto si tenía al menos una referencia identificable. Lo que no se podía identificar no se guardaba: un índice lleno de basura no se puede comparar.

Con esa llave, dos catálogos que no comparten ni una palabra se vuelven comparables renglón a renglón.

03

Repartir el trabajo sin que dos máquinas se pisen

Rastrear un mercado entero no cabe en un servidor, y varios servidores haciendo lo mismo es peor que uno solo: gastas el doble para obtener la mitad, y molestas al doble de sitios.

Un tramo para cada proceso

El trabajo se repartía por tramos del índice, de modo que dos procesos nunca tomaban las mismas direcciones. Añadir capacidad era añadir tramos.

Órdenes desde la base de datos

Arrancar o parar un proceso en cualquier máquina de la flota se hacía cambiando su estado en una tabla. Cada servidor consultaba lo suyo y obedecía sin que nadie entrara en él.

Procesos que se levantan solos

Cada tarea corría dentro de un bucle supervisado: si el proceso moría por un dato inesperado, volvía a arrancar sin intervención. En un trabajo que dura meses, morir es normal; quedarse muerto, no.

El servidor se protegía a sí mismo

Cada máquina reportaba su carga, su memoria y su disco. Si la carga superaba lo que sus procesadores aguantaban, el propio servidor apagaba una de sus tareas sin preguntar.

Una flota que se reparte el trabajo, se recupera sola de sus caídas y se frena antes de ahogarse.

04

Que el índice no se pudra con el tiempo

Un catálogo ajeno cambia todos los días: productos que se descatalogan, direcciones que se rompen, secciones que se reorganizan. Un índice que no gestiona sus muertos deja de valer en unos meses.

Descubrir y extraer a ritmos distintos

Cada dirección llevaba dos fechas separadas: cuándo se buscó en ella y cuándo se le extrajo el contenido. Así una fase podía ir deprisa sin arrastrar a la otra.

Duda razonable antes de borrar

Si una dirección empezaba a fallar pero tenía productos asociados, no se eliminaba: se aplazaba unos días. Muchos errores son temporales, y borrar el historial de precios de un producto es irreversible.

Y borrado cuando toca

Si volvía a fallar igual y no tenía nada que perder, se eliminaba del índice. Cargar con direcciones muertas es pagar cada noche por nada.

Prioridad a lo nunca visto

Cada pasada atendía primero lo que jamás se había revisado y solo después lo ya revisado hace tiempo. El índice crecía antes de refrescarse.

El índice se mantenía vivo solo, que es la diferencia entre un rastreo y una foto vieja.

Lo que este proyecto demuestra

Lo que este proyecto demuestra

Rastreo web hecho con oficio: el que sostiene una operación durante meses sin dejar un rastro de servidores molestos detrás.

Motores de rastreo web propios, de principio a fin
Cortesía de rastreo y autorregulación de ritmo
Extracción de datos estructurados de producto
Homologación de catálogos por identificador global
Vigilancia competitiva de precios
Sistemas distribuidos gobernados por base de datos
Procesos supervisados que se recuperan solos
Gestión del ciclo de vida de un índice grande
Informes diarios automatizados para negocio
Trabajo por lotes a escala de catálogo completo

Un proyecto terminado, y contado en pasado

Nicole estuvo en producción y hoy no está en marcha. Lo publicamos porque el trabajo fue real y las decisiones que se tomaron ahí siguen siendo las que tomaríamos hoy.

El cliente no se nombra

Fue un encargo bajo confidencialidad. Contamos qué construimos y cómo, sin decir para quién ni en qué mercado. Eso no es negociable aunque el proyecto haya terminado.

Rastreo con reglas

El rastreador se presentaba con su nombre, entraba por donde el sitio publica y se frenaba ante la señal de freno. Si un proyecto no se puede hacer así, la conversación que toca es otra.

Contamos solo lo verificado

Esta página salió de una revisión del código que escribimos, no de un folleto. Lo que no encontramos funcionando, no está aquí.

Un motor de rastreo completo —descubrimiento, extracción, homologación y comparación— repartido entre varias máquinas y sostenido en el tiempo.

¿Sabes a qué precio vende hoy tu competencia?

No en tus diez productos estrella: en todo tu catálogo, y cada mañana. Recoger datos de la web ajena de forma sostenible y convertirlos en una decisión de negocio es un oficio, y es el nuestro.