Ir al contenido
INTELIGENCIA COMPETITIVA Y DE PRECIOS

Una pipeline que convierte un catálogo público en un histórico de precios

Revisar a un competidor a mano da una foto fija y ninguna forma de compararla con la semana pasada. Construimos una pipeline que lee catálogos públicos página a página en un navegador renderizado, deduce por su cuenta la estructura de categorías y la paginación de un sitio, demuestra que su receta de extracción devuelve productos reales antes de fiarse de ella, y escribe un punto de precio en cada pasada. El informe que sigue es una diferencia y no un volcado, y no sale de casa hasta que una persona lo aprueba.

  • SectorRetail y comercio electrónico
  • Tipo de trabajoPlataforma propia, construida en casa
  • EstadoFunciona de extremo a extremo, con partes aún sin terminar
  • Inteligencia de precios
  • Recogida de datos web públicos
  • Investigación competitiva
  • Pipelines de datos

Un solo bucle: recoger, normalizar, comparar, empaquetar, aprobar

La pipeline corre por calendario para cada cliente. Primero rastrea el dominio propio del competidor en busca de páginas que merezca leer, y después recoge el catálogo en sí: categoría a categoría, página a página, dentro de un navegador renderizado. Porque un catálogo construido en JavaScript no está en el HTML que devuelve una petición simple. Las reseñas y las publicaciones públicas alimentan el mismo almacén, así que lo que sale describe a un competidor y no solo una lista de precios.

Todo lo recogido se normaliza a la misma forma. Los importes se analizan hasta obtener un número y una moneda en formatos europeos, turcos y estadounidenses. Los productos se actualizan por identidad, de modo que una pasada nueva actualiza en vez de clonar, y las fechas de primera y última vez vistas son lo que hace calculables lo nuevo y lo desaparecido. Cada pasada con un precio escribe además un punto de precio, y por eso el informe puede ser una diferencia y no un volcado.

El espacio de trabajo en plena tarea: catálogos ya recogidos, el análisis de reseñas al lado y trabajos de recogida que informan de su propio avance. Los nombres de los competidores están difuminados en la propia grabación.
EL RETO

Qué lo hacía difícil

Leer a un competidor no es un problema de scraping. La pipeline se diseñó contra estos tres fallos.

Una foto fija no se puede comparar con nada

Mirar precios a mano produce una lista que ya es vieja al escribirla y que no tiene nada detrás. La pregunta que un equipo de categoría hace de verdad es qué se movió desde la última vez, y ninguna copia cuidadosa la responde, porque el estado anterior nunca se guardó.

El catálogo no está en el código de la página

Las tiendas de hoy montan su rejilla de productos después de cargar, cuelgan las imágenes de atributos de carga diferida y reparten una categoría entre páginas según lo que prefiera su plataforma. Leer el código de una página de categoría devuelve una cáscara vacía.

Una lectura fallida se parece exactamente a un estante vacío

El fallo peligroso no es el que rompe. Es la pasada que termina limpia y dice que no encontró nada cuando lo que ocurrió fue un tropiezo de red. Ese resultado es indistinguible de un cambio real y envenena la comparación que viene después.

LA SOLUCIÓN

Lo que construimos

Un bucle programado: llegar al catálogo, entender su estructura, hacer comparables los valores y convertir la diferencia en algo que una persona firme.

Recogida que llega de verdad al catálogo

El rastreo se queda en el dominio propio del competidor, respeta robots.txt, se limita el ritmo, acota hasta dónde llega y visita las páginas de precio y de producto antes que las genéricas. La recogida del catálogo va aparte: la extracción corre dentro de la página renderizada, porque ahí es donde existe una rejilla hecha en JavaScript.

  • Rastreo en el mismo dominio que respeta robots.txt, se limita el ritmo y lee primero las páginas comerciales.
  • Tres motores de recogida con reserva automática: una dependencia opcional ausente degrada el rastreo en lugar de tumbarlo.
  • Paginación por parámetro, por enlace siguiente, listados de una sola página y desplazamiento infinito, cada caso identificado sondeando el sitio en vez de suponiéndolo.

Estructura que el modelo propone y el código demuestra

