Recomendaciones dinámicas de productos en Magento 2: perfiles en lugar de relaciones rígidas

En muchos proyectos de Magento 2, el tema de las recomendaciones de productos empieza con una idea simple: hay que mostrar al cliente algunos productos adicionales en la ficha de producto, en el carrito o durante el checkout. El problema aparece muy rápido. Los mecanismos estándar related, upsell y cross-sell de Magento son útiles, pero en la práctica suelen resultar demasiado rígidos para las necesidades reales de implementación.

La tienda no quiere mostrar los mismos productos en todos los lugares y en todos los casos. Se necesita un escenario para un producto simple, otro para un configurable, otro para una campaña estacional y otro distinto para un carrito que contiene varios productos diferentes. Desde la perspectiva de las agencias y de los equipos de implementación, esto suele significar una sola cosa: empiezan a aparecer excepciones, condiciones personalizadas y nuevas capas de código cada vez más difíciles de mantener.

Kowal_RelatedProductsProfiles fue diseñado precisamente para resolver este problema de otra manera. En lugar de construir la lógica alrededor de relaciones individuales entre productos enlazadas manualmente, el módulo introduce el concepto de perfil de recomendación. El perfil define dónde debe funcionar, en qué condiciones debe activarse, cómo se deben seleccionar los productos y cómo se deben renderizar. De este modo, las recomendaciones se convierten en una capa configurable y no en otra colección de excepciones puntuales incrustadas en el código del proyecto.

El módulo está disponible aquí: Automatic related products for Magento 2.

Por qué las listas estándar de Magento a menudo no bastan

Las listas nativas related, upsell y cross-sell funcionan bien en tiendas simples o en entornos donde el merchandising se gestiona manualmente por el equipo e-commerce. Sin embargo, en los proyectos reales de implementación aparecen muy pronto escenarios que el modelo estándar no cubre:

• mostrar recomendaciones solo para un grupo concreto de clientes,
• activar una lista concreta solo dentro de un rango de fechas determinado,
• relacionar productos a partir de atributos del catálogo y no de relaciones manuales,
• un comportamiento distinto en la PDP, otro en el carrito y otro en checkout,
• insertar una lista en una posición concreta del layout del tema sin reescribir toda la vista,
• sustituir parcial o totalmente las listas nativas de Magento por una lógica propia del proyecto.

Para las agencias esto suele significar dos problemas. Primero, el mecanismo estándar necesita envolverse con condiciones adicionales. Segundo, cada nueva necesidad de negocio empieza a generar una excepción separada. Llega un momento en el que, en lugar de un mecanismo coherente de recomendaciones, aparece un conjunto de soluciones improvisadas sin relación entre sí.

Los perfiles como capa de lógica de merchandising

La idea más importante del módulo es dejar de pensar en términos de una lista única de productos y sustituir ese modelo por un perfil de recomendación.

El perfil es una entidad de configuración independiente. Define:

• dónde debe funcionar,
• para qué tienda y grupo de clientes está activo,
• qué producto debe actuar como contexto,
• cuándo debe ejecutarse el perfil,
• cómo seleccionar los candidatos,
• cómo acotar el resultado,
• cómo ordenar los productos,
• cómo mostrarlos,
• y si además deben alimentar las listas nativas de Magento.

Desde el punto de vista de la implementación, esto supone un cambio importante de calidad. En lugar de preparar código personalizado distinto para cada placement, se puede construir un conjunto de perfiles que responda a distintos escenarios de negocio. Este modelo es más fácil de mantener, más sencillo de ampliar y mucho más legible para los equipos que trabajarán con el proyecto después del lanzamiento.

Dónde ofrece el módulo una ventaja real en las implementaciones

El lugar más evidente de uso es la ficha de producto. Es ahí donde con más frecuencia queremos mostrar productos de la misma colección, con un estilo similar o pertenecientes a la misma línea de comunicación. Sin embargo, en la práctica la PDP rara vez es el único lugar donde las recomendaciones tienen sentido.

