Personalización de la búsqueda en comercio electrónico: integración del historial de compras y cohortes de usuarios

En las partes 1 a 5 de esta serie se describe un plano de control gobernado que clasifica la intención, impone restricciones, resuelve conflictos de políticas y enruta a la estrategia de recuperación apropiada, todo antes de que se consulte el catálogo de productos. Todos los mecanismos descritos hasta ahora tratan a todos los compradores de la misma manera. Una búsqueda de “chocolate” produce el mismo conjunto de resultados, independientemente de si el comprador es vegano, un padre que compra para el cumpleaños de su hijo o un consumidor que observa las leyes halal.

En esta publicación se presentan dos mecanismos de personalización que amplían el plano de control gestionado sin modificar su arquitectura. Ambos mecanismos se apilan multiplicativamente con la capa de gobernanza de las partes 1 a 5: las políticas aún se activan, las restricciones aún se aplican, los conflictos aún se resuelven y las señales de personalización se componen en la misma consulta gobernada, lo que asegura que los resultados que devuelve Elasticsearch ya están personalizados.

El primer mecanismo impulsa los productos que el comprador individual ha adquirido anteriormente. El segundo activa políticas específicas de cohorte basadas en el perfil del comprador. En conjunto, demuestran que la personalización no es un sistema separado que se combina con la búsqueda ni se aplica como procesamiento posterior a la recuperación; es una extensión natural del plano de control orientado a políticas.

Para profundizar en las matemáticas de las técnicas de personalización utilizadas en esta publicación, consulta Personalización de la búsqueda en Elasticsearch sin postprocesamiento de ML y Clasificación basada en cohortes en Elasticsearch.

Para ver una demostración en vivo de cómo se puede usar el historial de compras para mejorar los resultados de búsqueda de los clientes que regresan, mira el video: Personalización explicable: cómo impulsar la búsqueda con historial de compras.

Impulso del historial de compras individuales

La forma más simple de personalización es también una de las más efectivas: si un comprador ha adquirido un producto antes, promuévalo cuando haga una búsqueda de algo relacionado. Un comprador que adquiere habitualmente una marca concreta de galletas con pepitas de chocolate debería ver esas galletas mejor posicionadas en los resultados de búsqueda cuando busque “galletas”, no porque un modelo predijo una preferencia, sino porque existe evidencia conductual directa.

Cómo funciona

Cuando una solicitud de búsqueda incluye un identificador de usuario, como sería el caso de un usuario que tiene una sesión abierta, el plano de control ejecuta dos consultas de Elasticsearch en paralelo utilizando un thread pool:

1. La consulta del percolador contra el índice de políticas (la misma búsqueda de gobernanza descrita en las partes 3 y 4).
2. Una búsqueda de historial de compras contra un índice de user_purchases, filtrada al usuario específico por term(user_id) y luego comparando el texto de búsqueda actual con los títulos de producto de ese usuario.

Estos procesos se ejecutan en paralelo (ninguno espera al otro), así que la búsqueda de personalización no agrega una latencia significativa al pipeline de gobernanza.

La búsqueda del historial de compras utiliza el análisis de texto de Elasticsearch (derivación, tokenización) al comparar la cadena de búsqueda actual con los títulos de los productos almacenados. Esto significa que una búsqueda de “cookies” coincidirá con una compra anterior de “galletas brownie” a través del análisis de texto estándar, sin requerir una coincidencia exacta de cadenas.

Cálculo de pesos de aumento

No todas las compras anteriores merecen el mismo impulso. La ponderación considera dos factores intuitivos: la frecuencia con la que el comprador adquirió el producto y qué tan reciente fue la compra. Un producto comprado 15 veces la semana pasada es una señal mucho más fuerte que un producto comprado una vez hace seis meses. La ponderación utiliza una escala logarítmica basada en la frecuencia (para que un único artículo comprado en grandes cantidades no eclipse al resto) y un decaimiento exponencial basado en la antigüedad (para que las compras más antiguas pierdan relevancia de forma natural con el tiempo).

Para conocer los detalles matemáticos de la fórmula de aumento, consulta Cómo personalizar la búsqueda en Elasticsearch sin posprocesamiento de ML.

