Empecemos por lo que un scraper sí resuelve, o el resto sonará a argumento de venta.
Para necesidades puntuales, de poco volumen y campos simples, escribir tu propio script suele ser el camino más rápido. Títulos y precios de cien ASIN, una vez y nunca más: medio día de escritura, diez minutos de ejecución, más rápido que evaluar una API, registrarse e integrar. Ahí, montarlo tú es la decisión correcta.
Los costes se tuercen en el otro caso: el script funciona y alguien dice "pues vamos a lanzarlo a diario".
Desde ese momento deja de ser un script puntual y pasa a ser una tubería de datos que hay que mantener — y cuatro costes empiezan a contar.
Coste 1: el mantenimiento antibot es recurrente, no puntual
Que la primera versión funcionara aporta menos información de la que casi todo el mundo supone.
Lo que demuestra es que esta estructura de página, a esta frecuencia, desde esta ubicación, hoy, se podía leer. De esas cuatro condiciones solo la primera está bajo tu control — y también cambia.
El gasto real está en la estabilidad. El script iba bien ayer; hoy devuelve arrays vacíos, no lanza ningún error y entrega en silencio un tercio menos de datos. Para esta clase de problema no hay traza de pila, solo una persona comparando salidas. Y ocurre en un calendario aleatorio, normalmente fuera del horario laboral entre semana.
La forma de este coste: las horas de desarrollo son puntuales, las horas de diagnóstico son recurrentes y el intervalo no lo decides tú. Lo segundo es lo que los presupuestos se saltan, porque cuando se aprueba el proyecto todavía no existe.
Esta entrada no cubre ningún método para evadir la detección. Si la viabilidad de un plan depende de sortear las medidas técnicas de un tercero, lo que hay que ajustar es el alcance del plan, no la técnica.
Coste 2: tienes que definir tú la semántica de los campos
El más subestimado, porque no parece un coste.
La página tiene un BSR. La página no tiene "ventas mensuales".
Lo que puedes rascar es la entrada del modelo, no su salida. Para pasar de un puesto a unidades necesitas una curva de conversión, y ajustar esa curva exige muestras etiquetadas con ventas reales — que solo existen dentro de las cuentas de los propios vendedores. No es una dificultad de ingeniería: simplemente no tienes las muestras.
El mismo problema se repite en muchos campos:
| Crees que rascas un campo | Lo que en realidad debes decidir antes |
|---|---|
| Precio | ¿Precio de lista, precio de oferta o tras aplicar cupón? Cada vendedor lo muestra distinto |
| BSR | ¿Puesto de categoría raíz o de subcategoría? La ruta de categorías tiene varios niveles |
| Ventas | No está en la página. O lo omites o construyes un modelo |
| Número de valoraciones | ¿Agregado en el padre o el del hijo concreto? |
| Categoría | ¿El nombre visible de la miga de pan o el ID de nodo? Los nombres cambian; los IDs aguantan mejor |
Cada fila es una definición que alguien tiene que zanjar. Una API entrega un contrato con semántica definida; un scraper entrega lo que la página mostrara ese día. Dos personas rascando la misma página obtienen números distintos sin que ninguna haya escrito un error — en una tubería propia eso es lo normal.
Peor aún: esas definiciones no suelen escribirse. Viven en la cabeza de quien escribió los selectores. Tres meses después, nadie sabe decir qué significa esa columna.
Sobre la frontera entre campos factuales y derivados, Qué dicen y qué no dicen los datos de ventas de Amazon profundiza más.
Coste 3: cumplimiento y exposición de la cuenta
Este no es un problema técnico, y por eso suele faltar en la evaluación de ingeniería.
Hay que sopesar los términos de servicio de la plataforma, el alcance de uso permitido y cómo se relaciona todo ello con tu propia cuenta de vendedor. Quien asume el riesgo es el negocio, no quien escribe el script — y sin embargo la conversación de arranque suele ser solo de ingeniería.
Un movimiento práctico: antes de empezar, pide al lado de negocio que responda claramente quién lo asume si esta vía de recolección genera un problema a nivel de cuenta. La respuesta no tiene que ser complicada, pero alguien tiene que darla. Si nadie quiere, el riesgo no se ha aceptado: solo se ha aplazado.
Coste 4: cuando se va quien lo mantiene, los datos se paran
Los tres anteriores se resuelven con dinero y tiempo. Este no.
Muy poco del conocimiento real de un scraper vive en el código: por qué un selector está escrito así, qué campo difiere en qué marketplace, qué fallos reintentar y cuáles saltar, cómo se parcheó el último rediseño. Nada de eso se documenta, porque en su momento era todo evidente.
Cuando se va quien lo escribió, el siguiente rediseño de página es el final del trayecto. No porque no se pueda arreglar, sino porque arreglarlo cuesta lo bastante como para que nadie lo apruebe: quien lo hereda tiene que reconstruir la lógica entera por ingeniería inversa, y la única especificación es el código.
Este riesgo escala a la inversa del tamaño del equipo. En un equipo de tres, normalmente hay exactamente una persona que entiende la capa de recolección.
La forma de los cuatro costes
| Puntual | Recurrente | Impredecible | |
|---|---|---|---|
| Mantenimiento antibot | Primera versión | Diagnóstico y reparación | Cuándo llegan los rediseños |
| Semántica de campos | Definir campos | Comprobar desviaciones | Cambios de estructura de página |
| Cumplimiento | Una evaluación | — | Cuándo se materializa |
| Mantenedor | — | Traspaso y documentación | Cuándo se marcha |
La tercera columna es el sentido de esa tabla. Los costes presupuestables no son los peligrosos; los impredecibles sí. El coste recurrente de una API de terceros cae en la segunda columna: sigue al volumen de llamadas, se calcula y escala linealmente con el negocio. El coste principal de una tubería propia cae en la tercera.
Eso no hace que montarlo tú sea más caro. Lo hace caro de otra manera: no es una factura mayor, es una factura cuya fecha de llegada desconoces.
Cuándo montarlo sigue teniendo sentido
Una prueba carga con casi todo el peso: ¿lo necesita alguien más que tú?
- Necesidad común → casi seguro que un endpoint ya lo cubre, y rascarlo es reinventar la rueda
- Específico de tu negocio de verdad → montarlo se sostiene, porque no hay segunda opción
Dos condiciones más lo hacen más seguro: que la necesidad sea puntual o de baja frecuencia, y que los campos sean lo bastante simples como para no exigir definir semántica. Con las tres, escribe el script. Si falta una, mira primero el catálogo.
Catálogo de API46 endpoints agrupados por productos, palabras clave, mercados, tráfico y marcas — comprueba si el campo que necesitas ya está cubiertoSi todavía no has elegido vía, Cómo elegir una API de datos de Amazon compara qué te da cada una de las tres: SP-API oficial, endpoints de terceros y recolección propia. Esta entrada desarrolla la columna de recolección propia de esa comparación.
Preguntas
¿Merece la pena rascar a pequeña escala? Para necesidades puntuales con campos simples, sí. En cuanto se convierte en una tarea programada diaria, estos cuatro costes empiezan a contar.
¿Rascar sale más barato que llamar a una API? Más barato al principio, porque son solo horas de desarrollo. Una vez cuentas el tiempo de diagnóstico, la deriva semántica y el riesgo del mantenedor, normalmente no. La diferencia clave no es el total: es la previsibilidad.
¿Puedo rascar las cifras de ventas? Ese campo no está en la página. Lo que puedes rascar es el BSR, y pasar de BSR a unidades exige una curva de conversión, que a su vez exige muestras etiquetadas con ventas reales. Esas muestras no están en datos públicos.
¿Puedo usar ambas cosas? Sí, y es habitual. Lleva los campos comunes por una API y recoge solo los campos de cola larga que nadie más necesita. Así la parte propia queda lo bastante pequeña como para que los cuatro costes sigan siendo manejables.