El Black Friday de 2026 cae el 27 de noviembre, y el Cyber Monday el 30 de noviembre. Quedan alrededor de siete semanas hasta el pico, lo que es justo suficiente para preparar el parser de precios. Si comienzas en noviembre, descubrirás las debilidades del sistema justo el día de la venta: los competidores cambian los precios cada hora, mientras que tu panel muestra datos de ayer o celdas vacías.
En esta guía, encontrarás un plan paso a paso de seis semanas: cómo recalcular el presupuesto de tráfico para la frecuencia máxima, qué proxies usar para qué sitios, cómo detectar precios "envenenados" que el sitio ofrece a los bots, y qué hacer el mismo día de la venta.
Por qué el parser falla más a menudo en Black Friday
En resumen: en estos días, los sitios experimentan un aumento tanto en el tráfico humano como en el tráfico de bots, por lo que la protección se ajusta más estrictamente que en el resto del año. Aquí están las cifras de la temporada pasada.
- Dinero en juego. Según Adobe Analytics, durante la semana del Día de Acción de Gracias hasta el Cyber Monday de 2025, los estadounidenses gastaron en línea $44,2 mil millones (+7,7% interanual). Solo en Black Friday, un récord de $11,8 mil millones, y en Cyber Monday, $14,25 mil millones. Los descuentos en electrónica alcanzaron hasta el 31% del precio.
- Los bots casi igualan a los humanos. Radware en su informe de 2026 indica que en el "Cyber Five" de 2025, los bots maliciosos representaron alrededor del 43% del tráfico en las tiendas en línea que protege, mientras que los humanos representaron alrededor del 46%. El año anterior, la proporción de bots malos era del 31%.
- Aumentan los ataques justo en los días de venta. Imperva registró un aumento del 50% en los ataques de bots al retail en Black Friday de 2025 en comparación con el promedio de noviembre, y el tráfico total fue un 37% más alto. Entre las amenazas típicas, Imperva menciona específicamente la recopilación automática de precios y existencias, así como la rotación de IP a través de proxies anónimos y VPN.
¿Qué implica esto en la práctica? El minorista ve una ola de bots, activa un modo estricto de anti-bots, establece una cola virtual para los productos populares y restringe más la frecuencia de solicitudes desde una sola IP. Tu parser, que funcionó sin errores durante todo octubre, se encuentra con un captcha o recibe un 403. Debes prepararte para este modo estricto, no para un día normal.
Paso a paso: plan de seis semanas
Semanas 1–2 (mediados de octubre): inventario y prioridades
- Clasifica los productos en niveles. Posiciones "calientes", para las que realmente cambias tus precios (generalmente el 5–15% del catálogo), "tibias" para análisis y "frías" para fondo. En el pico, la alta frecuencia solo es necesaria para los productos calientes.
- Haz una lista de los sitios de los competidores y su protección. Revisa cada uno y anota quién está frente al sitio: Cloudflare, Akamai, DataDome, su propio WAF. Esto determina el tipo de proxy (más detalles a continuación).
- Encuentra APIs internas. Abre la tarjeta del producto, la pestaña Network en DevTools y busca una solicitud JSON con el precio. Si existe, la solicitud a ella es mucho más fácil que a la página completa, lo que significa que consume menos tráfico y carga menos el sitio.
- Registra un estándar. Toma las métricas actuales: tasa de respuestas exitosas, tamaño promedio de respuesta, tiempo por tarjeta. Sin ellas, en noviembre no tendrás con qué comparar.
Semanas 3–4: recalculo del presupuesto y prueba de carga
- Calcula el tráfico para la frecuencia máxima. La fórmula es simple: número de productos × verificaciones por día × tamaño promedio de respuesta × número de días de pico. Ejemplo: 2,000 tarjetas calientes × 24 verificaciones × 0.4 MB ≈ 19 GB por día. Si el pico dura cinco días (de viernes a lunes más precalentamiento), resulta en aproximadamente 95 GB — solo para el nivel caliente. Hemos escrito en detalle sobre el cálculo en el análisis de el presupuesto para monitorear 10,000 productos.
- Deja un margen para repeticiones. En modo estricto de anti-bots, parte de las solicitudes tendrán que repetirse. Si en días normales la tasa de repeticiones es del 5%, para el pico considera un 20–30%. Es importante calcular no el "costo por gigabyte", sino el costo de una entrada exitosa: un pool barato que devuelve la mitad de captchas, al final cuesta más.
- Realiza una prueba de carga. Activa la frecuencia máxima durante 2–3 horas en sitios reales. Observa tres cosas: dónde comienzan los 403/429, cuántas solicitudes desde una IP generan un captcha, cómo aumenta el tiempo de respuesta.
- Define pausas y sesiones. Según los resultados de la prueba, establece un límite de solicitudes por dominio y el tiempo de vida de la sesión. Generalmente, es mejor tener más IPs paralelas con menor carga en cada una que unas pocas IPs "a plena carga".
Semana 5: protección contra errores silenciosos
La falla más peligrosa es la que no se ve. El sitio no bloquea al bot, sino que le entrega una página en caché, un precio sin descuento o un mensaje de "producto no disponible". ¿Qué implementar?
- Verificación de rango. Si el precio se ha movido más del 60–70% respecto a ayer o a la mediana de los competidores, la entrada se marca para re-verificación desde otra IP, en lugar de ir directamente al re-pricer.
- Productos de control. 10–20 posiciones, cuyo precio conoces de antemano (o verificas manualmente). Si el parser comienza a fallar en ellos, el problema está en todo el flujo.
- Verificación de moneda y región. El sitio determina el país por IP. Si el proxy entrega una IP de un país diferente, verás el precio en una moneda ajena o una promoción diferente. Verifica la geolocalización de la IP de salida y la moneda en la página.
- Alerta por tasa de errores. No por un fallo aislado, sino por una tendencia: por ejemplo, "respuestas exitosas menos del 85% durante más de 15 minutos".
Semana 6 (la semana antes del pico): congelación y reserva
- Congela el código. Ninguna nueva función en el parser una semana antes del Black Friday — solo corrección de errores.
- Recarga el saldo con anticipación. El tráfico con el proveedor de proxies debe estar disponible con un margen hasta el Cyber Monday incluido. Recargar la cuenta a las 23:00 del viernes es una mala idea.
- Prepara un plan B para cada sitio. Si el método principal falla: qué tipo de proxy conectar, qué frecuencia reducir, qué productos desactivar primero.
- Asigna un encargado. Una persona que vigile el panel en horas pico y sepa qué ajustes hacer.
Qué proxies usar para qué tareas
No hay una respuesta universal, depende de la protección de cada sitio. Un esquema de trabajo para la temporada de ventas:
- Data center — para sitios sin un anti-bots serio, APIs internas sin protección y nivel "frío". Rápido y barato, pero en sitios con Akamai o DataDome, en días pico, esas IPs son las primeras en ser bloqueadas: sus rangos son conocidos.
- Proxies residenciales — la herramienta principal para el nivel caliente en sitios protegidos. IPs de proveedores domésticos más segmentación por país y ciudad, para ver el mismo precio que el comprador en la región adecuada. La rotación en cada solicitud es adecuada para tarjetas individuales; una sesión fija de 5–10 minutos es para escenarios donde necesitas pasar por varias páginas consecutivas (catálogo → tarjeta → carrito para verificar el precio final).
- Proxies móviles — reserva para los objetivos más estrictos y versiones móviles de sitios y aplicaciones. Una IP de un operador es compartida por miles de abonados reales, por lo que bloquearla no es rentable para el sitio. Más caras, así que úsalas de manera puntual — donde las residenciales no funcionan.
Un consejo para ahorrar: desactiva la carga de imágenes, fuentes y videos si trabajas a través de un navegador. En la tarjeta del producto, pueden representar gran parte del peso de la página, y no son necesarias para el precio.
El día de la venta: qué hacer por horas
- La noche antes del inicio. Muchas tiendas lanzan promociones a medianoche según su hora local. Aumenta la frecuencia para los productos calientes una hora antes del inicio, para fijar el precio "antes".
- Las primeras horas. El momento más estricto para el anti-bots. Si la tasa de errores aumenta, primero reduce la frecuencia en el nivel "tibio", en lugar de cambiar todo de una vez.
- Cola virtual. Si el sitio ha establecido una sala de espera, no intentes asaltarla — solo quemarás tráfico y IP. Deja las tarjetas en espera y verifícalas con menos frecuencia, hasta que se elimine la cola.
- Pico de la tarde. Según Adobe, en Cyber Monday de 2025, se compró más entre las 20:00 y las 22:00 (hora de EE.UU.) — en ese momento, los estadounidenses gastaban $16 millones por minuto. Para el mercado estadounidense, estas son las horas en que los precios y existencias cambian con mayor frecuencia.
- Después del pico. Los descuentos no desaparecen de inmediato: Adobe registró descuentos significativos también en la primera semana de diciembre. No apagues el monitoreo el martes — reduce la frecuencia gradualmente.
Errores típicos
- Frecuencia uniforme para todo el catálogo. El presupuesto se gasta en productos para los que no cambias el precio.
- Prueba en una sola IP. La prueba "todo funciona" desde una dirección no dice nada sobre el comportamiento en miles de solicitudes.
- Confianza en el código 200. Una respuesta sin error no significa que el precio sea correcto.
- Ignorar las reglas del sitio. Recoge solo precios públicos, no toques cuentas personales y no generes una carga en el sitio que impida a los compradores reales. Esto es tanto justo como reduce los riesgos legales.
Conclusión
El Black Friday es una prueba no de la velocidad del parser, sino de la preparación. Clasifica el catálogo por prioridades, recalcula el tráfico con un margen para repeticiones, realiza una prueba de carga un mes antes del pico, establece verificaciones contra "basura silenciosa" y distribuye las tareas por tipos de proxy: data center para objetivos simples, residenciales para el flujo principal, móviles para los sitios más protegidos. Así, el 27 de noviembre estarás observando los precios de los competidores, no los registros de errores.