Cómo se convierte en una consulta

Los impulsos del historial de compras se integran en la consulta como la capa de puntuación más externa, envolviendo los filtros de política de gobernanza y los impulsos de las partes 3 y 4 y cualesquier impulso de señales comerciales, como margen y popularidad (que exploraremos en la parte 7). Esto significa que un producto que se elimina por una política de gobernanza no reaparecerá debido a un impulso en el historial de compras. La gobernanza controla el conjunto de resultados; la personalización ajusta el orden dentro de él. Los productos sin historial de compras no se penalizan. Se mantiene su clasificación gobernada, aunque los productos con un historial de compras relevante aparecerán por encima de ellos, en igualdad de condiciones.

¿Por qué consultar Elasticsearch en cada búsqueda?

El historial de compras se consulta desde Elasticsearch en cada búsqueda, en lugar de almacenarse en caché en la capa de la aplicación. Esta es una decisión de diseño deliberada. Como la consulta compara la cadena de búsqueda actual con los títulos de productos mediante el pipeline de análisis de texto de Elasticsearch, el sistema se beneficia de la misma reducción a la raíz, tokenización y manejo del lenguaje que usa la propia búsqueda de productos. Una consulta en memoria caché requeriría reimplementar ese análisis o aceptar una coincidencia menos precisa.

Para ver por qué este orden es importante, considere a un comprador que previamente adquirió jugo de naranja y ahora busca “naranjas”. La consulta de historial de compras compara “jugo de naranja” con el término de búsqueda “naranjas” mediante análisis de texto y calcula un impulso para ese producto. Pero la capa de gobernanza ya ha restringido las “naranjas” a la categoría de productos, filtrando completamente el jugo de naranja. El impulso del historial de compras para el jugo de naranja está presente en la consulta, pero no tiene efecto porque no hay un documento coincidente en el conjunto de resultados gobernado sobre el que pueda actuar. El comprador ve naranjas frescas, ordenadas por relevancia y personalización. La barrera de seguridad de gobernanza se mantiene.

El costo de rendimiento es mínimo: el índice de historial de compra es pequeño (el historial de compra de un usuario suele ser de decenas o cientos de documentos, no de millones), y la consulta se ejecuta en paralelo con la búsqueda del percolador, por lo que no alarga la ruta crítica.

Ejemplo de búsqueda para “agua de manantial” sin historial de usuario

Si un usuario que no ha iniciado sesión o un usuario que nunca ha comprado “agua de manantial” busca, es posible que vea resultados similares a los siguientes:

Ejemplo de historial de compra del usuario

Por otro lado, una usuaria llamada Carol tiene un historial de compras que contiene los siguientes productos:

Ejemplo de búsqueda de “agua de manantial” con el historial de compras anterior

Si Carol busca “agua de manantial”, verá resultados personalizados que reflejan lo que ha comprado en el pasado. Al observar el historial de compras anterior, ella compró “agua de manantial carbonatada” (la botella verde) unas 40 veces, y más recientemente hace dos días. Si busca “agua de manantial”, ese producto aparecerá en los primeros resultados, ya que sabemos que le gusta. Observa que en los resultados no personalizados, el agua de manantial Rubicon fue el primer resultado en aparecer.

Activación de políticas con reconocimiento de cohortes

El historial de compras individual funciona bien para los clientes habituales con un comportamiento ya establecido. Pero muchos compradores son nuevos, anónimos o navegan fuera de sus hábitos habituales. Para estos compradores, la membresía de cohorte proporciona un tipo diferente de personalización, una basada en quién es el comprador, no en lo que han hecho.

Un comprador vegano que busque “chocolate” debería ver el chocolate vegano clasificado más alto. Un comprador que sigue las normas halal y busca “refrigerios” debería ver opciones con certificación halal en un lugar destacado. Un comprador consciente de la salud que busca “yogur” debería ver opciones probióticas resaltadas.

Cohortes como políticas, no como etiquetas de productos

Los productos ya llevan sus atributos normales, incluidos campos como dietary_restrictions: ["vegan"] o dietary_restrictions: ["halal"]. La pregunta es dónde reside la lógica que conecta la cohorte de un comprador con esos atributos de producto.