El carrito abre un escenario completamente distinto. Ya no es un momento de inspiración, sino una etapa en la que se puede trabajar para aumentar el valor del carrito. Aquí funcionan bien los perfiles que sugieren accesorios, complementos, añadidos más económicos o productos de otra base de surtido, pero que siguen estando relacionados con lo que el cliente ya ha elegido.

Checkout es otra etapa que exige cautela. No todas las tiendas quieren ampliar allí el merchandising, pero para algunas implementaciones puede ser un buen lugar para una lista corta y simple de productos que apoye el AOV, siempre que la lógica y el renderizado estén muy controlados.

Y ahí no terminan las posibilidades del módulo. Un perfil también puede alimentar los bloques nativos de Magento:

• Related Products,
• Upsell Products,
• Crosssell Products.

Lo importante es que la integración no se limita a sustituir la lista. Para cada uno de estos mecanismos se puede decidir si los resultados del perfil deben añadirse a los productos nativos (append) o reemplazarlos por completo (replace). Para las agencias esto es muy práctico, porque permite implantar la lógica por fases sin tener que reescribir desde el principio toda la experiencia de compra.

Cómo funciona la lógica del módulo

Aunque el formulario del perfil es bastante amplio, el modelo de funcionamiento se puede explicar con claridad. El módulo recorre cada vez varias etapas consecutivas.

Primero se determina el placement, es decir, el lugar en el que se ejecuta el perfil. Una lógica funcionará en la ficha de producto y otra en el carrito. Después se selecciona el producto de contexto. En la PDP suele ser el producto actual, mientras que en carrito y checkout hay que decidir qué producto del quote se convierte en el punto de referencia.

Cuando el módulo ya conoce el contexto, comprueba las condiciones de activación. Este es el primer filtro y responde a una pregunta clave: ¿debe ejecutarse este perfil en la situación actual?

Si las condiciones se cumplen, el módulo pasa a las matching rules. Ahí es donde ocurre el ajuste real. Los atributos del producto de contexto se mapean a los atributos de los productos candidatos para encontrar productos de la misma colección, serie, gráfica, categoría u otra característica relevante para el negocio.

Después del matching, el resultado todavía puede acotarse mediante filtros estáticos de producto objetivo. Es un lugar cómodo para limitar la lista a tipos de producto concretos, visibilidad, estado o incluso bases de producto seleccionadas.

Al final, los productos se ordenan, se recortan al límite configurado y se renderizan en una posición independiente del layout o dentro de los bloques nativos de Magento.

En la práctica, esto significa que el módulo no se basa en una única relación producto-producto, sino en una secuencia de decisiones que pueden controlarse desde la administración.

Crear un nuevo perfil: cómo es trabajar con el formulario

La mayor fuerza del módulo se aprecia realmente cuando se mira el formulario del perfil no como una lista de campos, sino como una herramienta para modelar un escenario de merchandising.

El proceso empieza con la sección general. Name es el nombre administrativo que ayuda al equipo a localizar el perfil en el panel. Code es el identificador técnico. Es precisamente el valor que conviene usar en logs, en la comunicación del proyecto y en la documentación de implementación. Enabled permite desactivar rápidamente un perfil sin borrar su configuración, y Sort Order decide el orden en que se evalúan los perfiles dentro del mismo placement.

La segunda sección es el alcance de funcionamiento. Aquí se seleccionan placements, store views y grupos de clientes. Desde el punto de vista de la implementación, esto es muy importante porque permite mantener un único mecanismo y, al mismo tiempo, diferenciar el comportamiento entre tiendas, idiomas o segmentos de clientes.

El campo Context Strategy es especialmente importante. En la ficha de producto el asunto es simple, porque el módulo trabaja con el producto actual. En el carrito y en checkout, sin embargo, hay que definir qué elemento del quote se convierte en el contexto. En la práctica puede ser el primer producto, el último añadido o el producto con el precio más alto. Este campo aparentemente pequeño tiene un impacto enorme en el resultado final, sobre todo en carritos con varios artículos distintos.

Los campos From Date y To Date permiten limitar un perfil a una ventana de tiempo determinada. Gracias a ello, el mismo módulo puede cubrir campañas estacionales y acciones de venta de corta duración sin necesidad de crear interruptores adicionales.