Las categorías reales de un sitio se deducen de sus propios enlaces y de su mapa del sitio, y después se clasifican. Nada se acepta por la fuerza de esa clasificación: una puerta de resolver y extraer tiene que demostrar que la receta propuesta devuelve productos de verdad en la página en la que dice funcionar.

  • Las categorías candidatas salen de la navegación del propio sitio y de su mapa del sitio, y cada una se valida antes de usarse.
  • Una receta de extracción propuesta solo merece confianza cuando se demuestra que rinde productos, con una prohibición dura de inventar en la pasada de clasificación.
  • La extracción de nombre y de precio cae por una cadena de alternativas y prefiere la coincidencia limpia más corta, para no confundir una ficha entera con un nombre.

Valores que de verdad se pueden comparar

Un precio en una página es una cadena con un símbolo de moneda, con un separador de miles que significa cosas distintas según el país y, a menudo, con una etiqueta de descuento al lado. Todo se analiza a importe y moneda antes de guardarse, y las marcas salen de una lista cuidada que se niega a adivinar.

  • Los importes se analizan en formatos europeos, turcos y estadounidenses, con la moneda leída al lado.
  • La etiqueta de porcentaje se retira antes de analizar y gana el último importe anclado a una moneda, así que un descuento nunca se guarda como precio.
  • Los productos se deduplican por identidad entre pasadas, de modo que releer actualiza un producto en vez de clonarlo.

Un informe que es una diferencia, y una persona que lo firma

Cada pasada con un precio escribe un punto de histórico, así que la siguiente ya es una comparación. El informe de cambios se calcula con lo que hay en disco: sin llamada al modelo, sin red, sin tablas nuevas. El renderizado deja algo en estado pendiente de revisión, y la aprobación es la única ruta de código que envía.

  • Subidas y bajadas, productos nuevos, productos desaparecidos y reseñas nuevas, todo calculado de forma determinista.
  • Un paquete de datos en hoja de cálculo y una presentación, renderizados byte a byte igual a partir de entradas idénticas.
  • Nada llega al buzón de un cliente sin que una persona lo apruebe, y sin proveedor de correo configurado el envío se niega en lugar de registrar uno que nunca ocurrió.
INGENIERÍA

Las decisiones que hacen que el informe merezca leerse

Cuatro decisiones que iban de acertar, no de impresionar.

Una lectura fallida no es un estante vacío

Una petición fallida, una página cargada pero sin nada, y una página con productos son tres resultados distintos en el código y no uno. Una pasada se declara completa, parcial o fallida sobre esa evidencia, así que un problema pasajero de red nunca llega como un resultado limpio y vacío.

La condición de parada es del código

La detección de huecos es por reglas y tiene un tope duro por pasada, y el crítico opcional del modelo va encima y viene apagado. Un escaneo no cuesta nada en el modelo mientras nadie lo encienda a propósito, y ningún modelo de lenguaje decide cuándo el trabajo está terminado.

Un orden que sobrevive a la base de datos

La cronología vive en una marca de tiempo de microsegundos tomada en la lectura y no en el orden de inserción, con un identificador aleatorio solo como último desempate. Un histórico de precios se lee igual sea cual sea la base de datos que haya debajo.

Aislamiento en un único cuello de botella

Cada lectura y cada escritura pasan por un único punto de alcance, respaldado por seguridad de fila en la propia base de datos, y el servicio se niega a arrancar si su propio rol de ejecución pudiera saltárselo. El motor de comparación hereda ese límite en vez de reconstruirlo.

EL IMPACTO

Qué cambió

Cualitativo, porque lo que dio este proyecto es un bucle que funciona y no un resultado medido.

Histórico

Comparación en vez de foto fija

La primera pasada produce un catálogo. Cada pasada posterior produce una diferencia, porque los precios que hay detrás ya están en disco con la fecha en que se leyeron.

Honesto

Pasadas que admiten lo que se perdieron

Una pasada que no pudo leer algo lo dice y se marca como parcial. Nada aguas abajo tiene que adivinar si una sección vacía significa que el competidor cambió o que una petición falló.

Revisado

Una persona antes que el cliente

Renderizar un informe y enviarlo son dos pasos separados a propósito. Nunca ha salido nada solo porque saltara un calendario, y una sonda de salud recorre el bucle entero sin tocar la red ni gastar nada en el modelo.

Última revisión:

¿Tiene un catálogo que merezca vigilarse?

Cuéntenos qué fuentes le importan y qué debería decir un informe útil. Acotaremos la recogida con honestidad, incluidas las partes que rechazaríamos.

Empezar una conversación