El enfoque ingenuo sería codificar ese mapping en la capa de aplicación o en la plantilla de búsqueda: si el usuario es vegano, agrega un impulso a dietary_restrictions: "vegan". Pero este es el mismo código espagueti de la parte 1, y crea la misma fricción operativa: agregar una nueva cohorte o cambiar lo que significa una cohorte requiere un cambio de código.

En cambio, el plano de control gestionado mantiene la lógica de cohortes en el motor de políticas. Una política de cohorte combina dos cosas: la membresía de cohorte de un comprador (por ejemplo, “vegana”) y un atributo de producto (por ejemplo, dietary_restrictions: “vegan”). La política define la conexión: cuando un comprador en la cohorte vegana realiza una búsqueda, impulsa los productos donde dietary_restrictions incluye “vegano”.

Como la lógica de cohortes reside en el motor de políticas y no en el código de aplicación, esto significa lo siguiente:

• Para añadir una nueva cohorte, basta con crear una nueva política; no es necesario volver a indexar el producto.
• Las políticas de cohorte utilizan el motor de reglas completo: pueden agregar filtros, aplicar impulsos suaves, expandir sinónimos, cambiar la estrategia de recuperación o realizar cualquier otra acción que una política pueda tomar.
• El comportamiento de la cohorte se gestiona a través de la misma interfaz de administración que todas las demás políticas: un comerciante puede crear, probar y promover políticas de cohorte a través del flujo de trabajo Autor → Prueba → Promoción descrito en la parte 2.

Ejemplo de política de cohorte vegana

Un merchandiser crea una política de cohorte con las siguientes características:

• Cohortes: ["vegan"].
• Criterio de coincidencia: coincide con cualquier búsqueda (o una categoría específica de producto).

Acción: refuerzo leve en dietary_restrictions: "vegan" con una ponderación de refuerzo de 2.

Cómo funciona la activación de cohortes

Cada documento de política tiene un campo cohorts. Las políticas universales que se aplican a todos los compradores independientemente de la cohorte pueden dejar este campo en blanco, e internamente se les asignará un valor de "_all" por el plano de control. Las políticas específicas de cohorte almacenan los nombres de sus cohortes objetivo, como ["vegan", "kosher", “sweet_tooth”].

Cuando una solicitud de búsqueda incluye un perfil de usuario, el plano de control construye un filtro terms simple para la consulta del percolador:

Este filtro único incluye todas las políticas universales, además de las políticas específicas de la cohorte del usuario. El _all centinela hace que este sea un filtro de inclusión limpio: no se necesitan búsquedasmust_not o exists para manejar el caso en el que una política no tiene restricción de cohorte.

A continuación, el percolador evalúa las coincidencias de políticas como de costumbre. La única diferencia es que el conjunto de políticas candidatas se redujo a aquellas relevantes para las cohortes de este comprador. Todo el flujo descendente (transformaciones en cascada, resolución de conflictos por campo, seguimiento de frases consumidas) funciona de manera idéntica al flujo no personalizado descrito en las partes 3 y 4.

Resultados de usuarios no veganos (estándar) al buscar “chocolate”

Cuando un usuario no vegano realiza una búsqueda de chocolate, no se aplica ningún aumento de cohorte vegano a sus resultados. A menudo veía chocolates no veganos entre los resultados más populares, como por ejemplo:

Resultados de la política de cohorte vegana al buscar “chocolate”

Cuando un comprador de cohorte vegana realiza una búsqueda de “chocolate”, esta política se incluye en el conjunto de candidatos del percolador. Coincide, y el plano de control aplica un impulso suave a los chocolates certificados como veganos. El aumento es multiplicativo: los chocolates veganos tienen un rango más alto, pero los chocolates no veganos no están completamente excluidos porque el filtro anterior se define como un impulso suave, que describimos en detalle en la parte 3 de esta serie.

Sin embargo, si el comprador busca explícitamente “chocolate con leche Hershey”, la preferencia vegana sigue siendo aplicable, pero puede verse superada por la mayor relevancia textual de los productos de chocolate con leche Hershey.

