¿Sueñan los bots con vacaciones digitales?

“Un robot debe obedecer las órdenes que
le son dadas por un ser humano, excepto
cuando estas órdenes están en oposición
con la Primera Ley.”

Isaac Asimov.

En Despegar buscamos que los datos guíen nuestras decisiones, para eso trabajamos mucho en tener métricas precisas sobre la navegación de los usuarios, la conversión de los diferentes flujos, la carga de un cluster, incluso la performance en los tiempos de carga del lado del usuario. Cuando queremos decidir sobre un cambio, apuntamos a que los datos decidan, por eso utilizamos A/B testing por ejemplo para decidir entre múltiples opciones.

Imaginemos que tenemos la sospecha de que a la gente no le gusta llenar muchos campos para tener resultados de búsqueda, tal vez vimos en las métricas que luego de llenar 2 de ellos un alto porcentaje abandona el formulario y el sitio.

Por lo tanto vamos a probar una variante de este mismo formulario con solo destino obligatorio, sin ningún otro campo a la vista.

Prendemos nuestro A/B testing, y luego de un tiempo prudencial, detectamos que la conversión de búsquedas en el nuevo formulario es 30% mayor que con la versión original. ¿Podemos decir entonces que hay que utilizar el nuevo formulario? ¿Elegiremos bien que rama del A/B elegir? ¿Qué sucede si al ser un formulario más sencillo fue fácil crear un bot/crawler que simula el envío del formulario para conocer todas las opciones de vuelo que tenemos en el catálogo?

¿Qué es un bot/crawler?

Se utiliza la palabra bot para referirse a un robot informático, podríamos decir que existen dos bandos: buenos y malos.

Hay bots (también llamados spiders) que recopilan información de internet y permiten la existencia de buscadores (Google, DuckDuckGo, etc), estos podrían encontrarse dentro del primer grupo. Pero también existen aquellos que se encargan de generar correo spam.

Los bots pueden realizar tareas automatizadas como si se tratase de humanos. Normalmente realizando dichas tareas en forma más rápida y eficiente.

Los crawlers buscan navegar el sitio objetivo para poder obtener información a gran escala, puede ser el inventario de libros de Amazon para poner una página web que los revenda, o tal vez automatizar una búsqueda para detectar si el precio de un producto bajo a menos de X monto.

Al hacer esto afectan toda métrica del sitio, si constantemente chequean el producto “Hotel De Lujo” podrían hacer pensar que es un hotel muy buscado, o que la conversión de ese Hotel es mala (la tasa de búsqueda sobre compras se vería afectada).

Si el proveedor nos cobra por cotizar o chequear disponibilidad, estaríamos incurriendo en un costo innecesario de procesamiento.

Si la carga es muy alta, podríamos tender a tener clusters sobredimensionados para atender esa carga, generando un sobrecosto en infraestructura innecesario.

Asimov — Antes

Existía una solución que buscaba limitar el impacto de crawlers en Despegar. El enfoque era sencillo, ante una carga alta de tráfico por un dispositivo en una parte del sitio, se lo envía a cumplir un desafío que demuestra su humanidad (Captcha). Si el usuario no lo cumple se lo ingresa en una lista negra (blacklist).

Esto implicaba ciertas complejidades inherentes al enfoque de lista negra y repetición de visitas:

• ¿Cuánto tiempo dejamos blacklisteado un dispositivo?
• Dejamos sin navegar al usuario cuando tal vez no queríamos hacerlo. No es lo mismo comprar 30 reservas de una noche de hotel que 1 reserva de 30 noches.
• Los atributos por los cuales identificamos al usuario para blacklistearlo pueden variar con el tiempo permitiéndole esquivar la seguridad.
• Si utilizamos pocos atributos para identificar al usuario, estaremos siendo poco abarcativos y podríamos cometer errores. Por ejemplo la ip de una universidad.
• El tráfico “alto” no es el mismo para la home que para sitios de postventa seguramente, puede ser necesario tener límites diferentes por servicio.
• ¿Qué sucede si los datos que utilizamos en la blacklist cambian?
• Si tenemos 2 agentes, uno intentando crawlear y uno blacklisteando, es esperable que cuando uno supere al otro, este mute para superar el nivel de defensa del primero (por ejemplo reglas de tráfico), llevando a una competencia constante y agotadora de mantener.

Por algunas de estas razones, nos planteamos un nuevo enfoque.

Deckard — Ahora

El enfoque de Deckard es analizar el comportamiento de un usuario en cierto período para establecer si se trata de un humano o un bot (que se identifica como tal o lo oculta). A este conjunto de eventos en una ventana de tiempo lo llamamos sesión de un usuario.

Para realizar dicha clasificación utilizamos modelos de machine learning, que buscan clasificar la sesión a partir de variables que en estudios anteriores demostraron ser discriminantes entre navegaciones orgánicas y las de un bot.

¿Y cómo caracterizamos a los usuarios?

El objetivo es comprender cómo fue la sesión de navegación, por lo cual se balancean características propias de la navegación en un explorador (cantidad de páginas visitadas por segundo, tasa de errores) con algunas más relacionadas con el sitio de Despegar (utiliza la app de Despegar, cuanto avanza en el funnel de compra, variedad de productos que busca, idioma, si se saltea páginas del flujo normal, etc).