Activation Conditions, Matching Rules y Target Product Filters

Estas tres secciones son las responsables de la lógica de negocio del módulo.

Activation Conditions deben entenderse como la capa de entrada. Aquí definimos cuándo un perfil debe activarse realmente. Si, por ejemplo, un perfil debe funcionar solo para productos de una base determinada, de una marca concreta o con una visibilidad específica en catálogo, esas condiciones deben colocarse aquí.

Matching Rules son el corazón de todo el mecanismo. Trasladan las características del producto de contexto a los productos objetivo. En la práctica eso significa que se le puede decir al módulo: encuentra productos que tengan la misma gráfica, la misma colección, la misma categoría o cualquier otro atributo que tenga sentido desde el punto de vista del negocio.

Aquí hay dos campos especialmente importantes: Required y Empty Value Policy.

Required decide si una regla es obligatoria. Si está activado, la falta de coincidencia descarta al candidato. Si está desactivado, la regla actúa más bien como una capa adicional de acotación, pero un mismatch no bloquea todo el resultado. En la práctica esto es muy importante en proyectos donde el contexto en la PDP y en el carrito puede verse distinto, por ejemplo para un configurable parent en la ficha de producto y un simple child en el quote.

Empty Value Policy indica al módulo qué hacer cuando el producto de contexto no tiene valor en el atributo de origen. La regla puede omitirse, considerarse fallida o usar un valor por defecto. Este campo a menudo determina si un perfil será estable en un catálogo complejo con distintos tipos de producto.

Target Product Filters son la última capa de acotación. Ya no trabajan sobre la relación contexto-candidato, sino directamente sobre los productos objetivo. Es un buen lugar para imponer estado, visibilidad, tipo de producto o limitar el resultado a familias concretas de surtido.

Ordenación y forma de presentación

Desde el punto de vista de la implementación, importa no solo qué productos se encuentran, sino también en qué orden y en qué forma se presentan.

El módulo permite definir un atributo de ordenación principal y otro secundario. Gracias a ello se pueden construir listas más predecibles en lugar de depender solo del comportamiento por defecto de la colección.

En la parte de presentación hay disponibles distintos variantes de renderizado, entre ellas grid, slider y compact. Esto permite adaptar la lista al espacio disponible en la página sin crear tipos de perfil separados solo para cambiar el markup o la disposición visual.

También es importante que el perfil pueda controlar de forma independiente elementos como:

• precio,
• precio regular,
• botón de añadir al carrito,
• nombre del producto,
• descripción corta,
• rol de la imagen.

En la práctica, esto significa que el mismo motor de recomendaciones puede utilizarse tanto en secciones más amplias de la PDP como en listas más discretas del carrito o checkout.

Alimentar las listas nativas de Magento

Una de las características más interesantes del módulo es la posibilidad de alimentar los bloques nativos de Magento. Esto es especialmente importante para agencias que no quieren rehacer el frontend existente desde el primer momento o que trabajan en proyectos donde una parte de la tienda todavía usa listas clásicas related, upsell y crosssell.

En este escenario, el perfil no tiene que renderizarse como un bloque independiente. Puede conectarse a la lista nativa y trabajar en uno de dos modos.

El modo append mantiene los productos nativos y añade los resultados del perfil. Es una buena solución allí donde el equipo e-commerce todavía quiere conservar parte de las relaciones configuradas manualmente, pero al mismo tiempo necesita una capa adicional de automatización.

El modo replace va un paso más allá y sustituye por completo la lista nativa por los resultados del perfil. Es una opción especialmente interesante para tiendas que ya no quieren gestionar relaciones manualmente y esperan que la lógica del perfil se convierta en el mecanismo principal de recomendación.

Esta arquitectura ofrece mucha flexibilidad de implementación. Se puede introducir el módulo por etapas, ampliando primero las listas nativas y asumiendo solo más adelante el control total sobre ellas.

XML como capa de inserción flexible

Desde la perspectiva de la implementación, es muy importante que el módulo no termine en la lógica de selección de productos. El control sobre el lugar donde se renderizan es igual de importante.

