La monitorización de reseñas parece un problema de generación de informes y se comporta como un problema de recopilación de datos. Las reseñas son públicas, las páginas son fáciles de leer, y entonces el primer barrido serio se topa con las dos cosas que hacen que este trabajo no sea trivial: lo que muestra una página de reseñas depende de dónde procede la solicitud, y solicitar las mismas páginas todos los días es el patrón de tráfico que los sistemas anti-bot están afinados para detectar.
Este artículo trata sobre cómo encajan los proxies en todo esto, qué recopilar, y cómo mantener estable una canalización de reseñas una vez que funciona con un calendario.
Qué se rompe en realidad sin proxies
Empecemos por la localización. Las reseñas de Google, las tiendas de aplicaciones, los dominios por país de Trustpilot y los grandes marketplaces varían su resultado según la región del solicitante. La media de estrellas puede diferir, el conjunto de reseñas difiere, las versiones traducidas aparecen en algunas regiones y no en otras, y en los marketplaces el propio listado puede no existir en un país determinado. Un equipo que monitoriza desde la IP de una sola oficina no está viendo una imagen global. Está viendo la imagen de un país y llamándola global.
Luego está el volumen. Una marca que hace seguimiento de unos cientos de productos, o de unos cientos de ubicaciones de tienda, está solicitando miles de páginas al día, todos los días, desde una dirección estable. Eso es una huella. La respuesta normalmente no es un bloqueo total al principio, es degradación: respuestas más lentas, una página intersticial, una lista de reseñas truncada, una página de desafío que devuelve un 200 válido sin datos dentro. Las canalizaciones que no comprueban esto registran silenciosamente ceros y el panel de control muestra una sequía de reseñas que nunca ocurrió.
Los proxies abordan ambos problemas. La segmentación geográfica coloca la solicitud en el mercado cuyas reseñas quieres, y distribuir el tráfico a través de un pool residencial amplio mantiene cualquier dirección individual muy por debajo del ritmo al que un sitio empieza a fijarse.
Qué tipo de proxy encaja con qué objetivo
Las superficies de reseñas de consumo son el caso difícil. Google, Trustpilot, G2, Capterra, la App Store y Play Store, Amazon y los marketplaces regionales están todos protegidos por una gestión de bots madura. Estos quieren IPs residenciales, porque esas direcciones pertenecen a conexiones reales de consumidores y llevan el perfil de confianza contra el que el sitio está puntuando. Esto constituye la mayor parte de la mayoría de los programas de reseñas.
Los proxies ISP se ganan su lugar cuando el flujo tiene estado. Si las reseñas solo aparecen después de elegir una tienda, establecer una ubicación de entrega, o iniciar sesión en una cuenta de vendedor propia, una dirección estable a lo largo de esos pasos vale más que la rotación. Las direcciones ISP son estáticas y encaminadas por consumidores, que es la combinación que necesita ese escenario.
Los proxies de centro de datos siguen teniendo sentido en la cola larga: sitios de reseñas de nicho industrial, foros, feeds públicos, cualquier cosa con defensas ligeras. El coste por solicitud es menor y la penalización de confianza no muerde. Enviarlos contra las reseñas de Google es donde los equipos malgastan dinero, porque una solicitud barata que devuelve una página de desafío no es barata.
La mayoría de las configuraciones maduras encaminan según el objetivo en lugar de elegir un único tipo. Las plataformas de consumo difíciles van con residenciales, los flujos con estado van con sesiones fijas, el resto fácil va a donde sea más barato. Nuestra nota sobre cómo evitar bloqueos al hacer scraping cubre el lado a nivel de solicitud del mismo problema.
Rotación, sesiones y ritmo
La mayor parte de la recopilación de reseñas es una lectura de página directa: solicitar una URL, analizar las reseñas, seguir adelante. Rotar en cada solicitud es la opción por defecto correcta, y es lo que hace un endpoint residencial rotativo sin ningún trabajo de tu parte.
Las sesiones fijas importan para las excepciones. Paginar una lista de reseñas a menudo depende de un cursor que el sitio emite a una sesión, y las reseñas restringidas por ubicación dependen de una elección que el sitio almacenó contra una de ellas. Cambiar de IP a mitad de flujo reinicia ese estado y o bien vuelves a obtener la página uno o un resultado vacío. Mantén la sesión durante la duración del flujo, y luego suéltala.
El ritmo es la parte en la que los equipos invierten poco. El número de reseñas cambia lentamente. No hay ningún valor en bombardear una página de producto cada hora cuando los datos subyacentes se mueven semanalmente, y el coste de hacerlo es una tasa de bloqueo más alta en las páginas que realmente te importan. Ajusta la frecuencia de rastreo a la velocidad con la que se acumulan las reseñas en ese objetivo: diaria para listados de marketplace de alto volumen y tiendas de aplicaciones, semanal para la mayoría de los directorios de software B2B, y basada en eventos alrededor de lanzamientos y campañas cuando se espera un pico.
Elegir qué recopilar
El instinto es recopilarlo todo. Una canalización más útil recopila los campos que respaldan decisiones y descarta el resto.
La valoración y el número de reseñas por producto, por ubicación y por mercado te dan la línea de tendencia. El texto de la reseña, la fecha y el idioma te dan la sustancia, y el idioma es lo que permite dirigir una queja a un equipo que pueda leerla. Las marcas de compra verificada y el historial del autor de la reseña separan la señal real de las campañas. La identidad del vendedor o del listado importa en los marketplaces, donde el mismo producto vendido por un falsificador lleva reseñas que quieres conocer pero que no quieres mezclar en tu propia media.
Hay dos cosas que merece la pena resistir. Almacenar más datos personales de los que necesita el análisis convierte una canalización de reseñas en un problema de protección de datos sin ningún beneficio, y los nombres de los autores de las reseñas raramente se ganan su lugar. Y el texto de las reseñas está escrito por otras personas, así que agregarlo para el análisis es una cosa mientras que republicarlo como contenido del sitio es otra distinta.
Para los equipos cuyo interés en las reseñas es reputacional más que analítico, la protección de marca y la escucha social cubren las superficies adyacentes donde la misma queja normalmente aparece primero.
Construir la canalización
La mecánica es ordinaria. Un programador dirige una lista de trabajo de URLs por mercado, cada solicitud sale a través de un endpoint de proxy con el país establecido para esa fila, la respuesta va a un analizador, y las reseñas analizadas se almacenan indexadas por plataforma, producto y mercado de modo que la misma reseña nunca se cuente dos veces.
Las partes que deciden si sobrevive al contacto con producción son menos obvias.
Valida las respuestas en lugar de confiar en los códigos de estado, porque una página de desafío devuelve 200 y se analiza como cero reseñas. Una ejecución que de repente no encuentra ninguna reseña en una página que tenía cuatrocientas ayer es un fallo de recopilación, no un evento de negocio, y la canalización debería indicarlo así.
Obtén datos de forma económica. Las páginas de reseñas llevan imágenes, fuentes y scripts de análisis que no aportan nada al análisis. Bloquearlos reduce sustancialmente el ancho de banda, y en un plan con precio por ancho de banda eso es la diferencia entre unos pocos GB al mes y una factura que merece la pena discutir.
Renderiza solo cuando sea necesario. Algunas secciones de reseñas se renderizan en el servidor y una solicitud HTTP simple es suficiente. Otras necesitan un navegador headless, que cuesta un orden de magnitud más tanto en ancho de banda como en tiempo. Comprueba caso por objetivo en lugar de predeterminar todo a un navegador.
Conserva la respuesta en bruto durante una ventana corta de tiempo. Cuando un analizador se rompe porque una plataforma cambió su marcado, y lo hará, tener el HTML de ayer convierte la solución en un trabajo de diez minutos en lugar de un nuevo rastreo.
Si tu equipo no tiene ningún interés en mantener nada de esto, una API de scraping devuelve resultados estructurados y absorbe la lógica de rotación, renderizado y reintento a un precio más alto por solicitud. La compensación es dinero frente a tiempo de ingeniería, y para un programa de reseñas que ejecuta unos pocos miles de páginas al día suele ser un intercambio justo solo mientras el programa sea pequeño.
Cuánto cuesta esto
La monitorización de reseñas es una de las cargas de trabajo de proxy más económicas, porque las páginas son pequeñas una vez que dejas de descargar recursos y la frecuencia de rastreo es baja.
Con precios residenciales que empiezan en $1.00/GB, un barrido diario a través de unos pocos miles de páginas de producto y varios mercados suele ser una cifra de ancho de banda mensual de un solo dígito. Las variables que la mueven son la navegación headless, la carga de imágenes y los rastreos con frecuencia excesiva, en ese orden. Las tres son decisiones de ingeniería más que decisiones de precios, que es lo útil de saber antes de culpar a la factura de proxy.
El ajuste de Shifter aquí es el habitual: más de 205M de IPs residenciales en más de 195 países con segmentación a nivel de ciudad y ASN, sesiones rotativas y fijas en la misma cuenta, y conexiones concurrentes ilimitadas para que un barrido de mercado pueda ejecutarse en paralelo en lugar de en secuencia. Los datos independientes sobre el comportamiento de la red están en la página de benchmarks en lugar de afirmarse aquí.
La parte que no es infraestructura
La recopilación es la mitad fácil. Las reseñas solo merece la pena monitorizarlas si algo ocurre como resultado, y los programas que dan sus frutos dirigen una reseña negativa al equipo que es propietario del producto, no a un panel de control que nadie abre.
Eso significa decidir de antemano qué desencadena una acción: una valoración que cae por debajo de un umbral en un mercado específico, un pico de reseñas que mencionan una palabra, un listado que aparece bajo un vendedor que no reconoces, la valoración de un competidor superando a la tuya en una categoría que defiendes. La capa de proxy existe para asegurar que esas señales estén completas y actualizadas en cada mercado en el que vendes. Lo que hagas con ellas es el trabajo real.
Sigue leyendo: cómo hacer scraping de datos de negocios locales con proxies, que cubre la versión a nivel de ubicación del mismo problema de recopilación.