Una vez que identificamos las características, se realizan investigaciones para validar las variables a utilizar, entrenamos los modelos y se comparan con las versiones actuales. Además se validan contra las clasificaciones que realizan otros equipos para aprender sobre distintos enfoques.

También se trabaja en conjunto con el equipo de BI para ver cómo impacta la clasificación del modelo en las métricas del sitio y continuar el proceso de mejora continua.

¿Cuál es la arquitectura que permite el funcionamiento de Deckard?

Para aclarar el panorama, podemos dividir al proyecto en una parte online y una parte offline.

En la primera nos encontramos con la materia prima que hace que la magia suceda: los logs provenientes del tráfico público del sitio. Luego podemos dividir las distintas partes en:

• Producer: es la aplicación que recibe líneas de logs, se encarga de procesarlas y enviar esa información estructurada a Pulsar.
• Apache Pulsar: Es una plataforma de mensajería distribuida.
• Consumer: aplicación que se encarga de buscar las líneas de logs estructuradas de Pulsar, agruparlas formando sesiones por cada usuario y almacenarlas en Redis.
• Redis: base de datos clave-valor que Consumer utiliza para acumular eventos de las sesiones.
• Classifier: como seguramente se imaginaran, se encarga de clasificar las sesiones como bot/no_bot y guarda esta información en almacenamientos externos (en el data lake de Despegar y en la base relacional del sistema).
• Monitoring: el ojo que todo lo ve. Es una aplicación Web con dashboards en tiempo real que nos permite monitorear métricas de Consumer, Classifier y Redis. La misma utiliza Prometheus y Grafana.

Por otro lado, podemos encontrar el módulo offline:

• Baseline: aplicación Web que implementa la API del proyecto Deckard, es el principal punto de acceso para los clientes que necesitan consultar sobre la clasificación de algún usuario para luego tomar decisiones.
• DeckardDB: base de datos relacional (MariaDB) que guarda información sobre sesiones clasificadas, esto pueden ser resultados, variables, metadata de la sesión.
• Data: aquí se realizan notebooks sobre los análisis de los distintos modelos, hipótesis sobre el comportamiento de los usuarios, es el backstage donde almacenamos las ideas y la historia de cómo evolucionaron los modelos.
• Incoming Signals: clasificaciones propias de otros equipos que almacenamos para luego estudiar y nutrirnos de ese comportamiento, si bien buscamos ser una solución de detección de bots centralizada para todos, a veces los propios equipos tienen más conocimiento de su nicho de negocio y pueden clasificarlos de mejor manera, con este método podemos aprender de esas clasificaciones.

Hoy en día estamos procesando picos de 3 mil líneas de log por minuto.

Tenemos siempre presente el tiempo que nos lleva procesar cada una de estas líneas para no tener un cuello de botella (el tráfico de logs puede superar la capacidad del producer si empezamos a demorar).

Hacia dónde vamos

Para determinado producto comercializado por Despegar, la puesta en producción de Deckard logró disminuir la cantidad de bots no detectados en un 90%.

A pesar de esto, hay una serie de preguntas que nos hacemos a la hora de pensar en cómo evolucionará el proyecto:

• ¿Debemos tener modelos separados por dispositivos? ¿por horarios?
• ¿La navegación en Brasil es igual a la de Colombia? Es probable que donde UX detecte diferencias de comportamiento haya puntos de mejora para Deckard.
• ¿Además de detectar a los bots, deberíamos ser quien ofrezca medidas disuasorias? ¿o debemos dejar la decisión del lado de los equipos?

Deckard nos enseñó que no es trivial detectar cuándo una sesión es inorgánica. Se requiere aprender sobre el comportamiento del usuario a lo largo de todo el sitio, una feature puede ser útil para detectar bots en determinado flujo pero puede no ser así en otro.

Llega un punto en que el modelo propuesto es difícil de superar, en proyectos de Machine Learning hay que saber manejar la frustración, es un proceso muy experimental, por ejemplo cuando se propone alguna feature que se considera importante pero luego en la práctica no termina teniendo el impacto esperado.

Tener una lista negra de ips tal vez sea la idea que a la mayoría se le presente si le preguntaran sobre soluciones al problema de bots, pero este enfoque no resulta eficiente, ya que al ser las ips dinámicas podemos estar bloqueando a usuarios orgánicos o cometiendo errores. Como el caso mencionado de bloquear la ip de una universidad. Por consiguiente podríamos estar perdiendo ventas.

Resulta útil pensar en distintos enfoques para estructurar y procesar la información al manejar grandes volúmenes de datos.

Trabajamos creando bots que detecten bots, sin olvidarnos que somos los humanos los que definimos “quién es un bot”

Si alguno de estos problemas te resultan interesantes o quieres ser parte de nuestros equipos de ingeniería para aportar ideas (y atrapar bots), no dudes en ir a ver nuestras búsquedas abiertas.

Autores: Ignacio Pacheco y Valeria Rocha Bartaburu