Un comprador fuera de la cohorte vegana que busca la misma consulta nunca ve la política de la “cohorte vegana”; no está en su conjunto de candidatos. La capa de gobernanza es idéntica; solo el conjunto de políticas activas difiere.

Cohortes con historial de compra

Un comprador vegano con un historial de compra extenso obtiene la activación de políticas específicas para la cohorte vegana, así como impulsos en el historial de compra. Para compradores nuevos o anónimos, la membresía implícita en la cohorte por sí sola proporciona una personalización significativa sin requerir datos de comportamiento (por ejemplo, quizás un usuario anónimo solo buscó productos veganos, por lo que lo clasificamos como afiliado a la cohorte vegana). Un comprador que se autoidentifica como seguidor de las normas de halal durante la creación de la cuenta recibe inmediatamente resultados adaptados a halal en su primera búsqueda.

Cómo se componen las capas de personalización

El orden de anidación de function_score capas importa. De lo más interno a lo más externo:

1. Búsqueda base: la palabra clave o coincidencia semántica con consultas nombradas (fulltext_match, title_phrase_match).
2. Capa de política de gobernanza: filtros duros como cláusulas bool.filter, impulsos suaves como funciones function_score (Partes 3 y 4).
3. Impulsos de señales de negocio: aumento de margen y popularidad (que exploraremos en la parte 7).
4. Impulsos del historial de compra: La capa function_score más externa.

Este orden garantiza que la gobernanza controle el conjunto de resultados (lo que aparece), que las señales de negocio ajusten la clasificación dentro de ese conjunto (lo que aparece primero desde la perspectiva del minorista) y que el historial de compras ajuste aún más la clasificación según el comportamiento individual (lo que aparece primero desde la perspectiva del comprador). Cada capa envuelve a la anterior de manera multiplicativa, por lo que los efectos se acumulan en lugar de entrar en conflicto.

Qué significa esto a nivel operativo

La personalización a través del plano de control gobernado preserva todas las propiedades operativas descritas en las Partes 1 y 2:

• Cambios sin necesidad de despliegue. Las políticas de cohorte se crean, prueban y promueven a través de la IU de administración. Agregar una nueva cohorte dietética o ajustar un peso de refuerzo no requiere cambios en el código ni participación de ingeniería.
• Auditabilidad. Cada política de cohorte es un documento independiente y versionado. Cuando un comercializador pregunta: “¿Por qué los productos veganos aparecen mejor posicionados para este usuario?”, la respuesta es una política específica con una prioridad determinada, visible en el panel de depuración junto con todas las demás políticas que se activaron para esa consulta.
• Resolución de conflictos. Las políticas de cohorte participan en la misma resolución de conflictos por campo descrita en la Parte 3. Si el aumento de categoría de una política de cohorte entra en conflicto con la anulación de categoría de una política de campaña, el conflicto se resuelve de forma determinista mediante el mismo marco de trabajo de prioridades y estrategia, sin necesidad de una gestión especial.
• Mensurabilidad. Debido a que las políticas de cohorte son discretas y se pueden activar individualmente, su impacto en las tasas de conversión, clics y agregados al carrito puede medirse de forma independiente, al igual que cualquier otra política en el sistema.

Lo que se viene

En la próxima publicación se explora otra dimensión del plano de control gestionado: cómo el margen y el impulso de la popularidad pueden ajustarse por consulta a través de políticas, lo que convierte la optimización económica en una decisión de gobernanza en lugar de una configuración estática.

Consulta la parte 7: optimización económica gobernada por consultas: margen por búsqueda y aumento de popularidad

Pon en práctica la búsqueda gobernada de comercio electrónico

Los patrones de personalización descritos en esta publicación (aumento del historial de compras individuales y activación de políticas consciente de la cohorte) fueron diseñados y desarrollados por Elastic Services Engineering como parte de nuestro acelerador de búsqueda de comercio electrónico repetible. Ambos mecanismos se integran con la arquitectura del plano de control gobernado descrita a lo largo de esta serie. Ponte en contacto con Elastic Professional Services.

Únete a la discusión

¿Tienes preguntas sobre la gestión de búsquedas, las estrategias de recuperación o la arquitectura de búsqueda en el comercio electrónico? Únete a la conversación general de la comunidad de Elastic.