Precisamente por eso el perfil incluye campos XML asignados a cada placement. Permiten insertar el resultado del perfil en un contenedor concreto o bajo un bloque determinado del layout, sin necesidad de crear un módulo aparte solo para colocar la lista en el sitio adecuado.

En la práctica, esto es crucial al trabajar con temas personalizados. Cada frontend tiene su propia estructura de layout. Algunos temas mueven la descripción del producto a otro parent, otros construyen sus propios wrappers y otros rediseñan casi por completo los bloques nativos de producto de Magento. La posibilidad de controlar el placement mediante XML aporta aquí una ventaja clara.

Es precisamente esta capa la que hace que el módulo no sea solo un motor de recomendaciones, sino también una herramienta de integración. Para las agencias esto supone un ahorro real de tiempo, porque permite adaptar la forma de inserción a un proyecto concreto sin tocar la lógica principal.

Escenarios de implementación de ejemplo

El escenario más simple es la recomendación clásica de "misma colección, distinta base". Un perfil puede activarse para un producto de una base concreta y, a partir de las matching rules, encontrar productos con la misma gráfica pero pertenecientes ya a otra familia de surtido. De este modo, la tienda puede promocionar conjuntos o ampliar la compra con otros tipos de producto sin construir relaciones manuales.

El segundo escenario son los accesorios o complementos en el carrito. En este caso, el contexto puede ser el primer producto o el más caro del quote, y los target filters acotan el resultado final a productos que tengan sentido como ampliación de la compra. Esto resulta especialmente útil allí donde el cross-sell estándar de Magento no ofrece suficiente control.

El tercer escenario son las campañas estacionales. Un perfil puede funcionar solo dentro de un rango de fechas concreto, únicamente para determinadas store views y solo para grupos concretos de clientes. Desde la perspectiva del equipo de implementación, eso significa que la campaña puede construirse dentro del mismo mecanismo, sin crear un módulo promocional independiente.

El cuarto escenario es la sustitución parcial o total de los upsells nativos. Esto resulta especialmente interesante para tiendas con mucho surtido, muchas características de catálogo y sin intención de mantener relaciones manuales entre productos.

Por qué este enfoque escala bien en el mantenimiento del proyecto

Para las agencias, la pregunta más importante no es solo "¿funciona?", sino también "¿se podrá mantener dentro de seis meses?".

Y es precisamente aquí donde el enfoque basado en perfiles tiene su mayor ventaja. La lógica no está dispersa entre observers separados, plugins y clases dedicadas para casos individuales. En su lugar hay un único modelo de configuración y un único motor de recomendaciones que puede evolucionar por capas.

Esta estructura aporta varias ventajas:

• es más fácil entregar el proyecto al equipo de mantenimiento,
• es más fácil añadir nuevos escenarios sin reescribir los existentes,
• es más fácil diagnosticar el comportamiento de los perfiles porque la lógica está concentrada en un solo lugar,
• es más fácil trabajar con frontends personalizados gracias a la capa XML,
• es más fácil separar las decisiones de negocio de los detalles de implementación.

En la práctica, esto significa que el módulo no solo ofrece nuevas posibilidades a una agencia en la fase de implantación, sino también una base sensata para el desarrollo posterior del proyecto.

Resumen

Kowal_RelatedProductsProfiles no es solo un mecanismo para mostrar otra lista de productos en una página. Es una herramienta para diseñar escenarios de recomendación en Magento 2.

Para los equipos de implementación y las agencias hay tres puntos especialmente importantes. Primero, el módulo permite construir la lógica de recomendaciones sobre perfiles en lugar de excepciones puntuales. Segundo, ofrece control sobre placement, contexto, selección de productos y renderizado. Tercero, encaja bien en proyectos reales donde hay que equilibrar expectativas de negocio, limitaciones del tema y necesidad de seguir ampliando la tienda.

Si un proyecto necesita algo más que simples relaciones manuales entre productos, este modelo ofrece mucha más libertad que los mecanismos estándar de Magento. Y ahí es donde reside su mayor valor.