La recopilación de datos con sesión iniciada suele requerir varias cuentas, y las limitaciones de tráfico no siempre se deben al script. Separar el riesgo de asociación en características del dispositivo, salida de red, estado de sesión y ritmo de solicitudes aclara qué variables se pueden controlar.
La recopilación de datos de comercio electrónico suele dividirse en dos tipos: la captura de páginas públicas que no requieren inicio de sesión y la recopilación con sesión iniciada, por ejemplo para consultar datos de administración de competidores u obtener resultados mostrados después de una personalización.
En el primer caso, normalmente basta con controlar la frecuencia. Cuando el segundo caso implica varias cuentas, el éxito ya no depende tanto de lo ingenioso que sea el script, sino de que esas cuentas puedan existir de forma independiente. Si esta capa no está bien resuelta, las limitaciones y los bloqueos parecen aleatorios, y cambiar el script, reducir la frecuencia o sustituir selectores no mejora la situación.
De dónde viene el riesgo
Las plataformas determinan si varias cuentas están siendo operadas por la misma parte mediante comprobaciones cruzadas: direcciones de red, características del navegador y del dispositivo, datos de Cookie y sesión, y patrones de uso. Una coincidencia alta en cualquiera de estas categorías puede hacer que las cuentas queden agrupadas bajo el mismo operador.
Aquí conviene marcar un límite. La lógica de detección se actualiza continuamente, por lo que intentar contrarrestarla con trucos temporales ofrece beneficios breves a un coste alto. Por eso no se analiza cómo eludir los controles de riesgo. La cuestión útil es otra: una vez identificadas las fuentes de riesgo, ¿qué variables podemos controlar y mantener estables a largo plazo? Esas variables determinan si varias cuentas legítimas pueden terminar afectándose entre sí.
Características del dispositivo y del navegador
Una de las combinaciones más propensas a errores es abrir varias ventanas en el mismo equipo e iniciar sesión en cuentas distintas. Aunque se borre la caché o se utilice el modo incógnito, esas ventanas siguen compartiendo el mismo entorno del sistema y datos del navegador. Las características continúan solapándose y la plataforma ve un solo dispositivo que cambia de identidad repetidamente.
Una opción controlable es dar a cada cuenta su propio entorno: una cuenta por entorno independiente, con huellas, Cookies y almacenamiento local separados. La clave es mantener ese entorno fijo para la cuenta, en lugar de generar uno aleatorio cada vez que se inicia. Las combinaciones aleatorias suelen ser incoherentes entre sí: zona horaria, idioma, resolución y UA pueden entrar en conflicto, lo que resulta más anómalo que una configuración estable.
En definitiva, la estabilidad proviene de la coherencia, no de la aleatoriedad.
Salida de red
La salida debe estar vinculada a la cuenta: un entorno, una salida, y una región de salida coherente con el perfil de la cuenta, la zona horaria y el idioma. Si varias cuentas tienen entornos separados pero comparten la misma salida, gran parte del aislamiento anterior pierde su efecto.
La salida también debe ser relativamente estable. Cambiar de región con frecuencia hace difícil explicar la señal de ubicación de la cuenta. Al elegir una salida, las direcciones residenciales suelen parecerse más al acceso de un usuario normal que las direcciones de centros de datos. También conviene evitar direcciones que ya hayan sido utilizadas de forma masiva, porque pueden estar sometidas a una vigilancia más estrecha.
Cookies y sesiones
El estado de sesión constituye por sí mismo un registro de identidad. Si varias cuentas comparten las mismas Cookies o el mismo almacenamiento local, se crea un vínculo directo entre ellas, por muy limpia que sea la separación del resto del entorno.
Tampoco conviene usar una sesión en un entorno nuevo a gran intensidad desde el primer momento. Es mejor acumular primero un periodo de navegación normal y aumentar gradualmente la carga de trabajo. Este principio también se aplica fuera de la recopilación: disponer o no de un historial de uso influye directamente en la cantidad de actividad que una cuenta puede sostener.
Ritmo de solicitudes
La densidad de solicitudes es una señal de comportamiento. Los scripts suelen presentar una regularidad típica: intervalos fijos entre accesos, un orden fijo de páginas y ninguna actividad ajena a la recopilación. Añadir valores aleatorios no resuelve esa regularidad, porque el problema principal está en el volumen global.
La dirección controlable consiste en mantener la carga dentro de un rango razonable: escalonar los horarios de ejecución de distintas cuentas, evitar que todas funcionen al máximo al mismo tiempo, dejar intervalos sensatos entre páginas y separar tareas de recopilación de alta y baja prioridad. El límite es claro: la recopilación no debe ejercer presión sobre el servicio objetivo. Cualquier velocidad ganada a costa de afectar al funcionamiento del servicio deja de ser una opción válida.
Por qué un entorno fijo por cuenta es más estable que cambiar al azar
La motivación del cambio aleatorio es adoptar una apariencia distinta cada vez, pero las comprobaciones de asociación observan si las señales son estables entre distintas dimensiones y si se contradicen. Si una cuenta sale hoy desde un lugar y mañana desde otro, con una combinación distinta de características en cada ocasión, esa inconsistencia ya es una señal anómala.
Un entorno fijo sigue la lógica contraria. Desde su registro, la cuenta mantiene una identidad constante: entorno fijo, salida fija, zona horaria e idioma coherentes, e historial de sesión que se acumula poco a poco. Cuanto más dura esa consistencia, más fácil resulta que la actividad se parezca a la de un usuario normal. Ese es el valor de la capa de entorno: estabilidad a largo plazo, no variación vistosa.
Esto también explica por qué el script de recopilación no debería gestionar por sí mismo las instancias del navegador. Los entornos deben poder programarse de forma independiente para asignar uno exclusivo a cada cuenta; su estado debe poder consultarse para detectar entornos anómalos y cuentas que ya no sean válidas; deben poder liberarse para que una operación prolongada no acumule instancias zombi; y los reintentos de una tarea de recopilación a menudo necesitan cambiar de entorno, algo que solo es viable si estos se pueden programar de manera independiente. En este tipo de arquitectura, PurpleMark actúa como la capa de recursos de entorno. El script se ocupa de la lógica de recopilación y deja la identidad y los recursos a la capa de entorno.
Límites de cumplimiento
Los siguientes puntos son más importantes que cualquier optimización anterior.
Respeta los términos de servicio y las reglas de robots del sitio objetivo. Muchas plataformas de comercio electrónico restringen expresamente el acceso automatizado en sus condiciones, por lo que debes confirmar antes de empezar que el uso previsto está permitido. Recopila únicamente información pública sobre productos, precios e inventario y no recopiles información personal. No eludas medidas de protección técnica. Si encuentras defensas como CAPTCHA o interfaces cifradas, ajusta la estrategia de recopilación o solicita autorización en lugar de intentar vulnerarlas. Controla la frecuencia de las solicitudes independientemente de cuántas cuentas tengas y no interfieras con el funcionamiento normal del servicio objetivo.
El punto de partida de esta discusión es cómo mantener independientes varias cuentas legítimas sin que interfieran entre sí, no cómo eludir las reglas de una plataforma. Lo primero es higiene operativa; lo segundo es otra cuestión.
