La elección del motor de búsqueda para los puntos de contacto de un e-commerce juega un papel fundamental en la visibilidad de los productos y el aumento de la tasa de adición al carrito de compra desde la lista de productos o la página de detalles de cada producto – incrementando los ingresos del canal.
La búsqueda “Search” ha ido evolucionando desde los parámetros estándar del analizador de consultas hasta los parámetros basados en DSL o json para evolucionar junto con los sistemas conectados. No sólo eso, el avance hacia los algoritmos de búsqueda para ser adaptables y tener la Inteligencia Artificial interconectada ayudó a construir una solución de búsqueda poderosa que permite tener mejor clasificación, relevancia y ordenamiento.
Las empresas también han comenzado a moverse hacia “construir su propios motores de búsqueda” o utilizar opciones de búsqueda SaaS como Algolia, Bloomreach, etc. al darse cuenta de que la solución basada en Lucene como Solr o Elasticsearch sólo da un 20% de preparación al producto que se necesita para estar listo para el cliente en modo “out-of-the-box”.
¿Pero es esto suficiente? ¿Podemos comparar los motores de búsqueda construidos que se usan en los puntos de contacto de un e-commerce con el de Google? Al final lo que se destaca es la velocidad de búsqueda.
La búsqueda en Google es más rápida que un parpadeo, en promedio un humano parpadea cada 100 ms. En promedio, Google regresa 2,000,000,000 de resultados de búsqueda en 400 ms y sugerencias/autocompletar en 50 ms. Lo que importa es que este tiempo de respuesta es de la interfaz final y no sólo del motor de búsqueda subyacente. Según el gurú de la búsqueda de Google, cada 400 ms de retraso lleva a una caída del 0.44 % en los volúmenes de búsqueda en el sitio (https://www.thinkwithgoogle.com/marketing-resources/the-google-gospel-of-speed-urs-hoelzle/)
Es importante entender este problema y centrarse en resolver los inconvenientes de la latencia: una búsqueda más rápida atrae a más clientes y les lleva a comprar más.
Opciones de infraestructura
La latencia entre la interfaz y el motor de búsqueda se debe principalmente a la elección de la infraestructura. Los índices de búsqueda deben estar lo más cerca posible de la interfaz para minimizar la demora. Las soluciones de búsqueda in situ pueden realmente impactar en la latencia de la búsqueda debido a que se necesitan viajes de ida y vuelta, esta es una de las razones por las que la solución Endeca local ya no es la primera elección de las empresas.
Así como la CDN (Content Delivery Network) ayuda a abastecer el contenido desde cualquier lugar más rápido porque el cliente es atendido desde el punto más cercano, la búsqueda también debe estar disponible para el cliente desde los índices más cercanos posibles. Solr y Elasticsearch han lanzado la técnica de replicación, pero éstas siguen estando pensadas para una configuración activa-pasiva y no se recomienda tener múltiples clusters en diferentes centros de datos y ubicaciones.
La resolución del DNS (Domain Name Server), el balanceo de carga son también algo que hay que revisar ya que cada uno de estos toma una buena cantidad de tiempo agregando lapsos entre ellos.
Procesamiento de la búsqueda
La mayoría de los motores de búsqueda del mercado aplican actualmente reglas de relevancia, ordenamiento y otras reglas después de que los resultados se obtienen de los índices, lo que requiere tiempo.
La personalización cada vez mayor en la búsqueda significa más tiempo de respuesta. El motor de búsqueda necesita ser acondicionado para que los resultados sean pre-indexados con relevancia, y la clasificación es necesaria para evitar el post-procesamiento.
Proceso de indexación
Casi todos los motores de búsqueda en su modo “out-of-the-box” cuando hacen la indexación – que es un proceso pesado – lo hacen en el mismo nodo que también se utiliza para la búsqueda. Esto hace que los procesos de indexación y búsqueda compitan por recursos como el CPU y la memoria lo que a menudo reduce el rendimiento de la búsqueda.
Recolección de basura
Hay varias librerías de motores de búsqueda como Clucene, Xapian, etc. que usan C++ en el núcleo, que es muy rápido ya que se compila en código máquina y no tiene un historial de operaciones de GC (Garbage Collection). Esas pausas para la recolección de basura siempre han sido un problema para los motores de búsqueda basados en Java como Lucene.
Capa envolvente
La mayoría de las veces, las APIs de los motores de búsqueda están envueltas por una capa de negocios para conectar alguna lógica de negocios o interpretar la respuesta según sea necesario para la interfaz que se maneje. Es importante repensar el enfoque ya que cada capa adicional añadirá una sobrecarga a la latencia. ¿Vale la pena este compromiso con la velocidad? Considere la posibilidad de reestructurar la respuesta subyacente del motor de búsqueda para que sea fácilmente interpretada por la interfaz del cliente para evitar cualquier capa intermedia.
En resumen, es importante ayudar a los visitantes a encontrar los productos correctos lo más rápido posible!.
Autor: Prateek Srivastava
Lead Solutions Architect / Engineering Manager
Artículo original: https://www.linkedin.com/pulse/search-beyond-just-prateek-srivastava/